Recently, I was tasked with creating an installer application to get around some of the browser inconsistencies they’ve been experiencing with the various Smart Phones.  They have an installer app that has an executable and an XML file that the executable reads for it’s configuration.  Pocket PC allows you to download the XML file and the executable file and everything just worked.  The Smart Phones do not behave this way.  I created an app that downloads both the EXE and the XML file to the My Documents directory and launches the EXE.  Works great.

My problems started when I tried to cab up the whole thing and install it from a mobile device.  I signed each file inside the cab as well as the cab itself.  I kept getting prompted by the device asking me if I want to trust this unknown publisher?  At first, I thought maybe I had screwed up the signing.  Turns out that no, I did sign it correctly… for windows clients.  The Windows Mobile platform uses a different technology than Authenticode.

On this MSDN article about how to Sign your Windows Mobile Application, it states very clearly: ”Authenticode signatures for other Windows platforms, such as Windows Client or Windows Server, use a different technology than Windows Mobile code signing and are not recognized as valid normal or privileged mode signatures.”  What I don’t yet understand is that it states Windows Mobile (not Smart Phone) uses a different technology, yet we used Authenticode to make the prompts go away for the Pocket PCs we were testing on (Windows Mobile 5 and 6).

The Windows Mobile code signing seems very expensive.  From what I can tell it costs $350 for 10 signings.  There is an additional fee for each signing after that.  What this means is that you better be darn sure your application is finished before signing your application.  I’ve read that you have to submit your signed cab to Verisign who then signs your cab file with their certificate.  I am beginning to hate the Windows Mobile platform and might actively root for their demise…

I seem to have troubles finding this article when I need it, so here is a link to help me figure out the user interface options I have for the SmartPhone:

http://msdn.microsoft.com/en-us/library/aa446513.aspx#smartphoneuserinterface_topic3

Initially I believed it was because I didn’t have the Windows Mobile 6 SDK installed.  I needed the app to be backward compatible to Windows Mobile 5 so I haven’t messed around with the new SDK yet.  When I looked (skimmed) through the documentation, everything led me to believe that most windows mobile 5 apps will run on a Windows Mobile 6 device.  There is the exception that if you are using undocumented APIs, they aren’t guaranteed to work.  Since the app I’m working on logs GPS coordinates in the background, it was possible that I was using some calls through a 3rd party library.

Turns out my problem was much more basic.  Once I got my hands on an actual Windows Mobile 5 smart device to test on, I discovered the problem right away.  The app was failing when it tried to create a list box.  My simplistic thinking was that you write applications for “Windows Mobile 5″.  You actually write for either Windows Mobile Smartphones or Windows Mobile Pocket PCs.  One is more limited than the other.  The naming is still confusing to me.  My iPhone is a “smart phone” so I assumed that Smartphone was simply Pocket PC + phone.  WRONG.  Windows Mobile 6 makes it even worse.  They label one sdk “standard” and the other “professional”.  I am pretty sure professional = pocket pc = more functionality.

So I learned that if you want to write lowest common denominator applications for Windows Mobile, you need to target the smart phone.  And you should really test your interface at different resolutions because those smart phones have tiny screens.

After signing the EXE and the CAB file, this worked just fine on Windows Mobile 5.  When testing on Windows Mobile 6, I got the following error: “program is from an unknown publisher”.  Not only must the EXE and CAB file be signed, but all the DLLs inside the CAB must be signed too.  There are two ways to accomplish this.

The first method is to simply add the signtool commands mentioned in my previous post to sign the DLLs.  Aftter the DLLs are signed, you cab up all the files using CabWiz.exe. Then you sign the cab file itself.

The second method is to use the utility CabSignTool.exe from Microsoft.  This handy utility explodes a CAB file, signs every executable and DLL file inside, then recabs it and signs the CAB file.  In order to use it, you will need to download and install the Windows Mobile 6 SDK.  The tool is located in <WindowsMobile6SDK>/Tools/Security/CabSignTool.  Make sure this is in your path.  The cabsigntool takes most of the same arguments as the signtool.  The only differences are that the first two parameters are the input and output cab names and the “sign” command is not necessary.  So to accomplish signing the cab, do something like the following:

c:> cabsigntool.exe cabinput.cab caboutput.cab /f [yourcert.pfx] /p [yourpassword] /t [yourtimeserver]

When you execute this command, it will extract the contents of your cab file.  It will sign each file inside.  It will then recab the files and sign the cab file.  So you can accomplish with one command what it took multiple lines to do with signtool.exe alone.

http://msdn.microsoft.com/en-us/library/aa924367.aspx
http://msdn.microsoft.com/en-us/library/bb278115.aspx

Most of the documentation to sign code for the Windows Mobile device assumes you want to do it all through the Visual Studio enviornment.  Well I don’t.  Here is what you need to do to get your application signed as well as the install cab created and signed using the command line.

First, get your certificate from verisign, godaddy, or some other certificate authority.  Follow their directions to install it in your store and create a *.pfx file.   I used godaddy http://help.godaddy.com/article/5087.

Sign the exe using the signtool.exe

signtool sign /f {yourcert.pfx} /p {yourpassword} /t {http://yourtimeserver} {yourexe}

Second, You will need an ini file that cabwiz.exe will use to create the cab file.  The easiest thing is to create a SmartDeviceCab project and use Visual Studio to determine what you will install on the device.  When you compile this SmartDeviceCab project, it creates an ini file.  You use this ini file to create your CAB file as your starting point.  Run the following command to create the cab file:

cabwiz.exe your.inf /cpu CEDevice /compress

After you have created your cab file, you can then sign the cab file the same as you signed your EXE.  That should be all there is to it.

The issue I worked on was making sure the data gets the server in a format that the PHP folks can recognize.  Internationalization (i18n) created a problem because the dates and numbers were being sent in a different format. In Chile for instance, the dates and numbers were not coming out as we expected.

currentLatitude.ToString("#0.00000");
// this came out as 0,00000

gpsTime.ToString("MM/dd/yyyy HH:mm:ss");
// This came out as MM-dd-yyyy HH:mm:ss

Apparently, .NET converts these for you based on the NumberFormatInfo object and the DateTimeFormatInfo objects.   I thought an easy way to correct this would be to set the current thread locale to be that of US so I could send the data in the expected format.  In the full .NET world, you could write something like this to accomplish it:
http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo(VS.71).aspx

Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");

Unfortunately, the CurrentCulture property on the thread object is not available in the compact framework.  Instead, you need to pass the culture object along with the format in the toString methods. You could create a CultureInfo object such as “en-US” and pass this, but .NET provides a better alternative.  The CultureInfo object has  a property called InvariantCulture.  Using this object ensures that the behavior is consistent across all the different cultures.

currentLatitude.ToString("#0.00000", CultureInfo.InvariantCulture);
gpsTime.ToString("MM/dd/yyyy HH:mm:ss", CultureInfo.InvariantCulture);


After doing this, it is exactly as one would expect.