Chapter 7
USB in the Windows World
Introduction
To show how new USB technology is, or maybe just how slowly the various implementations are going, consider that the original outline of this book had this chapter giving a survey and overview of the various USB implementations across the various operating systems. As this book leaves the author’s word processor for the publisher, only Microsoft is providing operating-system support for the Universal Serial Bus. We know that others are working on it, it’s just not available at the time of this writing. Perhaps we can give a thorough overview of all of the operating-system offerings in a subsequent edition of this book.
Microsoft has not disappointed us. They have jumped in with both feet and provided USB support in Windows 95 (when the OSR2 patches are applied), Windows 98, Windows/NT 4.0 (with a service packet applied), and Windows/NT 5.0. You will notice that Microsoft has not supported the Universal Serial Bus in any of the Windows 3.x products, and for good reason. Windows 3.x is years beyond being obsolete, and users should upgrade to Windows 95 or Windows 98 to get full advantage of progressing technology. What is surprising, though, is that Windows/CE is not yet supported. We’re certain, though, that support will be forthcoming.
This chapter will give a high-level overview of how the Universal Serial Bus structure fits into the Windows world. For a detailed discussion of the underpinnings of USB support in Windows, we will point you to the Microsoft documentation included in the Device Driver Developer’s Kit (the DDK) for the various operating systems. After all, this book is about understanding the Universal Serial Bus. It is not intended to be the sole reference for developers of USB software and hardware.
One quick note to help you understand this chapter a little better: we use the generic word Windows to signify all of Windows 95, Windows 98, and Windows/NT versions 4.0 and 5.0. This usage, while not really encouraged by Microsoft, will serve to keep the sentences and meanings clear. At the time of this writing, there are no differences worth mentioning between the various USB implementations.
USB Software Architecture
As you can see in Figure 7–1, Windows separates very distinctly the various software components that make up a USB host. There is the USB client software, consisting of nothing more than device drivers that control the various USB peripheral devices. The client software talks through a well-defined software interface to the root-hub driver. The root-hub driver talks to the Universal Serial Bus driver (the USBD) through the USBD interface (the USBDI). The USBD communicates with the underlying host-controller through a choice of two host-controller drivers. Finally, the host-controller drivers talk directly to the USB physical bus (through the PCI enumerator software, of all things!). So far, this all sounds like the discussion in Chapter 3 on the USB host architecture and, to be fair, it is. Beyond this, though, things become specific to Windows.
Figure 7–1 MS Windows USB Architecture
Like device drivers in the Windows NT environment, the various layers of the USB software stack communicate using a mechanism called I/O Request Packets (or IRPs). A device driver communicates with another device driver by populating the IRP structure with the request it wishes to make (such as “read a USB endpoint”) and passes it to the next lower layer. When the lower layer has satisfied the request, it alerts the original caller. This procedure can be duplicated for as many layers of device drivers as necessary.
While the various layers communicate using IRPs, the actual USB requests are stored in something that Microsoft calls a Universal Serial Bus Request (or URP). The URP merely includes a structure containing fields that the underlying hardware needs in order to format a bus-level transaction to the USB device.
Understanding the inner working of IRPs, URPs, and NT device drivers is far from essential in following the discussions in this chapter. It is pointed out simply to show that there are mechanisms for layered device drivers to communicate between the layers, and that these mechanisms are common across Windows implementations of the USB software stack.
USBD
The Universal Serial Bus Driver (or USBD) is the component in a USB host that manages the “work” of the Universal Serial Bus. The USBD handles all of the protocol work and high-level interrupt handling. Windows defines the USBD in the context of a new device-driver model called the Windows Driver Model (or WDM).
The WDM was first brought to light by Microsoft in 1997 in order to provide a consistent and common device-driver model for certain classes of devices between the various Windows operating systems. Indeed, a WDM device driver written for a Windows 9x platform will run without change (or even recompilation) on a Win/NT 4.0 or 5.0 machine. It seems natural that the first device driver to take advantage of the portability provided by WDM is the USB software stack.
UHCD and OpenHCI
There are two interfaces that the various USB vendors are attempting to bring forward to control the USB host controller in a system and, surprisingly, Microsoft is not taking sides. Microsoft supports both host controller interfaces. These are the Universal Host Controller Driver (or UHCD) and the Open Host Controller Interface (or OpenHCI). The OpenHCI originated at, and is being supported by, Compaq Computer Corporation. Others are using the UHCD. One can only imagine that one of these interfaces will gain widespread acceptance and the other will fade from the scene. For now, though, the USB driver developer in the Windows world has her choice.
The host-controller driver (whichever is controlling the bus) communicates through the host controller to the physical bus. Or so it would seem. Windows places its PCI Bus Enumerator between the host-controller driver and the USB bus. It is the responsibility of the PCI Bus Enumerator to load the appropriate USB system software when it detects the presence of a Universal Serial Bus in the system.
Root-Hub Driver
While the host controller drivers sit beneath the USBD, the root-hub driver sits above it. Remember from our discussions of both the USB host and USB hubs that every host in a USB system contains an integrated, controlling hub called the USB root hub. By definition, every device on the USB bus is a descendant of this root hub. Microsoft finds it natural to have the client driver software for all attached devices communicate through a Windows-defined USB interface to this root hub’s driver. Another way to do this would be to talk directly to the USBD through the USBDI.
USB Clients
The USB client software, in the form of device drivers, lives just above the root-hub driver. It communicates to the underlying USB software through a well-defined interface called the USB Interface. This is not to be confused with the USBDI is completely Windows specific. Don’t expect your USB drivers for Windows to be portable to other systems. Of course, the same is true for just about every other Windows driver, so it should not be too much of a hardship.
The accompanying table provides a summary of the USB interface functions provided by the Windows USB Interface. A complete discussion of these functions can be found in the various Device Driver Development Kits (DDKs) for each Windows operating system. Additional information may be found on Microsoft’s Web site.
USB Driver Loading
USB devices can contain multiple distinct interfaces, each with its own configuration. Each function contained within a device, and possibly each different configuration, requires its own device driver. This is a generalization, since it is more than possible for a device driver to be written to support multiple functions on a given USB device. You will usually see, however, a single device driver for any particular function. This is an important point to understand, because each device’s configuration must be understood by the system at the time the bus is enumerated.
Each device driver can assist in determining what functions a particular device is supporting, but the device driver can be fully loaded. After all, the proper device driver cannot be loaded until the function of the device is fully understood and enumerated by the lower-layer host software. If it sounds like a “chicken and egg” problem, that’s because it really is. The engineers at Microsoft provided mechanisms to make it all work, and that’s described in their documentation.
The Windows USB software loads a client device driver not for each device as you might expect, but for each interface on a device. Remember that a device can have multiple interfaces that provide completely different functions. For example, a combination USB keyboard and mouse might have a separate interface for the mouse function and the keyboard function. It makes sense that different device drivers would exist for each.
If, during the bus-enumeration process, a device is found for which there is no device driver on the system, then the user is prompted to put one on the system. The user should load one, but if she doesn’t have one (or just doesn’t want to load it yet) then she will be warned that the device is there but is unusable.
USB Enumeration
Windows enumerates the Universal Serial Bus by building a list of objects called physical-device objects (or PDOs in Windows parlance). A PDO is nothing more than a data structure maintained by the operating system. The software operates on these PDOs, as they represent in software the attached USB device.
When the bus-enumeration process is first started, there is only one PDO—the root-hub PDO. The enumeration process then searches the Universal Serial Bus and creates a new PDO for each device it finds. It’s important to note that a device is assigned a PDO in the order it is found; the actual physical layout does not make any difference to the software.
Just as there is a separate device driver for every interface on a device, there is a separate PDO for each device interface. This is illustrated in Figure 7–3, showing a configuration that has one device with three interfaces attached to the root hub.
Figure 7–3 Root-Hub PDO
Figure 7–4 further illustrates the concept of bus enumeration using PDOs. This clearly shows the physical layout of a bus with two hubs, each with two devices attached to the root hub. As the bus is enumerated, the PDOs are created in the order that the devices are scanned and not necessarily in the order that they actually exist. Figure 7–5 shows the PDO list for the physical USB topology shown in Figure 7–4.
Figure 7–4 Example Physical Topology
Figure 7–5 PDO List for Example Topology
User Interface
The Universal Serial Bus was designed to be a truly plug-and-play bus, and it is (at least in the Windows world). Devices are detected as they are plugged in, and the drivers configure themselves based upon the hardware they find. There is really no place for a user interface in a self-detecting, self-configuring environment. True to form, there is no user interface to the core USB components.
There may be, however, some device-driver-specific configuration screens. Such an interface is outside the scope of this book and should be well defined by the vendor that you bought the device from.
All of the bus- and device-configuration information is, however, stored in the systems registry. While you can use registry edit tools to modify these values, it is strongly discouraged. The values are not documented and will typically be implementation and device specific.
Wrapping It Up
In this chapter, we have talked briefly about what Microsoft has given us to “do” USB in the Windows world. They’ve made a very successful attempt at hiding the details of the implementation from all but people who write client software for USB devices. For the most part, in the Windows environment you simply have to plug a USB device in and the rest will be taken care of for you. The Universal Serial Bus is an early step toward true plug-and-play.