Device drivers link physical or virtual devices with the OS, making devices available to the OS and applications through an interface. The following diagram illustrates how a typical device driver interacts with the OS and device hardware.
As shown in this diagram, applications communicate with device drivers through the file system and the Device Manager. The Device Manager interacts with device drivers and the kernel to manage device access. Device drivers call kernel APIs to access hardware; the kernel, in turn, calls functions in the OEM Adaptation Layer (OAL) to read and write device registers. When the device generates an interrupt, the kernel intercepts the interrupt and forwards it to the device driver as an interrupt event. For more information about device driver hardware access and interrupt handling, see the Device Driver Developer Guide. For more information about the OAL, see OEM Adaptation Layer.
Windows Embedded Compact supports two primary device driver models: stream interface drivers and native device drivers. Stream interface drivers implement and expose a standard set of stream interface functions for use by applications. Any device that can be treated as if it were a special file—that is, a producer or consumer of ordered streams of bytes—is a good candidate for a stream interface driver. Native device drivers implement and expose any interface other than the stream interface functions. The APIs exposed by native device drivers are most often specifically customized to the underlying device's functionality. For more information about these device driver models, see Stream Drivers and Native Drivers
All device drivers in Windows Embedded Compact are dynamic-link libraries (DLLs). Windows Embedded Compact device drivers primarily use the standard Windows Embedded Compact APIs in their implementation. This differs from drivers on desktop Windows where drivers use the Windows Driver Model (WDM) interfaces. Any device driver in Windows Embedded Compact can use a monolithic or layered organizational model. A monolithic device driver is based on a single segment of code that exposes the hardware device’s functionality directly to the OS; monolithic device drivers access hardware devices directly. A layered device driver consists of two layers: a model device driver (MDD) upper layer, and a platform-dependent driver (PDD) lower layer. For more information about monolithic and layered device drivers, see Layered and Monolithic Drivers.
Windows Embedded Compact device drivers are loaded and started by one of three processes, as shown in the following table.
| Device driver loading process | Loads |
|---|---|
Device Manager | Stream Drivers |
GWES | Keyboard, video adapter, touch screen, printer, and mouse native drivers. |
File System | Native file system drivers |
In each case, the process that loads the device driver examines registry settings to determine how to load and start the driver. To configure the OS to load and start a device driver, you select the appropriate process for loading that device driver type and configure the registry settings for that process with information about how and when to load the device driver.
Applications and OS components access device drivers through different interfaces, depending on whether the device driver is a native driver or a stream driver. When the device driver is a native driver, the access method for the device driver is built into the native interface that the driver exposes to GWES or the file system. For example, if a device driver controls a graphics adapter, GWES uses the GPEEnableDriver function of the driver to connect the driver to GWES. Unlike stream drivers, native drivers are typically opened for exclusive access by the subsystem that controls that driver.
When the device driver is a stream driver, the OS and applications can gain access to the device driver through the file system by making a call to CreateFile to get a handle to the device. After an application obtains this handle, it can call ReadFile and WriteFile to perform read and write operations, which Device Manager translates into corresponding calls to stream interface functions on the device driver. So that Windows Embedded Compact can recognize stream device resources and redirect file operations to the appropriate stream driver, it uses special naming conventions for file names that represent device resources instead of ordinary files. A stream device driver can use one or more of these three device naming conventions: legacy, device-based, and bus-based.