"Network is unreachable" on an embedded box

We've been working extensively with embedded boxes lately trying to migrate our platform over. One of the programs we've been trying to migrate today was a simple announcer program that sends out a UDP broadcast. On our first go, the program wouldn't work, saying that the "Network is unreachable" when doing a 'perror' after the call to 'sendto'. After much experimentation with various network binding flags, etc, which took the whole day, I went into overtime trying to figure out the problem. Eventually, I got to the point where I inspected the routing tables of the embedded system and was shocked to find .... there was no routing table entry for the default gateway, i.e. 0.0.0.0 destination IP. I'm actually kind of ashamed of how long it took me to find this, but in my defense, I was dealing with a wild mixture of systems and had done a lot of network reconfiguration with the systems and some of the stuff was handled automatically for me by my Ubuntu box, which gave me some inconsistent results at times when experimenting.  For my own future reference, here's how I solved the problem:

• Run 'route -n'
• Ensure there's an entry that looks like the following :
• Destination: 0.0.0.0 Gateway: [the desired gateway, e.g. 192.168.10.1] Genmask: 0.0.0.0 Flags: UG, Metric: 0, Ref: 0, Use: 0, Iface: eth0 (or eth2, or whatever you may have)
• If the above entry doesn't exist, add it with the following command:
• sudo route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.10.1 dev eth0

You should now have no problems with your UDP broadcasting. If you do, well, let me know how it goes, I'd love to hear your problem and your solution.

Synchronizing with a remote SVN repository

We recently had a double hard-drive failure on our RAID 5 on our main server at work, and we lost our stuff. Our primary backup method of that system had completely failed due to the incompetence of some of the staff in our parent company that was completely beyond our control. It's only by the grace of the fact that our IT guy had an extra weekly backup that we were able to recover as much as we were. That said, it brought to light the need to have our own extra backups of our source code because we can't rely on the people we're supposed to be able to rely on to do the backups for us. We're now going to be creating our own copies of the SVN server on a semi-daily basis, and I've found instructions on how to do it on this awesome StackOverflow post. I'm just sorry I didn't know about this sooner.

Cross-compiling libexpat (and other libraries)

So, lately I've been trying to cross-compile libexpat for a new board with a different architecture from what we typically use at work, and I've been having one heck of a time, until I finally got help online from my question at stackoverflow. Turns out, I just needed to be more specific about my host architecture in the configure command:

./configure --host=arm-none-linux --enable-shared CC=arm-none-linux-gnueabi-gcc CXX=arm-none-linux-gnueabi-g++ AR=arm-none-linux-gnueabi-ar RANLIB=arm-none-linux-gnueabi-ranlib STRIP=arm-none-linux-gnueabi-strip

I'm going to try similar recompilation with other libraries so that I can improve the functionality of our older systems as well.

Journey to robust Windows Services

Because I have the need for it in several projects, I'm going to be working with Windows Services implemented with .NET quite a bit in the next little while. That said, I'd like to refer to some resources for working with Windows Services:

• The MSDN page on creating windows services
• The MSDN page on debugging a Windows Service
• The MSDN page on installing and uninstalling Windows Services

Also, there are some issues that I ran into while working on my first service. I had originally planned to expose a WCF endpoint through WS-HTTP, however, I can into an unpleasant exception when I tried to do so: AddressAccessDeniedException. Apparently, the cause of this is the fact that http bindings are reserved for processes run as administrators. Fool me once, shame on me. In light of that fact, I'm switching over to using net.tcp for my local Windows Service-hosted WCF service. I'll post more here as I learn it.

Adding the Network Service account to the permissions for a file/folder/registry key etc

I'm currently developing a Windows Service that's to be run under the Network Service account (owing to the fact that it requires substantial network access). I'm just starting to learn how to program Windows Services, so this is very new to me. I just started developing a simple service to start, and when I followed the instructions on this MSDN page, I was surprised when, after trying to start my service, I got the error 005: Permission denied. I later found out that I needed to give the network service account to the folder from which the service was running, i.e. the debug output folder of my project. Doing this isn't as simple as setting the permissions for other users. To add the network service account to the permissions list in Windows 7, do the following :

1. Right click on the folder containing the service you want to debug, and go to Properties
2. Go to the Security tab, and under the box marked "Group or user names", click on Edit ...
3. Under the window that pops up, you'll see another box marked "Group or user names". Underneath that box, click on Add ...
4. In the "Select Users or Groups" dialog that pops up, click on the Advanced... button at the bottom left.
5. In the advance "Select Users or Groups" dialog that pops up, click on Find Now to find all the users, groups and built in security principals.
6. Once the search results are populated, scroll down and select "NETWORK SERVICE" (not "NETWORK") and click on Ok, then Ok again in the Select Users or Groups dialog.
7. One you're back to the Permissions window, ensure that you give the Network Service account Full Control over the folder in the Permissions box, then click Ok.
8. Click Ok one last time to close the properties for your folder, and you're done.

Wpf2WinRT: Bindings are not the same!

I've just learned something new about the bindings system in WinRT: they're not the same as Bindings in WPF. Check out the MSDN page for WinRT BindingMode, and you'll see that they're missing a value from WPF: OneWayToSource.

Migrating from WPF to Windows 8

As part of the ongoing development efforts at my company, I'm always researching the latest technologies and developments. My latest endeavour is researching Windows 8 and doing technical feasibility work to find out if it's right for us. On that front, I'm learning how to develop for the Windows 8 runtime in C#. I've got a lot of experience in WPF, and our current Line-Of-Business application is written in WPF, so I'm used to certain things, things which I'm finding no longer hold true in WinRT programming. For example, how resources such as strings are accessed in XAML. For WPF, if I wanted the internationalized string for a label, I'd do something like this : <Label Text="{x:Static resources:Messages.UserName}"/> However, the x:Static XAML extension no longer exists. Instead, you have to follow the *very different* ways of accessing string resources on this MSDN document, because the means of accessing resources for a WinRT application are both simpler (in some ways) and more robust, if a little bit confusing at first. For string (and even other resources, such as images) internationalization in WinRT, what you do is this: 1. Create a folder path for your strings: \Strings\en-US 2. Under the aforementioned folder, create a resources file named Resources.resw (not that it's not .resx, as with previous .NET applications written in Windows Forms, WPF and ASP.NET) 3. Add a new string with the Name "ApplicationName.Text". The ".Text" suffix is very important; you'll see why in a minute. 4. In your XAML, create a TextBox like this: <TextBlock x:Uid="ApplicationName" Text="" /> The Uid attribute is used for associating controls with resources, according to the MSDN link provided above, and the .Text suffix in the resource Name column, specifies the property to which the resource is linked. Honestly, I'm not sure I like the way this is going, but if it reduces code clutter, I'm willing to at least give this a try. We'll see how this pans out.