|This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
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.
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 CreateFileand 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
Instead, they call
GPSCloseDevice. For more information about this interface, see
- Raw mode, using the Windows Embedded CE stream device driver
CloseHandle). The information provided by each
ReadFilecall 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
Internally, the GPSID communicates with the underlying GPS hardware driver. It provides location data from the hardware driver to applications that call either GPSGetPositionor ReadFileto 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.