|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.|
In addition to the primary display, Windows CE–based platforms can support additional display devices. These additional controllers might be used, for example, to support a Video Graphics Adapter (VGA) output to a CRT screen. Display drivers for such additional display devices are called secondary display drivers. Secondary display drivers are loaded only when an application calls the CreateDCfunction with the name of the secondary display driver's .dll file. CreateDCreturns a handle to a device context that is associated with the secondary display driver. An application can use this device context just like a device context associated with the primary display driver; all of the text and graphics application programming interfaces (APIs) work with the device context. However, applications cannot use any Window Manager functions with the device context because the Window Manager was not involved in creating it. Thus, applications are responsible for rendering the entire display on the secondary display device. If you want to create the appearance of windows, menus, dialog boxes, scroll bars, and so on on the secondary display, your application must draw those items itself, using the text and graphics APIs. If you want to show the contents of the primary display on the secondary display, your application can copy the frame buffer for the primary display to the frame buffer for the secondary display. The secondary display driver is unloaded when there are no remaining device contexts associated with it. When multiple display devices are being used, the GDI makes sure that all drawing calls are routed to the appropriate display driver.
Windows CE–based platforms can provide a built-in secondary display controller. The controller must be managed by a secondary display driver. The secondary display driver must be implemented as an ordinary Windows CE display driver, and expose the same display DDI as other display drivers. The sample ATI display driver is the only CEPC display driver that will work as a secondary display driver, and then only if the primary display driver is not also an ATI display driver.
If the display controller resides on a removable medium, such as a PC Card, the secondary display driver can be implemented as two DLLs or as a single DLL. In practice, most device driver writers choose to implement two separate DLLs: a secondary display driver that exposes the native display DDI and a stream driver that exposes the stream interface functions. The Device Manager loads the stream interface driver when a user connects the display adapter to the system and registers the driver's special device file name; for example, "VGA1:". The secondary display driver is loaded when an application calls CreateDCand passes in the name of the secondary display driver's .dll file. The secondary display driver gets a handle to the stream interface driver by calling the FileOpenfunction on the "VGA1:" special device file. The secondary display driver handles all of the graphics processing. When it needs to communicate with the display controller, it uses the stream interface driver's IOControlfunction.
You may choose to create a single DLL that acts as both secondary display driver and stream driver instead. In this case, the Device Manager loads this combined driver in its own process space to serve as an ordinary stream interface driver, whereas GWES would load the same driver in its process space to act as the secondary display driver. If you choose to implement a combined driver, be aware that because the driver DLL is loaded in separate process spaces, it cannot share global data without using shared memory or a memory-mapped file. Furthermore, having the driver loaded twice wastes system resources.
Many of the stream interface functions are not used by display device drivers because display devices are not particularly oriented to working with streams of data. Display drivers need only have stubs for those functions. For these interfaces, the driver should handle the call and return. The driver's XXX _Initand XXX _Deinitfunctions are exceptions. The driver should handle calls to these functions correctly, as is described in Developing Stream Interface Device Drivers. The Device Manager calls XXX_Initwhen the display adapter is connected to the system. When the adapter is disconnected, the Device Manager calls XXX_Deinit. XXX_Deinitdeletes any data structures and registry entries that were created by the driver's XXX_Initfunction.
Like all Personal Computer Memory Cars International Association (PCMCIA)-based drivers, the stream interface driver must create registry entries that enable the device to be detected. For more information, see Registry Keys for Display Drivers.
Last updated on Tuesday, July 13, 2004