SCSI Drivers
The Windows NT SCSI architecture uses layered drivers to separate the management of specific devices from the control of the SCSI host bus adapter (HBA) itself. Figure 1.5 shows the components of the Windows NT SCSI architecture.
SCSI port and miniport drivers — The port driver is a Microsoft-supplied component that acts as an interface between a SCSI miniport driver and the operating system. By handling common SCSI grunt work and hiding the details of the local operating system, the SCSI port driver makes it easier to write drivers for new SCSI HBAs. It also reduces the overall size of a miniport and makes it easier to move the miniport to other operating systems (like Windows 95). SCSI miniports supply the port driver with routines that perform any HBA-specific control operations. Generally, the only people writing SCSI miniport drivers are HBA vendors who want to sell their products in the Windows NT marketplace.
SCSI class drivers — Class drivers manage all the SCSI devices of a particular type, regardless of what HBA they’re attached to. For example, there are SCSI class drivers for tapes, disks, and CD-ROM drives. Separating device control from HBA control makes it possible to mix and match SCSI devices and adapters from different vendors. If you have a device that attaches to a SCSI bus, this is the only kind of driver you’ll need to write.
SCSI filter drivers — Filters are optional SCSI components that intercept and modify requests sent to a SCSI class driver. This allows you to take advantage of existing class driver capabilities without writing everything from scratch. Filters are useful if you’re developing a class driver for hardware that’s similar to some other device.
Network Drivers
In an effort to get better performance, many of the networking components in Windows NT are implemented as kernel-mode drivers. As you can see from Figure 1.6, Windows NT uses driver layering to disengage network protocol management from actual network data transfers. The result is much greater flexibility and support for a wider range of network protocols and hardware.
Network interface card (NIC) drivers — At the bottom of the stack are the NIC drivers that manage the actual networking hardware. NIC drivers present a standard interface at their top edge that allows higher-level drivers to send and receive packets, to reset or halt the NIC, and to query and set the characteristics of the NIC. The interface to a NIC driver is defined by the network driver interface specification (NDIS).
NDIS NIC drivers rely heavily on the services provided by the NDIS interface library. This library (sometimes referred to as the NDIS wrapper) handles many of the nasty details involved in managing asynchronous communications across a network. The NDIS library also exports a complete set of kernel-mode system functions so that a properly written NDIS driver doesn’t need to deal with the operating system.
Based on the amount of help they get from the NDIS interface library, you can classify NIC drivers as either miniports or full drivers. NIC miniports perform only those hardware-specific operations needed to manage a particular NIC. Code in the NDIS library takes care of issues common to all NIC miniports such as synchronization, notification of packet arrival, and queuing of outgoing packets. This is the preferred type of NIC driver for any new hardware.
By comparison, full NIC drivers do almost everything on their own. This makes them much harder to write and debug and often slower than NIC miniports. Originally introduced in the first release of Windows NT, full NIC drivers are supported only to maintain backward compatibility. No one in their right mind is developing full NIC drivers anymore.
NDIS intermediate drivers — Version 4.0 of NDIS (the one included with Windows NT 4.0) includes a new kind of component: the NDIS intermediate driver. NDIS intermediate drivers are sandwiched between transport drivers and NDIS NIC miniports. To the transport driver, they appear to be NDIS miniports while to the NIC driver they look like transport drivers.
NDIS intermediate layers are useful if you have a legacy transport driver and you want to connect it to some new type of media unknown to the transport driver. In this situation, the intermediate driver performs any necessary translations between the transport driver and the NIC miniport managing the new media.
Transport drivers — A transport driver is responsible for implementing a specific network protocol such as TCP/IP or IPX/SPX. It is independent of the underlying network hardware and uses NDIS NIC or intermediate drivers to transfer packets over one or more physical network connections.
All Windows NT transport drivers offer their services to kernel-mode networking clients through the transport driver interface (TDI). The TDI specification defines a low-level interface that supports both connection-based and connectionless (i.e., datagram) protocols. Having all transport drivers expose a single, common interface simplifies the development of both the transport drivers and the clients they support.
Kernel-mode networking clients — Various kernel-mode components that access the network use the TDI interface to communicate with protocol drivers. These kernel-mode TDI clients fall into two broad categories: First, there are system components whose operation is transparent to user-mode applications. One example would be the Server and Redirector that handle requests for remote file access.
The other kind of TDI client is an emulator that exposes some well-known programming interface. User-mode applications access the network through one of these standard APIs rather than working directly with TDI. This approach makes it easier to port existing software to Windows NT and prevents the needless proliferation of networking APIs. Windows NT currently supports interfaces for sockets, NetBIOS calls, named pipes, and mailslots.
SPECIAL DRIVER ARCHITECTURES
Along with the relatively straightforward kernel-mode drivers described in section 1.2, Windows NT depends on a number of very specialized driver architectures. The following subsections describe each of them in detail.
Video Drivers
Video support in Windows NT is complicated by the fact that Win32 applications can use three different graphics APIs. First, there’s the graphical device interface (GDI). This API provides a set of device-independent rendering functions for generating two-dimensional output on display or hardcopy devices. Most Win32 applications use this programming interface because it simplifies the task of producing identical display and printer output.
For programs that need to produce three-dimensional graphics, Win32 also supports the OpenGL API. These functions generate the kind of high-quality output needed by CAD software or scientific visualization tools. In return for the quality of the output, however, the OpenGL API demands a great deal of CPU horsepower or hardware rendering assistance.
Finally, for consumer applications (i.e., games), Windows NT supports a subset of the Direct-Draw API included in Windows 95. DirectDraw is one piece of Microsoft’s DirectX game-programming architecture. Its goal is to give user-mode applications more direct access to video and audio hardware without compromising the integrity of the system.
Supporting multiple APIs on video hardware from multiple vendors is a complex problem. Solving it in a flexible and portable manner requires the interaction of a number of software components. Figure 1.7 shows what they are.
GDI engine — The GDI engine is the key to Windows NT’s device-independent output strategy. This Microsoft-supplied component provides full software rendering support for Win32 GDI calls. In response to a Win32 drawing request, the GDI engine uses the appropriate display or printer driver to generate commands for a specific piece of hardware.
Display drivers — Display drivers are vendor-supplied components that do the actual work of drawing on the display screen. By selectively overriding the rendering functions in the GDI engine, they also give Win32 access to any hardware acceleration features provided by the video card. Along with a display driver for a specific piece of video hardware, vendors need to provide a corresponding video miniport (described below).
DirectDraw HAL — This vendor-supplied component exposes an abstract version of the video hardware. This includes the video frame buffer plus any hardware acceleration mechanisms supported by the DirectDraw API. Any features of the DirectDraw hardware model not supported by the video device are emulated by Microsoft’s DirectDraw software.
Video port and miniport drivers — The main responsibility of these two drivers is to manage state changes in the system’s video hardware. The video port and miniport do not take part in any drawing operations. The work of these drivers includes doing such things as:
Finding and initializing the video controller.
Managing any cursor or pointer hardware located on the video card.
Handling mode-set and palette operations when a full-screen MS-DOS session is running. (This only applies to 80x86 platforms.)
Making the video frame buffer available to user-mode processes.
The video port and miniport are actually a tightly coupled pair of drivers. The port driver is a Microsoft-supplied framework that simplifies the task of writing video drivers. It contains only generic, hardware-independent code that is common to all video drivers.
The miniport is a vendor-supplied driver whose job is to manage a specific type of video card. In response to calls from the video port driver, it is the miniport that actually changes the state of the device. This division of labor between the port and miniport makes it easier to add support for new video cards to Windows NT.
Critical Challenges of ESI & Email Retention Are you storing too much electronic information? Get expert legal advice and better understanding of what you are required to do as an IT professional.
Rev Up Your IT Know-How with Our Recharged Magazine! The improved Windows IT Pro provides trusted IT content with an enhanced new look and functionality! Get comprehensive coverage of industry topics, expert advice, and real-world solutions—PLUS access to over 10,000 articles online. Order today!
Get It All with Windows IT Pro VIP Stock your IT toolbox with every solution ever printed in Windows IT Pro and SQL Server Magazine plus bonus Web-exclusive content on hot topics. Subscribe to receive the VIP CD and a subscription to your choice of Windows IT Pro or SQL Server Magazine!
Order Your Fundamentals CD Today! Gain an introduction to Exchange, learn server security requirements, and understand how unified communications can play a role in your messaging strategies with this free Exchange CD.
Windows IT Pro
Register
