Should an application that updates Windows Mobile 6.5 to Compact Framework 3.5 be .NET 1.0 or native code?

Question

I recently inherited a large mobile application, and one of the things I'm looking to improve is its installation/update process. Right now, company policy is, whenever a new version is released, we released a new CAB file and it's manually copied to each of the PDAs it runs on. This also includes manually copying CAB files for SQL Server Compact and Compact Framework 3.5.

I'm replacing this with a little bootloader application, which will check with our server for things like updates in the application, but will also check if the compact framework and SQL Server compact are installed (and if not, will get the CAB files from the server and install them). A lot of newer Windows Mobile 6.5 devices come with the Compact Framework 3.5 installed, but not all of them. I want this bootloader to run on pretty much any device, so with that in mind, would it be more reliable to do this in native code (c++) or Compact Framework 1.0? Are there some devices that just don't come with CF at all?

Answer 1

For Windows CE (Windows Embedded Compact now) it is entirely up to the device manufacturer whether they want to include the CompactFramework. However, for Windows Mobile 6 the CF 2.0 SP2 was preinstalled with the OS (So I believe that 6.5 should have it too). I believe that you can probably write .NET CF 2.0 code for it and have it be expected to run.

As far as native code, one thing to keep in mind is that if you have different processor architectures then you cannot have the same native code, for example x86 and ARM. However, again I think Windows Mobile 6 only supports ARM processors, so I'm not sure that would be a problem either.

I think you could use either one.

Answer 2

If you would like to be on the safe way, you should write a native C (Win32 WIN_CE) application to check for updates. Windows CE comes with an autostart feature that looks automatically for a file calle autorun.exe at different directories for different processor types. In example: if you have a ARM device the OS will look at %Volume%\2577\autorun.exe (see also here). If the device has a SH3 processor, the call will be %volume%\10005\AutoRun.exe. Using the above is only needed if you plan to support non-ARM processor type systems too.

Using an autorun.exe will enable you to automatically setup or update a device. You can share the same code for different processors. AutoRun enables you to write a 'bootstrap' installation and update.

If you are faced with a more limitted set of devices and OS versions you may limit the supported processor types (possibly only support StrongARM compatible devices). Possibly you can also implicitely assume that at least .NET Compact Framework 1.1 is available on a device.