The Windows 2000 Device Driver Book: A Guide for Programmers (2nd Edition)

Building upon the intermediate driver strategy described in the last section, Microsoft supplies driver architectures for several types or classes of devices.

• Video drivers

• Printer drivers

• Multimedia drivers

• Network drivers

These architectures conform to the spirit, if not to the letter, of the classifications of the last section. Each architecture is described in more detail in the following sections.

Video Drivers

Video drivers in Windows 2000 present special requirements to the I/O subsystem. Because the graphical interface is constantly exposed to users, the apparent overall speed of the system is judged (often incorrectly) by the performance of this component. Competition among video adaptor hardware vendors has forced aggressive graphic accelerators to be included on high-end boards. The video driver architecture must exploit such hardware when it exists, yet provide full compatibility and capability when it does not. Finally, video drivers have evolved since the 16-bit world of Windows. There is a need to provide as much compatibility as possible with legacy drivers.

The video driver architecture of Windows 2000 is shown in Figure 1. 4. The shaded components are provided with Windows 2000. Vendors of specific display adaptors supply the display driver. Since many display adaptors are designed using common chip sets, the chip set manufacturer supplies the video miniport class driver for its adaptor-manufacturing customers. For example, an ET4000 Miniport driver exists for all adaptors that utilize the ET4000 chip set. The extra hardware surrounding the chip set is driven with adaptor-specific display driver code.

Fundamentally, the video driver architecture differs from the standard I/O architecture in that user applications do not communicate directly with the I/O Manager when requesting drawing services. Instead, user-mode code interacts with a Graphics Device Interface (GDI) component of the kernel.

The GDI implements functions that allow the drawing of lines, shapes, and text in selected fonts. The GDI, therefore, is similar to a high-level driver. In turn, the GDI relies upon the services of the display driver and the I/O Manager to complete its work. Communication between the GDI and display driver is bidirectional. Where speed is paramount, the GDI can invoke functions in the display driver directly, bypassing the I/O Manager altogether. The display driver implements an interface known as the Device Driver Interface (DDI), which consists of functions prefixed with the Drv string. Conversely, the display driver relies on common graphics library routines implemented within the GDI. These GDI routines are known as Graphics Engine calls and are prefixed within the Eng string.

For less time-critical services, the GDI relies upon the traditional layered approach of the Windows 2000 I/O subsystem. The GDI uses the I/O Manager to invoke support routines of the video port and miniport intermediate drivers. An example of a function that would be implemented with port and miniport drivers would be a mode-switch command. Requests made by the I/O Manager of the video port driver are in the standard IRP format. The video port driver converts these IRPs into Video Request Packets (VRPs), which are then sent to and processed by the video miniport driver.

Printer Drivers

Printer drivers differ from standard Windows 2000 drivers in several ways. First, a print job may be directed to a spooling mechanism before being sent to a physical device. Second, the physical device is often connected to a remote machine, thus burdening the spool process with the use of RPC calls. Finally, the different printer stream protocols used by different printer devices (e.g., Postscript and HPCL) burden printer driver authors with yet another layer of integration.

The spooler components are shown in Figure 1.5. If spooling is enabled, an application's print job is first directed to a file by the spooler. The spooler then dequeues jobs as a printer (perhaps in a logical queue) becomes available. Data is passed to a print provider, which then directs the output to a local or remote printer.

The shaded components in Figure 1.5 are supplied with Windows 2000, as are several print providers. The client-side spooler component, winspool.drv or Win32spl.DLL (when remote printing), is simply an RPC-based client stub. It connects with a server-side RPC stub, spoolsv.exe. to implement a spooler API.

The server-side stub code relies on a routing service, spoolss.dll, which connects a specific print provider based on the target printer name. Finally, the print provider acts as an abstract front-end for a specific print server or device. A specific device's job queue is created and managed by the print provider. A single print provider can serve the needs of an entire class of printers. Thus, the print providers supplied with Windows 2000 are usually sufficient to serve the needs of most applications and printers. A local, remote, and Internet print provider are included with Windows 2000.

