Microsoft Windows CE 3.0  

Loading Stream Interface Drivers

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.

There are two ways to load stream interface drivers. One involves the Device Manager, while the other is specific to applications.

The first type of loading occurs at startup. When a Windows CE–based platform starts up, it starts the Device Manager. In turn, the Device Manager reads the contents of the HKEY_LOCAL_MACHINE\Drivers\Builtinkey and loads any stream interface drivers listed there. For example, on many Windows CE–based platforms, the Device Manager loads the driver for built-in serial ports (Serial.dll) through this mechanism.

The third type of loading occurs when the Device Manager cannot automatically detect the connection of a peripheral to a platform. Unrecognized devices are often serial devices because there is no automatic way for Windows CE to detect the connection of a serial device to a serial port. If the Device Manager cannot automatically recognize a peripheral, the application that needs to use the peripheral must load the peripheral's driver. The following is the standard sequence of actions for this type of loading:

  1. The application determines that the device driver is not loaded, either by inspecting the file system or by receiving a failure return value from the CreateFilefunction when it tries to open the device file name of the peripheral. For more information, see Device File Names.
  2. The application loads the device driver DLL. Applications have a number of options for how to do this, each of which provides different levels of infrastructure support.
    • To load the device driver DLL in the process' own address space, simply call LoadLibraryor LoadDriverto load the DLL just like any other DLL. LoadDriveris just like LoadLibraryexcept that it marks the DLL's pages as non-pageable, so they stay in RAM. Device driver DLLs loaded in this way are completely unavailable to other parts of the system; they will not have device file names associated with them, so the application will have to access the driver's stream interface functions directly, rather than through the normal file system APIs.
    • The application can call RegisterDeviceto load the device driver in the process space of the Device Manager. RegisterDevicewill create a device file name for the driver so that multiple applications can use it.
    • The application can call ActivateDeviceto load the device driver. ActivateDevice handles the complex tasks of reading a device driver's registry key to get the driver's prefix, index, and other values, creates appropriate registry entries in the HKEY_LOCAL_MACHINE\Drivers\Activeportion of the registry, calling RegisterDeviceto load the DLL itself, and broadcasting a WM_DEVICECHANGE message to the system.
    • The application continues with its usual operation. When the application is done with the device driver, it should unload the driver by calling UnLoadLibraryor DeactivateDeviceas appropriate, depending on what loading mechanism the application used. DeactivateDevicebroadcasts a WM_DEVICECHANGE message to notify the system that the driver is being unloaded, calls DeregisterDeviceto unload the DLL and remove the driver's device file name, and removes the driver's registry key from HKEY_LOCAL_MACHINE\Drivers\Active.

      PC Card device drivers are handled as a special case when a user connects a PC Card to a Windows CE-based platform. In this situation, the PC Card socket driver detects the card insertion event and notifies the Device Manager that it needs to load a PC Card device driver. The Device Manager uses the PC Card's Plug and Play identifier to locate the correct device driver for the PC Card. The Device Manager then checks the HKEY_LOCAL_MACHINE\Drivers\PCMCIA\key for a subkey matching the Plug and Play identifier. If one exists, it loads the driver listed within that key. If there is no match, the Device Manager calls all of the detection functions that are listed within the HKEY_LOCAL_MACHINE\Drivers\PCMCIA\Detectkey. If one of the detection functions returns a value indicating that it can handle the PC Card, the Device Manager loads and initializes that stream interface driver.

      Whenever the Device Manager loads a device driver — either at system boot time or due to a PC Card insertion — the Device Manager calls the ActivateDevicefunction for the stream interface driver and creates a numbered subkey within the HKEY_LOCAL_MACHINE\Drivers\Active\key to track the driver. ActivateDevicealso locks the stream interface driver into working RAM. This prevents the driver from being swapped out and prevents any paging activity that would slow driver operation when servicing interrupts.

       Last updated on Tuesday, July 13, 2004

      © 2004 Microsoft Corporation. All rights reserved.