Plug and Play for Windows 2000 and Windows XPUpdated: December 4, 2001
On This Page
IntroductionThe 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 PlaySupport 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 ImplementationTo 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:
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 OverviewA 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 PlayWindows 2000 provides the following support for Plug and Play:
Device and Driver Support LevelsThe 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
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:
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 ArchitectureKernel-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 ManagerThe 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 ManagerThe 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 ManagerThe 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 PlayThe 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 TypesFrom the Plug and Play perspective, there are three kinds of drivers:
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 LayersFor 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 ObjectsA 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 InterfacesWindows 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 DriversBus 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:
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 DriversWDM 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 ComponentsThe 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 TreeThe 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.
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. ConclusionA 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: Microsoft DDKs for Windows operating systems, including NDIS documentation: 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: OnNow capabilities and power management:
PCI Local Bus Specification: PCMCIA standards: Plug and Play specifications: |
|
- Related developer sites
- Microsoft Connect
- OSR Online
- Windows Phone
- Other Windows sites
- Enterprise
- Small business
- Students
- Home users
- Essentials
- Recently published
- Debugging
- Samples
- Hardware dashboard
- Support
- Forums
- More support resources
© 2013 Microsoft. All rights reserved.
