Plug and Play for Windows 2000 and Windows XP
On This Page
Introduction
The Microsoft Windows 2000 and Windows XP operating systems include enhancements to simplify device driver development and device management. These enhancements include support for power management, Plug and Play, and low-level hardware instrumentation.
Note: ACL references to Windows 2000 in this paper also apply for Windows XP.
Plug and Play is a combination of hardware and software support that enables a computer system to recognize and adapt to hardware configuration changes with little or no user intervention. With Plug and Play, a user can add or remove devices dynamically, without awkward and confusing manual configuration and without any intricate knowledge of computer hardware.
For example, a user can dock a portable computer and use the docking station's Ethernet card to connect to the network without changing the configuration. Later, the user can undock that same computer and use a modem to connect to the network — again without making any manual configuration changes.
Plug and Play allows a user to change a computer's configuration with the assurance that all devices will work together and that the machine will boot correctly after the changes are made.
Evolution of Plug and Play
Support for Plug and Play was first provided in the Microsoft Windows 95 operating system. Since that time, Plug and Play has evolved dramatically. This evolution is largely a result of the OnNow design initiative, which seeks to define a comprehensive, system-wide approach to controlling system and device configuration and power management.
One product of the OnNow initiative is the Advanced Configuration and Power Interface Specification, Version 1.0 which defines a new system board and BIOS interface that extends Plug and Play data to include power management and other new configuration capabilities, all under complete control of the operating system.
Unlike Plug and Play support in Windows 95, the Windows 2000 Plug and Play implementation does not rely on an Advanced Power Management (APM) BIOS or a Plug and Play BIOS. These two BIOS implementations were designed for Windows 95 as early attempts to support Plug and Play and power management. ACPI provides these services for all versions of Windows later than Windows 95.
The primary design goal of Plug and Play is to further the industry initiative to simplify PCs for end users. Beyond that, Windows 2000 Plug and Play is designed to extend the existing Windows NT I/O infrastructure to support Plug and Play and power management while also supporting industry hardware standards for Plug and Play.
In Windows 2000, Plug and Play support is optimized for laptop, workstation, and server computers that include ACPI system boards. In addition, Plug and Play device driver support for many device classes is provided by the Microsoft Windows Driver Model (WDM), which also supports power management and other new capabilities that can be configured and controlled by the operating system.
Windows 2000 Implementation
To incorporate Plug and Play support into Windows 2000, a native Plug and Play implementation was integrated into the existing Windows NT code base. This results in the following changes for developers who previously created drivers under the Windows NT 4.0 device driver model:
| • | Bus drivers separate from HAL. Bus drivers control an I/O bus, including per-slot functionality that is device-independent. In the new architecture, bus drivers have moved out of the hardware abstraction layer (HAL) to coordinate with changes and extensions made to existing kernel-mode components, such as the Executive, device drivers, and HAL. Bus drivers are generally provided by Microsoft. |
| • | New methods and capabilities available to support device installation and configuration. The new design includes changes and extensions to existing user-mode components, such as the Spooler, class installers, Control Panel applications, and Setup. In addition, new kernel-mode and user-mode Plug and Play-enabled components have been added. |
| • | New Plug and Play APIs used to read and write information from the registry. For the new design, changes and extensions were made to the registry structure. This structure supports Plug and Play and allows the registry to be enhanced in future versions of Windows, while also providing backward compatibility. |
Windows 2000 supports legacy Windows NT drivers, but these legacy drivers have no Plug and Play and no power management functionality. Manufacturers who want to support complete Plug and Play capabilities for their devices and who want the same drivers to function on both Windows 2000 and Windows 98 operating systems will need to develop new drivers that integrate the latest Plug and Play and power management functionality.
This article provides a brief overview of the architecture and design direction for Plug and Play under Windows 2000. The Windows Driver Development Kit (DDK) documents the actual driver modifications required to allow current drivers to work in a Windows Plug and Play system.
Plug and Play Overview
A Plug and Play system requires the combined interaction of the PC's BIOS, hardware components, device drivers, and operating system software. The basic systemboard implementation and BIOS support required for Plug and Play support under Windows are defined in the ACPI specification.
Windows 2000/Windows XP and the Windows 98/ME operating systems use this specification as the basis for their Plug and Play and OnNow architecture.
The ACPI specification defines a new interface between the operating system and the PC's Plug and Play and power management features. Notice that the ACPI methods defined are independent of the actual operating system or CPU.
ACPI specifies a register-level interface to core Plug and Play and power management functions and defines a descriptive interface for additional hardware features. This gives system designers the ability to implement a range of Plug and Play and power management features with different hardware designs while using the same operating system driver. ACPI also provides a generic system-event mechanism for Plug and Play and power management.
In addition to the ACPI specification, other hardware support is defined in industry standards such as Universal Serial Bus, PCI Local Bus Specification PCMCIA standards, and Plug and Play specifications. (See the References section at the end of this article for locations of all specifications.)
System Support for Plug and Play
Windows 2000 provides the following support for Plug and Play:
| • | Automatic and dynamic recognition of installed hardware. This includes initial system installation, recognition of Plug and Play hardware changes that occur between system boots, and response to run-time hardware events such as dock/undock and device insertion/removal. |
| • | Hardware resource allocation (and reallocation). Drivers for Plug and Play devices do not assign their own resources. Instead, the required resources for a device are identified when the device is enumerated by the operating system. The Plug and Play Manager retrieves the requirements for each device during resource allocation. Based on the resource requests each device makes, the Plug and Play Manager assigns the appropriate hardware resources such as I/O ports, interrupt requests (IRQs), direct memory access (DMA) channels, and memory locations. The Plug and Play Manager reconfigures resource assignments when needed, such as when a device is added to the system and requests resources that are already in use. |
| • | Loading of appropriate drivers. The Plug and Play Manager determines which drivers are required to support a particular device and loads those drivers. |
| • | An interface for driver interaction with the Plug and Play system. The interface consists primarily of I/O routines, Plug and Play I/O request packets (IRPs), required driver entry points, and registry information. |
| • | Interaction with power management. One of the key features of both Plug and Play and power management is dynamic handling of events. The addition or removal of a device is an example of such a dynamic event, as is the ability to awaken a device or put it to sleep. Plug and Play and power management both use WDM-based functions and have similar methods for responding to dynamic events. |
| • | Registration for device notification events. Plug and Play enables user-mode code to register for and be notified of certain Plug and Play events. The RegisterDeviceNotification routine allows callers to filter exactly the class or device for which they want to receive notification. This can be specific, such as a file system handle, or general, such as a class of devices. Legacy Windows NT notification methods will continue to work as before. |
Device and Driver Support Levels
The extent to which a device supports Plug and Play depends on the Plug and Play support in both the device hardware and the driver(s) for the device (see Table 1).
Table 1 - Device Driver Support Levels
| Plug and Play driver | Non-Plug and Play driver | |
Plug and Play device | Full Plug and Play support | No Plug and Play support |
Non-Plug and Play device | Possible partial Plug and Play support | No Plug and Play support |
As this table indicates, any device that supports Plug and Play should have Plug and Play support in its driver. The following list expands on the possible configurations:
| • | Plug and Play device and driver — full Plug and Play support. To provide the optimal Plug and Play support, the hardware implementation must comply with the OnNow design initiative, including ACPI. Windows 2000 Plug and Play targets ACPI systems only. |
| • | Plug and Play device/non-Plug and Play driver — no Plug and Play support. If a driver does not support Plug and Play, its device behaves as a non-Plug and Play device regardless of support in the hardware. Note that a non-Plug and Play device can constrain the Plug and Play capabilities of the entire system. |
| • | Non-Plug and Play device/Plug and Play driver — possible partial Plug and Play support. A non-Plug and Play device can have partial Plug and Play support. Although it is not possible for the system to automatically and dynamically recognize the hardware and load the appropriate drivers, it is possible to have Plug and Play manage resource allocation, provide an interface for driver interaction with the Plug and Play system, interact with power management, and register device notification events. Also, if a non-Plug and Play device has a Plug and Play driver, the device will appear in the Device Manager application and property pages will be available for that device. |
| • | Non-Plug and Play device/non-Plug and Play driver — no Plug and Play support. |
Legacy drivers written before Plug and Play was incorporated into the operating system will continue to function as they did previously (without any Plug and Play capability). All new drivers should support Plug and Play.
Windows 2000 Plug and Play Architecture
Kernel-mode functionality in Windows 2000 Plug and Play supports boot-time Plug and Play activity and interfaces with the HAL, Executive, and device drivers. User-mode functionality cooperates with kernel-mode components to provide dynamic configuration and interfaces with other components that need to participate in Plug and Play, such as Setup and Control Panel.
Plug and Play modules shown in Figure 1 are described at length in the following sections.
Figure 1. Windows 2000 Plug and Play Architecture
Kernel-mode Plug and Play Manager
The kernel-mode Plug and Play Manager maintains central control, directing bus drivers to perform enumeration and configuration and directing device drivers to add a device, start a device, and so on.
For example, the Plug and Play Manager can send requests to determine whether a device can be safely paused or removed and to give the device driver a chance to synchronize outstanding I/O requests to the incoming request. The Plug and Play Manager coordinates with the user mode Plug and Play counterpart to pause or remove devices that are available for such actions.
Power Manager and Policy Manager
The Power Manager is the kernel-mode component that works in combination with the Policy Manager to handle power management APIs, coordinate matching power events, and generate power management IRPs. For example, when several devices request to be turned off, the Power Manager collects those requests, determines which requests must be serialized, and then generates appropriate power management IRPs.
The Policy Manager monitors activity in the system and integrates user status, application status, and device driver status into power policy. Under specified circumstances or upon request, the Policy Manager generates IRPs to change device power states.
I/O Manager
The I/O Manager provides core services for device drivers. The I/O Manager is the kernel-mode component that translates user-mode read and write commands into read or write IRPs. It manages all the other main operating system IRPs. These interfaces work as they did in Windows NT 4.0. Note that because both Windows NT 4.0 and Windows 2000 include the I/O Manager, a Windows 2000 Plug and Play driver can be manually installed on Windows NT 4.0 to serve as a Windows NT 4.0 driver, but it will not support Plug and Play or other features specific only to Windows 2000.
WDM Interface for Plug and Play
The I/O system provides a layered architecture for drivers. This section discusses types of WDM drivers, driver layers, and device objects. For a different discussion of the topics covered in this section, see Plug and Play in the Windows DDK.
Driver Types
From the Plug and Play perspective, there are three kinds of drivers:
| • | A bus driver services a bus controller, adapter, bridge, or any device that has child devices. Bus drivers are required drivers and are generally provided by Microsoft. There is one bus driver for each type of bus on a system. |
| • | A function driver is the main device driver and provides the operational interface for its device. It is a required driver unless the device is used raw (an implementation in which I/O is done by the bus driver and any bus filter drivers). The function driver for a device is typically implemented as a driver/minidriver pair. In such driver pairs, a class driver (usually written by Microsoft) provides the functionality required by all devices of that type, and a minidriver (usually written by the device vendor) provides device-specific functionality. The Plug and Play Manager loads one function driver for each device. |
| • | A filter driver sorts I/O requests for a bus, a device, or a class of devices. Filter drivers are optional and can exist in any number, placed above or below a function driver and above a bus driver. Usually, filter drivers are supplied by system original equipment manufacturers (OEMs) or independent hardware vendors (IHVs). |
In most cases, lower-level filter drivers modify the behavior of device hardware. For example, a lower-level class filter driver for mouse devices could provide acceleration, performing a non-linear conversion of mouse movement data.
Upper-level filter drivers usually provide added-value features for a device. For example, an upper-level device filter driver for a keyboard could enforce additional security checks.
Driver Layers
For a given device, there are two or more driver layers: a bus driver for the underlying I/O bus (or the Plug and Play Manager for root-enumerated devices) and a function driver for the device. Optionally, one or more filter drivers can be provided for the bus or device.
Device Objects
A driver creates a device object for each device it controls; the device object represents the device to the driver. From the Plug and Play perspective, there are three kinds of device objects: physical device objects (PDOs), functional device objects (FDOs), and filter device objects. PDOs represent a device on a bus; every Plug and Play API that refers to a device refers to the PDO. FDOs represent the functionality of a device to a function driver. Filter device objects represent a filter driver as a hook to add value. These three kinds of device objects are all of the type DEVICE_OBJECT, but are used differently and can have different device extensions.
Additional Windows NT Interfaces
Windows 2000 Plug and Play drivers are not limited to using the WDM interfaces. Drivers can call other interfaces to support legacy Windows NT drivers, detection, or other Windows 2000-specific capabilities that are not provided under WDM.
Notice that a driver that supports features specific to Windows 2000 is no longer compatible with Windows 98. If a driver will be used under both Windows 2000 and Windows 98, only WDM interfaces can be used.
WDM Bus Drivers
Bus power management and Plug and Play are controlled by WDM bus drivers, which are standard WDM drivers that expose bus capabilities. Notice that in this context, any device from which other devices are enumerated is referred to as a bus. A bus driver responds to new Plug and Play and power management IRPs and can be extended using filter drivers.
The bus driver is primarily responsible for the following:
| • | Enumerating the devices on its bus |
| • | Reporting dynamic events on its bus to the operating system |
| • | Responding to Plug and Play and power management IRPs |
| • | Multiplexing access to the bus (for some buses) |
| • | Generically administering the devices on its bus |
During enumeration, a bus driver identifies the devices on its bus and creates device objects for them. The method a bus driver uses to identify connected devices depends on the particular bus.
A bus driver performs certain operations on behalf of the devices on its bus but usually does not handle reads and writes to the devices on its bus. (A device's function driver handles reads and writes to a device.) A bus driver acts as a function driver for its controller, adapter, bridge, or other device.
Microsoft provides bus drivers for most common buses, including PCI, Plug and Play ISA, SCSI, and USB. Other bus drivers can be provided by IHVs or OEMs. A bus driver can be implemented as a driver/minidriver pair, the way a SCSI port/miniport pair drives a SCSI host adapter. In such driver pairs, one driver is linked to the second driver, and the second driver is a DLL.
The ACPI driver fulfills the role of both bus driver and function driver. ACPI allows the system to learn about devices that either don't have a standard way to enumerate themselves (that is, legacy devices) or are newly defined ACPI devices to be enumerated by ACPI (such as the LID device or the embedded controller device). ACPI also installs upper-level filter drivers for devices that have functionality beyond the standard for their bus. For example, if a PCI bus driver installs a graphics controller with power controls that are not supported by the PCI bus, the device can access its added functionality if the ACPI driver loads an upper-level filter driver for it.
WDM Device Drivers
WDM device drivers fit into the architectural model in the space occupied by the function driver and the filter driver (see the explanations of the function driver/minidriver pair and the filter driver in the WDM Interface for Plug and Play section earlier in this article).
In addition to providing the operational interface for its device, function drivers play an important role in a power-managed system, contributing information as the policy owner for the device about power management capabilities and carrying out actions related to transitions between sleeping and fully on power states.
User-Mode Plug and Play Components
The Windows 2000 user-mode APIs for controlling and configuring devices in a Plug and Play environment are 32-bit extended versions of Windows 95-based Configuration Manager APIs. In Windows 95, Configuration Manager is a virtual device driver (VxD) that exposes these routines as services to both ring 0 and ring 3 components.
In Windows 2000, these routines expose functionality from the user-mode Plug and Play Manager and are exclusively user-mode APIs. The Windows 2000 Setup program installs the drivers and so forth. The 32-bit device installer installation APIs that Setup uses to install drivers are functionally a superset of the Windows 95 SetupxDi routines.
Windows 2000 provides APIs that applications can use for customized hardware event management and to create new hardware events.
Plug and Play Device Tree
The Plug and Play Manager maintains a device tree, viewable through Device Manager, which keeps track of the active devices in the system and information about those devices. The Plug and Play Manager updates the device tree as devices are added and removed or as resources are reallocated. The device tree is hierarchical, with devices on a bus represented as children of the bus adapter or controller. The registry is the central repository for static hardware information. Plug and Play system components and drivers build, maintain, and access new and existing subtrees in the registry.
During enumeration, data for each device is stored under a new HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum key in the registry (this is the enum tree). Plug and Play makes decisions about which device drivers are loaded based on the results of enumeration. Thus, there is an important connection between the enum tree and the services list in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services.
Figure 2 shows a Plug and Play device tree for a hypothetical ACPI system configuration. In practice, a device tree would consist of many additional devices, but Figure 2 shows only the devices necessary for this discussion.
Figure 2. Sample Windows 2000 Plug and Play Device Tree for an ACPI system
In Figure 2, a Local Area Network (LAN) adapter and a USB host controller plug into a PCI bus. A USB hub plugs into the sole port of the USB host controller. From a Plug and Play perspective, the PCI bus controller, the USB host controller, and USB hub are bus devices because they each provide ports. The LAN adapter is not a bus device. The following discussion walks through the steps required to build the device tree shown in Figure 2. The example begins with the objects at the bottom of the stack.
1. | ACPI HAL PDO and FDO. The ACPI HAL is detected during Setup, and the root enumerator creates a PDO for the ACPI HAL. The driver creates an FDO and the ACPI HAL attaches it to the device stack for ACPI (shown by a curved arrow in Figure 2). |
2. | ACPI PDO and FDO. The ACPI HAL enumerates ACPI and creates a PDO for it. The Plug and Play Manager identifies Acpi.sys as the function driver for ACPI, loads the driver, and passes the PDO to the ACPI driver. The ACPI driver creates an FDO for ACPI and attaches it to the device stack for ACPI. |
3. | PCI adapter PDO and FDO. Plug and Play directs the ACPI driver to enumerate ACPI and create a PDO for each device it finds. In Figure 2, a PCI bus controller is found. The Plug and Play Manager identifies the PCI driver (Pci.sys) as the function driver for the PCI controller, loads the PCI driver, and passes the PDO to the PCI driver. The PCI driver creates an FDO for the PCI bus and attaches the FDO to the device stack for the PCI controller. Creating and attaching this FDO are the PCI driver's responsibilities as the function driver for the PCI controller. Note that an IHV can add functionality to a bus by supplying a bus filter driver (not shown in Figure 2). This method is preferred to supplying a custom bus driver. |
4. | LAN adapter and USB host controller PDOs and FDOs. The Plug and Play Manager directs the PCI driver to enumerate the PCI bus. In this example, the PCI bus driver finds a LAN adapter and a USB host controller, and creates PDOs for both devices. The Plug and Play Manager identifies the LAN adapter driver as the function driver for the LAN adapter, loads the driver, and passes the adapter PDO to the LAN adapter driver. The LAN adapter driver creates an FDO for the LAN adapter and attaches the FDO to its device stack. The Plug and Play Manager identifies the USB host controller driver (either Uhcd.sys or Openhci.sys, depending on the chip set used) as the function driver for the USB host controller, loads the driver, and passes the USB host controller driver the USB host controller PDO. The USB host controller driver creates an FDO for the USB host controller and attaches the FDO to its device stack. |
5. | USB hub PDO and FDO. The Plug and Play Manager directs the USB host controller driver to enumerate the USB host controller. In this example, the USB host controller driver finds a USB hub and creates a PDO for it. The Plug and Play Manager identifies the USB hub driver (Usbhub.sys) as the function driver for the USB hub, loads the driver, and passes the USB hub driver the USB hub PDO. The USB hub driver creates an FDO for the USB hub and attaches the FDO to its device stack. Notice that the PDO created by the underlying bus driver is always at the bottom of the device stack for a particular device. When drivers handle Plug and Play and power management IRPs, they must pass the IRP all the way down the device stack to the PDO and its associated bus driver. |
6. | Re-enumeration of devices as a result of a power state change. Systems that go to sleep often cannot detect whether a device has been removed or added while the system was asleep because the hardware circuitry that detects such an event may not be available. When an ACPI system wakes up, the ACPI driver can notify an existing bus driver that there is a device check on its device, providing the signal to the bus driver that it needs to re-enumerate its devices. Good system design provides for selective notification on wake up rather that requiring the entire system to re-enumerate devices. |
Notice that the PDO created by the underlying bus driver is always at the bottom of the device stack for a particular device. When a driver handles a Plug and Play IRP, it must pass the IRP all the way down the device stack to the PDO and its associated bus driver.
Conclusion
A major factor in the customer experience for Windows 2000 will be the availability of tested, certified Plug and Play device drivers at the time the operating system ships.
The list of supported Windows 2000 Plug and Play drivers will allow us to notify customers of hardware issues that they may encounter during the operating system upgrade.
A list of supported hardware will also influence the purchasing decisions of both OEMs and enterprise customers. For these reasons, it is vital that writers of device drivers incorporate Plug and Play and power management functionality into their drivers as soon as possible. Microsoft recommends that you update your drivers to include Plug and Play functionality, and submit these updated drivers to the Microsoft Windows Hardware Quality Lab (WHQL) for testing.
Look for more information on Plug and Play drivers in the Windows DDK.
References
Advanced Configuration and Power Interface Specification:
http://www.acpi.info/ 
Microsoft DDKs for Windows operating systems, including NDIS documentation:
http://www.microsoft.com/whdc/devtools/ddk/default.mspx
Note: The Windows DDK documents the Plug and Play interfaces and provides background information on Plug and Play, power management, and WDM.
OnNow and Power Management: Introduction, related white papers, and power management specifications for device and bus classes:
http://www.microsoft.com/whdc/system/pnppwr/powermgmt/devicepm.mspx
OnNow capabilities and power management:
http://www.microsoft.com/ whdc/ hwdev/ tech/ onnow/ onnowwdm.mspx.
PCI Local Bus Specification:
http://www.pcisig.com
PCMCIA standards:
http://www.pcmcia.org/
Plug and Play specifications:
http://www.microsoft.com/ whdc/ hwdev/ tech/ pnp/default.mspx