Defeated by Microsoft

I have never understood why Microsoft has become the most successful software company in the world. When compared to similar products the underlying design of their software, to me, seems unnecessarily complex. And the company couldn't care less about backward compatibility and breaking something when bringing out a new version. Microsoft software development tools, compared to third party products like Delphi or Lazarus, are far more difficult to use in my opinion. Visual Basic long ago ceased to be a "basic" programming language for amateurs like myself.

I had an idea for a program to run on my HTC Touch Pro smartphone that needed to access the phone's internal GPS. A couple of months ago I actually got a good way towards implementing it for the Android platform (even though I'd never programmed in Java before) just by downloading the source code of someone else's GPS application and modifying it using the free development tools. But because my phone was running an unofficial port of Android on which not all features worked I could only run it in an emulator, not transfer the app to the phone. In any case, the XD Android port was unstable and ate battery power even worse than Windows Mobile did, so I had to go back using WM 6.1 despite the fact that under Android it was a much nicer phone.

So I thought I'd have a go at writing my program for Windows Mobile. I had a copy of Visual Studio 2005 sitting on the shelf. So as before, I started Googling for example programs for accessing a GPS.

If I am writing a program for Windows desktop using Lazarus / Free Pascal I can Google for what I am trying to do and nearly always find code I can use. Even if it was written for Borland Delphi in 1996 it usually still works. The problem with the Windows smartphone / PDA platform is that it has been through many incompatible incarnations in less time than that. There is Windows CE, Pocket PC, Windows Mobile versions 4, 5, 6 and 6.1, Windows Smartphone, Windows Phone 7, Compact Net Framework 1.0, Compact Net Framework 2.0 and Compact Net Framework 3.5. If you do manage to find a relevant example there is no guarantee that it is actually compatible with the development tools and SDKs you have installed on your PC, or with your mobile device.

The first program I tried that actually did anything came with two DLLs, one for serial port access and one to decode the GPS data. That would print out a few NMEA strings and then fail with an exception. None of the other examples I tried would do anything at all. The problem with the first program appeared to be in the serial port DLL, so I tried to upgrade it to version 2.0 of the .Net Compact Framework which had built-in serial port support. I copied examples of serial port access code but although the program didn't crash it never received anything from the GPS at all, even though I knew it was working (e.g. by running APRSISCE.) Unfortunately when run from Visual Studio the Net CF 2.0 programs would display an error on the phone that "this device has a newer version of the Compact Framework installed that must be uninstalled first." I wasn't about to do that since who knows what it would break. So much for backward compatibility.

One of the reasons implementing my idea was so easy on the Android platform is that Google had provided a GPS object that gave you ready to use data. On Windows Mobile you have to listen to the GPS via a serial port and then parse the NMEA data that comes out. So, having failed to find a GPS example that would run for more than a couple of seconds I decided to look for serial port examples. None of those would receive any data from the GPS either. I even found a free GPS test application. That would receive several lines of data from the GPS then disappear without trace.

At this point I started to wonder if there was a problem with the internal GPS of my HTC Touch Pro. I did some more Googling and found that users of some GPS apps on HTC smartphones with internal GPS had found these apps did not recognize the internal GPS or timed out while waiting to get data from it. Presumably these apps had been written based on the same code examples I had been trying. One user had found the only way to get the GPS data into the program was to use a program called GPSGate. But this was a commercial program, costing money, which I had no wish to spend just to see if this worked when everything else hadn't.

After a couple of days of fruitless effort my interest in continuing with this project had evaporated completely so I gave up. At least, unlike with abortive hardware projects, no components were wasted. I restored the PC back to a couple of days earlier to remove all the hundreds of megabytes of APIs, SDKs and examples I'd installed. And I have gained a new respect for people who actually manage to develop software using Microsoft tools.