Windows 98 provides improved support for hardware devices, including disk devices, display adapters, pointing devices, modems, fax machines, and printers.
In Windows 3.1, device drivers were, for the most part, monolithic and complex to develop. In this case, monolithic means that the driver had to provide all services, user interfaces, API functions, and hardware-access services to operate under Windows 3.1. Starting with Windows 95, and continuing with Windows 98, we provide a universal driver/minidriver architecture that makes driver development easier for hardware vendors. By having the operating system provide basic device services for a given hardware class natively, the vendor is required to provide only device-specific code for their particular hardware. In addition, Windows 98 uses the WDM architecture, which provides a common set of I/O services understood by both Windows 98 and future versions of Windows NT. With WDM, developers can write a single device driver for both operating systems.
A universal driver includes most of the code necessary for devices of a particular class (such as printers or modems) to communicate with the appropriate operating system components (such as the printing or communications subsystems). A minidriver is the relatively small and simple driver that contains any additional instructions needed by a specific device. In many cases, however, the universal driver for a particular category of devices also includes the code needed to operate devices designed to the most common standard for that category. (For example, the Unimodem driver works with all modems supporting AT commands.) The universal driver architecture is shown in Figure 28.2.
Figure 28.2 Universal driver architecture
A virtualization driver (VxD) is a 32-bit, protected-mode driver that manages a system resource, such as a hardware device or installed software, so that more than one application can use the resource at the same time. VxD refers to a general virtualization driver; the x represents the type of device driver. For example, a virtualization driver for a display device is known as a VDD, a virtualization driver for a timer device is a VTD, a virtualization driver for a printer device is a VPD, and so forth.
Windows 98 dynamically loads VxDs —albeit only those that are needed at any given time are loaded into memory. In addition, the new VxDs do not require all of their memory to be page-locked, thereby further increasing the available memory in the system.
VxDs support all hardware devices for a typical computer, including disk controllers, serial and parallel ports, keyboard and display devices, and so on.
While the VxDs dynamically support device drivers, the virtual device keeps track of the status of the device for any application that uses the specific device. Within the Windows 98 environment the ability to switch between multiple applications is commonplace. Each application being used can interrupt the use of a device being used by another open application. Because this interruption can lead to problems with the use of an application trying to access the device, the virtual device checks and manages the state of the device for applications. Furthermore, the virtual device ensures that the device is in the correct mode of operation whenever an application continues. Although most virtual devices manage hardware, some, such as an MS-DOS device driver or a TSR program, manage only installed software. Such virtual devices contain code to emulate the software or ensure that the software uses data that applies only to the currently running application. Also, VxDs are often used to improve software performance.
Note
Windows 98 and Windows 95 virtualization driver files have a file name extension of .vxd; Windows 3.1 drivers used the .386 file name extension.
A Win32 Driver Model (WDM) driver can run under Windows 98 and future versions of Windows NT. WDM uses a layered architecture in which each layer isolates portions of the services required of a device driver. This design also allows hardware vendors to contain all hardware-specific functionality in a single file. Before WDM, device drivers had to include hooks for a particular operating system in addition to the elements necessary to interact with a specific piece of hardware. This nonlayered approach prevented device drivers from being supported across multiple operating systems.
The WDM layered architecture is shown in Figure 28.3.
Figure 28.3 WDM layered architecture
The components of the WDM layered architecture are defined in the following sections.
Device class drivers provide interfaces between different layers of the WDM architecture. The lower layer of a device class driver communicates with the class-specific interface exposed by a device minidriver. The upper edge of the device class driver is specific to the operating system. Device class drivers have the following attributes:
An example of a device class driver is Hidclass.sys. This is the generic layer for such input devices as keyboards, mouse devices, and joysticks.
For more information about device drivers, see Chapter 30, "Hardware Management."
Bus class drivers perform the same function as device class drivers but facilitate the communication between the hardware layer and bus minidrivers. Under Windows 98, WDM supports bus class drivers for the Universal Serial Bus (USB) and the IEEE 1394 bus. An example of a bus class driver is Usbd.sys, for the USB.
For more information about bus drivers, see Chapter 30, "Hardware Management."
Minidrivers were implemented under Windows 95 in the classes of small computer system interface (SCSI) and network adapters. With Windows 98, the concept of minidrivers has been widened to include support for USB, the IEEE 1394 bus, digital audio, DVD players, still imaging, and video capture. Minidrivers either communicate directly with hardware or form the "glue" between two class drivers.
Hardware minidrivers have the following attributes:
Minidrivers that connect class drivers have the following attributes:
An example of a "bridging" minidriver is Hidusb.sys. This Human Interface Device (HID) class minidriver translates HID I/O into request packets that are understood by the USB class driver (Usbd.sys).
For more information about HID, see "Human Interface Device Drivers" later in this chapter and Chapter 30, "Hardware Management."
Though non-portable, virtualization drivers occasionally have a place in the WDM layer, Windows 98 virtualization drivers can allow legacy hardware interfaces to be used with WDM devices. For example, an MS-DOS-based game running on an MS-DOS virtual machine (VM) under Windows 98 might attempt to read a joystick’s position by directly accessing the I/O ports associated with the legacy game port controller. The virtualization driver for HID joystick support would trap these requests and redirect them into the HID class driver. Another use for a VxD is to act as a "mapper" between the Windows 98 VxD architecture and the WDM architecture. For example, Joyhid.vxd forwards HID class driver information on to Vjoyd.vxd. For a detailed example of VxDs in the WDM stack, see "Human Interface Device Drivers" later in this chapter.
For more information about virtualization drivers, see "The Virtualization Driver" earlier in this chapter.
The Win32 Driver Model is implemented in Windows 98 by adding a new layer to the existing device driver architecture. Kernel Services handles device driver access for Windows NT, whereas Ntkern.vxd handles device driver access for Windows 98. Ntkern.vxd abstracts the Windows 98 architecture to look like the Windows NT architecture. This abstraction allows vendors to develop one driver for both operating systems.
For more information about WDM, see Chapter 30, "Hardware Management."
Windows 98 supports the Human Interface Device (HID) class, the standard for input devices, such as keyboards, mouse devices, joysticks, and game pads. Support is based on the HID specification developed by the USB Implementers’ Forum. A HID-compliant device is self-describing, returning function, layout, and usage information. The HID architecture for Windows 98 (implemented with WDM drivers) is shown in Figure 28.4.
Figure 28.4 HID architecture
HID support is provided for USB keyboards, mouse devices, joysticks, and game pads. HID support for USB comes from the HID class minidriver (Hidusb.sys) provided by Microsoft. Game applications can communicate with USB devices by using the Microsoft DirectInput 5.0 COM interfaces.
The following HID modules are shown in Figure 28.4:
Figure 28.5 shows the Windows 98 HID keyboard implementation alongside the USB stack. In this example, the USB controller may be based on either the OpenHCI standard (Openhci.sys) or the Universal HCI standard (Uhci.sys). The system has two keyboards attached, one USB, another PS/2.
Figure 28.5 HID keyboard architecture example (with USB stack)
The WDM layered architecture and the role of "mapper" virtualization drivers (VxDs) is illustrated by considering how Windows 98 keeps the LED states of both keyboards consistent.
A HID report containing the CAPS LOCK HID Usage is passed across the USB bus and progresses up the USB stack. It crosses over to the HID stack through Hidusb.sys and is presented to any driver or application that has the keyboard device open with the HID class driver, Hidclass.sys. In this case, Kbdhid.vxd is listening and translates the HID Usage into a legacy PS/2 SCAN CODE, and injects it into the legacy Vkd.vxd driver for routine processing by User.exe. User.exe eventually will cause Vkd.vxd to transmit a SET LED command to the PS/2 keyboard. Kbdhid.vxd hooks this service and also issues a HID report with the CAPS LOCK LED Usage set. This report propagates down through Hidclass.sys, Hidusb.sys, and the USB driver stack to the keyboard. In the meantime, Vkd.vxd sets the LED on the PS/2 keyboard in its usual way.
In the usual way, the PS/2 SCAN CODE propagates up from Vkd.vxd to User.exe. Eventually, User.exe sends a command to Vkd.vxd to set the LED. This command is noticed by Kbdhid.vxd, because it has the service hooked. It creates a HID report with the CAPS LOCK LED Usage set and writes it to Hidclass.sys, and the report propagates down through Hidusb.sys and the USB driver stack to the keyboard. In the meantime, Vkd.vxd sets the LED on the PS/2 keyboard in its usual way.
Hidvkd.sys does much the same as Kbdhid.vxd, only Hidvkd.sys is looking for the power key scan codes available on newer PS/2 keyboards.
Just as Kbdhid.vxd is needed to connect HID keyboard support with the VxD keyboard subsystem (Vkd.vxd), similar mapping VxDs (as shown in Table 28.2) are needed to enable support for HID mouse devices, joysticks, and so on.
Table 28.2 Virtualization drivers that support HID class devices
| Hidclass.sys device | Windows 98 mapping driver | Windows 98 core driver |
|---|---|---|
| Keyboard | Kbdhid.vxd | Vkd.vxd |
| Mouse device | Mouhid.vxd | Vmouse.vxd |
| Joystick | Joyhid.vxd | Vjoyd.vxd |
For more information about HID, see Chapter 30, "Hardware Management."