Partager via

GPSID: From device driver->service and why GPS OEMs should care

  • Article

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]

Comments

  • Anonymous
    November 14, 2006
    In Windows Mobile 5, we first introduced the GPS Intermediate Driver. I describe why it went into a WM
  • Anonymous
    December 07, 2006
    I guess that makes me one of the 5 people in the world... Thanks for posting all the info regarding gpsid and related things like the location framework. Good stuff.
  • Anonymous
    August 31, 2007
    I care too ... I guess I might be number six.
  • Anonymous
    April 22, 2008
    John,Thanks, that was informative. Quick question. Is it possible to read GPS in winmo6 when the device goes to sleep? Also, on some devices, we have found that device.exe crashes when the device comes out of sleep - specifically the sprint 6800 (aka htc mogul).naeem
  • Anonymous
    April 25, 2008
    With device being asleep, different people have different concepts of what sleep means -- CPU not running and only being around for critical interrupts is what I (and most people I suspect) think sleep means.  But sometimes I've heard it over-ridden funny so it just means CPU is in some low power state but certain stuff can still run.For this discussion, let's assume it's the traditional device sleep.  In this case, no, you can't read GPS stuff in this condition.For the "low power mode", I really don't know.  A newsgroup (listed at http://blogs.msdn.com/cenet/archive/2005/12/05/500181.aspx) may be helpful, though this could vary from OEM to OEM also.  I'm out of my element on this one, I'm afraid.RE device.exe crashing - I've never heard of this one.  Again a newsgroup may be a better starting point to see if other folks have hit.John