Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

BusDriver	REG_SZ	The name of the driver's bus.
BusName	REG_SZ	The name of the device's bus.
DevID		A unique device identifier from Device Manager.
FullName	REG_SZ	The name of the device if used with the $device namespace.
Name	REG_SZ	The driver's legacy device file name including index, if a prefix is specified (not present for drivers that do not specify a prefix).
Order	REG_DWORD	The same order value as in the driver's registry key.
Key	REG_SZ	The registry path to the driver's registry key.
PnpId	REG_SZ	The Plug and Play identifier string for PCMCIA drivers.
Sckt	REG_DWORD	For PCMCIA drivers, describes the current socket and function of the PC card.

NOTE

Checking the Active key

By calling the RequestDeviceNotifications function with a device interface GUID of DEVCLASS_STREAM_GUID, an application can receive messages from Device Manager to identify loaded stream drivers programmatically. RequestDeviceNotifications supersedes the EnumDevices function.

Kernel-Mode and User-Mode Drivers

Drivers can either run in the kernel memory space or in user memory space. In kernel mode, drivers have full access to the hardware and kernel memory, although function calls are generally limited to kernel APIs. Windows Embedded CE 6.0 runs drivers in kernel mode, by default. On the other hand, drivers in user mode do not have direct access to kernel memory. There are some performance penalties when running in user mode, yet the advantage is that a driver failure in user mode only affects the current process, whereas the failure of a kernel- mode driver can impair the entire operating system. The system can generally recover more gracefully from the failure of a user-mode driver.

NOTE

Kernel driver restrictions

Kernel drivers cannot display a user interface directly in CE 6.0 R2. To use any user interface elements, developers must create a companion DLL that will be loaded into user-mode, then call into this DLL with CeCallUserProc. For more information on CeCallUserProc, see the MSDN Web page at http://msdn2.microsoft.com/en-us/library/aa915093.aspx.

User-Mode Drivers and the Reflector Service

In order to communicate with the underlying hardware and perform useful tasks, user-mode drivers must be able to access system memory and privileged APIs unavailable to standard user-mode processes. To facilitate this, Windows Embedded CE 6.0 features a Reflector service, which runs in kernel mode, performs buffer marshaling, and calls privileged memory management APIs on behalf of the user- mode drivers. The Reflector service is transparent so that user-mode drivers can work almost the same way as kernel-mode drivers without modifications. An exception to this rule is a driver that uses kernel APIs that are not available in user mode. It is not possible to run these types of kernel-mode drivers in user mode.

When an application calls ActivateDeviceEx, Device Manager loads the driver either directly in kernel space or passes the request to the Reflector service, which in turn starts a user mode driver host process (Udevice.exe) through a CreateProcess call. The Flags registry entry in the driver's registry key determines whether a driver should run in user mode (DEVFLAGS_LOAD_AS_USERPROC flag). Having started the required instance of Udevice.exe and user-mode driver, the Reflector service forwards the XXX_Init call from Device Manager to the user-mode driver and returns the return code from the user-mode driver back to Device Manager, as indicated in Figure 6-5. The same proxy principle also applies to all other stream functions.

Figure 6-5 User-mode drivers, kernel-mode drivers, and the Reflector service