Different print device characteristics, or perhaps different network protocols, sometimes require that a unique print provider be supplied. For example, Novell supplies a print provider for Windows 2000 that directs output to a NetWare print server.

Whether or not the spooling process is involved in a print job, it is the GDI which must ultimately render an application's drawing command into a printer-specific format. The GDI relies upon the services of the Printer Driver. The Printer Driver components consist of a Printer Graphics DLL and a Printer Interface DLL.

The printer graphics DLL is the component responsible for rendering data for a specific device. Depending on device capabilities, the work involved can range from intense for a bit-oriented device to high-level for a device supporting a full graphics engine (such as Postscript.) NT 4 required that this DLL reside in kernel mode, but the performance advantages of placing this code in the trusted category were not significant enough to outweigh the many disadvantages. In Windows 2000, the printer graphics DLL can reside in either user mode or kernel mode. Flexible configuration and higher system reliability result from placement of this DLL in user mode.

Each function exported by the printer graphics DLL is prefixed with the string Drv. The functions defined are invoked by the GDI when rendering is performed.

The printer interface DLL is responsible for configuration of device-specific parameters by providing a user interface for each device option. For example, a printer with multiple paper trays needs a way for a user to specify a default tray and paper size. The printer interface DLL provides user interfaces by building one or more property sheets. These sheets are a kind of Windows dialog, with standard Windows controls allowing selection of various options.

Multimedia Drivers

To support multimedia devices such as sound cards and TV tuners, Windows 2000 supports a new model known as Kernel Streaming (KS). Kernel Streaming consists of both Functional and Filter Drivers. Applications interact with a KS driver using Methods, Properties, and Events, familiar terms from the COM (Component Object Model) world. These mechanisms apply to four different kinds of KS objects exposed to an application: Filters, Pins, Clocks, and Allocators. Each KS object is exposed to an application as a standard I/O file object.

A filter object (which should not be confused with a filter driver) is the top-level entity exposed to an application performing multimedia operations. For example, an application might open a microphone filter on a sound card.

A pin object is a subobject of a filter. It represents a node (input or output) on a device. For example, the microphone filter might expose a single pin for input. An output pin could then be used to read, or acquire, the digitized signal.

A clock object exposes the real-time clock of a multimedia device, if equipped. The clock object may signal an application with an event when the clock timer expires or ticks.

Allocator objects represent the direct memory interface to a multimedia card. Memory on the card can be allocated or freed using this object.

Windows 2000 includes a generic class driver for streaming devices, Stream.sys. In most cases, it is only necessary to write a mini driver to support a specific device such as an audio card or video camera. The class driver implements the Windows 2000 Kernel Streaming abstraction, while the vendor-supplied mini driver utilizes the class driver's services, including buffer and DMA support, to support device-specific actions.

Network Drivers

Network drivers in Windows 2000 follow the Open Systems Interconnection (OSI) standard of ISO. This is a seven-layer model, with the top layer being the application software and the bottom layer being the physical hardware connection and topology of the network. Network Interface Cards (NIC) provide the hardware interface on most platforms for a given network. NIC drivers are written to support a specific device and Windows 2000 ships with popular NIC driver types. Separately, the OSI transport layer (the fourth layer up within the model) is provided by protocol drivers. It is possible to bind different protocols to the same physical NIC driver.

A Network Driver Interface Specification (NDIS) provides library support for NIC drivers that usually permits a NIC vendor to supply only an NDIS miniport driver to manage hardware specifics. Higher layers of NDIS, the NDIS intermediate driver and the NDIS protocol driver, provide media translations, filtering, and media-specific actions when required. The layering of NDIS is shown in Figure 1.6.

Windows 2000 includes a layer of kernel-mode software known as the Transport Driver Interface (TDI). This layer interfaces between the NDIS layer and higher-level software abstractions such as sockets and NetBIOS. The TDI layer makes the construction of Windows 2000 components such as the NetBIOS redirector and server easier and more portable.