GPS Intermediate Driver Architecture
A version of this page is also available for
4/8/2010
The GPS Intermediate Driver (GPSID) works by injecting itself between applications and GPS hardware. To an application, the GPSID appears like GPS hardware. To GPS hardware, the GPSID appears like a single client. This abstraction layer provides multiple benefits to developers. For more information about these benefits, as well as a brief comparison between the model used by the GPSID and a model where an application interacts directly with GPS hardware, see GPS Intermediate Driver Benefits.
The figure below shows the GPS ID architecture. In the figure blocks are shaded with left or right diagonal patterns to create two logical groups. The right-diagonal group deals with NMEA input. The left-diagonal group deals with raw input.
.gif "Bb201942.598d5d4d-8f11-462f-8087-e3a51d6123d9(en-us,MSDN.10).gif")
Legacy applications are those which expect to read a COM port and receive NMEA data. They use functions such as CreateFile() and ReadFile(). GPSID provides data to Legacy applications by disguising itself as a COM port and registering itself as the service for “COMX:” where "X" is specified in the registry. The multiplexer allows many legacy applications to use the virtual COM port simultaneously.
New applications are those that use the GPS API. They get data through the structures defined by the API, and do not need to parse NMEA sentences. The GPSID parses the GPS hardware's NMEA sentences into the API structures for the applications.
The GPSID is implemented as a normal device driver. In Windows Mobile this is run from device.exe and is loaded into the device.exe process like all device drivers, even though it does not interact with device hardware directly. It uses another device driver - the one provided with or used by the GPS hardware - which then interacts with the actual hardware.
For example, suppose that, without the GPSID, an application interacts with GPS hardware by calling CreateFile and passing "COM1:" as the first parameter. With the GPSID, the application no longer connects directly to the GPS hardware. For the application to retrieve data using the GPSID, it must first configure the GPSID to connect to the GPS hardware using COM1. You can do this using the GPSID Control Panel application (if present on your target device), or by manipulating the registry. For detailed information about configuring the GPSID, see Configuring the GPS Intermediate Driver.
Once the GPSID knows where to find the actual GPS hardware, applications can use the GPS hardware through either of two interfaces:
- Parsed mode, using the GPSID API. This interface enables developers to retrieve GPS data without calling CreateFile and ReadFile. Instead, they call GPSOpenDevice, GPSGetPosition, and GPSCloseDevice. For more information about this interface, see Accessing Parsed GPS Data.
- Raw mode, using the Windows Embedded CE stream device driver interface (CreateFile/ReadFile/CloseHandle). The information provided by each ReadFile call is the data as it was retrieved from the GPS hardware. Applications are responsible for parsing the NMEA strings themselves. This interface provides backward compatibility by supporting applications that expect to interact with GPS hardware directly through a stream interface. For more information about this interface, see Accessing Raw GPS Data.
Internally, the GPSID communicates with the underlying GPS hardware driver. It provides location data from the hardware driver to applications that call either GPSGetPosition or ReadFile to retrieve the GPS data. The GPSID tracks location data that is provided to each client so that one application obtaining location data does not prevent another application from obtaining the same location data. The fact that the GPSID may be providing location data to multiple applications is completely transparent to applications using the GPSID.