GPSID: From device driver->service and why GPS OEMs should care
I realize as I type this that there's probably 5 people in the world that actually care about this post (or most of my posts for that matter), so if you're one of the 5 I hope you really enjoy it :).
In Windows Mobile 5, when we introduced GPSID (GPS Intermediate Driver), I had to put it in device.exe. Perhaps it seems logical that I should put the Intermediate *Driver* in the device driver host process, but I really didn't like doing it. My issue is that I focus on the *Intermediate* part, so that it sits between the real device driver DLL that talks to hardware and the user app. Services.exe is perfectly capable of hosting system services like this and does for stuff like MSMQ, UPNP, and others.
The reason I couldn't put it in services.exe has to do with Prefix name collision and the multiplexer. GPSID has to multiplex raw NMEA streams on COM0-9: (as user specifies) in order to support backward compatibility for apps that use NMEA raw. The problem with the "COM" prefix is that a lot of stuff wants to use it and you have a real possibility of 2 devices being configured to be COM4 for instance. If an app asked GPSID to multiplex on COM4, I would try to register myself for that if possible.
The issue is that services.exe and device.exe keep separate lists of registered Prefix ports (in CE 5.01 & before). Had GPSID been running in services.exe, it would've called RegisterService("COM5",...) on itself and had that call succeed even had device.exe already had someone registered with COM5.
Obviously we can't have 2 device drivers on COM5, even though services.exe could tell a service registering for COM5 that it owned it when it didn't. What would happen in this case is that when an app did CreateFile("COM5",...) the filesystem prefers device.exe and would ask device.exe first if it had someone who owned COM5. Device.exe would say yes it did, return a handle to that guy, and then never call into the services.exe version of COM5. So this is why I had to put GPSID into device.exe, so that I used its handle list. Almost everything else with "COM" in it is a driver of some sort, not a service.
In CE 6.0, we've moved the PREFIX handle tracking to the kernel. This means that it protects us against collisions between process like this, and hence I was able to make GPSID a service (which it should be).
The reason I think 5 people (rather than 0) care about this is that if you're writing a device driver that interacts with GPSID, you need to be aware that in a future OS version it's changing processes. You can future proof yourself (to some extent) by only using the DeviceIoControl() interface to communicate to GPSID as described here.
[Author: John Spaith]