When I implemented GPSID to abstract out GPS hardware via a nice set of API's, I thought when people heard about it they would all say how smart I was.  Unfortunately I didn't get that.  Instead it was "You're a bonehead, you're going to break back-compat.  You didn't break back-compat did you, you bonehead?"  Even the marketing guys got on me.

The concern was that GPS is almost always exposed over serial or virtual serial ports (it's changing a bit with A-GPS, but that's another story).  Serial ports usually don't do multiplexing, so if GPSID grabbed the real GPS hardware driver then it would block other legacy apps from getting at it.

Ignoring the blow to my self-esteem to have even a marketing guy think I was a bonehead, the answer is no -- I didn't break backward compat with old applications to my knowledge and for the most part.  I avoided breaking back-compat by having GPSID act as a multiplexer and be the virtual serial driver legacy apps could talk to.  This makes UI tricky but long term it'll be much better.

Still, my statement above about no BC breaks is pretty qualified so I should expand:

"To my knowledge" -- There was a newsgroup thread with some folks complaining about setting up GPSID to talk to their GPS device, but they were having problems accessing GPS in the first place and I never heard back from the regarding some questions I asked.  Beyond that I've heard no complaints, which means of course no one is using it or people are using it and it's working.  I hope the latter.  If you have problems, please let me know via a newsgroup (for various reasons I hate having conversations on the blog forum).

The "for the most part" is the more interesting part of this, as I know there are a few areas where I favored stability over back-compat.  Let's say that you have a GPS chip that's happily generating a NMEA stream, which is the standard and is the only thing GPSID knows how to parse.  Let's say now that some random app sends some random, proprietary data via WriteFile() (using GPSID multiplexer) and asks the chip to go into some weird format that only the app and the GPS chip have ever heard of.  In the past that app didn't affect anything else since it owned the GPS serial port, but now it would break all other apps on the system relying on GPSID. 

Similarly, imagine that the app could send some weird DeviceIOControl() to the chip to cause similar weirdness.  Or suppose that the app called SetupComm(), SetCommTimeouts(), or SetCommState() to mess with the baud-rate or such.  GPSID itself maintains these for the GPS device and GPSID's settings are registry configurable, so having the app mess with it through one of these API's just invites problems.

So for that reason, if you do DeviceIoControl() or WriteFile() with the handle being the GPSID multiplexer, GPSID will reject it unless you are a trusted application (in which case I'll defer to letting trusted apps be gods).  I will always block the SetupComm/SetCommTimeouts/SetCommState API calls from going through to the underlying driver.  This is just one of those hard calls between backcompat and doing the right thing for the rest of the system.

Of course if you're writing new applications targeting Windows Mobile 5 or above, please please please use GPSOpenDevice and friends!  Not only will you not have to deal with these multiplexer limitations, you'll be the beneficiary of me enforcing them -- it could be your application's access to GPS that I'm stopping from getting screwed up by somebody else!

[Author: John Spaith]