Microsoft Corporation
September 1997
The Microsoft® Windows NT® version 5.0 operating system will include enhancements to simplify device-driver development and device management. These enhancements include support for low-level instrumentation, power management, and Plug and Play (the subject of this article).
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.
Support for Plug and Play was first provided in the Microsoft Windows® 95 operating system; however, 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 (ACPI) Version 1.0 specification 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 Microsoft Windows 95, the Windows NT 5.0 Plug and Play implementation does not rely on an Advanced Power Management (APM) BIOS or a Plug and Play BIOS. These two Basic Input/Output System (BIOS) implementations were designed for Windows 95 as early attempts to support Plug and Play and power management; they will be maintained in the next version of Windows (code-named Memphis) for backward compatibility only. ACPI provides these services for both Windows NT 5.0 and Memphis.
The primary design goal of Plug and Play is to further the industry initiative to simplify personal computers for end users. Beyond that, Windows NT 5.0 Plug and Play is designed to:
In Windows NT 5.0, 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 Win32® Driver Model (WDM), which also supports power management and other new capabilities that can be configured and controlled by the operating system.
To incorporate Plug and Play support into Windows NT 5.0, 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 NT 5.0 will support legacy Windows NT drivers, but these will have no Plug and Play and 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 NT and Memphis 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 NT 5.0. The beta releases of the Windows NT 5.0 Device Driver Kit (DDK) will document the actual driver modifications required to allow current drivers to work in a Windows NT 5.0 Plug and Play system.
A Plug and Play system requires the combined interaction of the personal computer's BIOS, hardware components, device drivers, and operating system software. The basic system board implementation and BIOS support required for Plug and Play support under Windows NT 5.0 are defined in the ACPI specification. Both Windows NT 5.0 and the Memphis operating system 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 personal computer's Plug and Play and power-management features. Note 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, Version 1.0, PCI Local Bus Specification, Revision 2.1, or PCMCIA standards, and in the Plug and Play specifications. (See the References section at the end of this article for locations of all specifications.)
Windows NT 5.0 provides the following support for Plug and Play:
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. Plug and Play Support Options
| Plug and Play Driver | Non–Plug and Play Driver | |
| Plug and Play Device | Full Plug and Play | No Plug and Play |
| Non–Plug and Play Device | Possible partial Plug and Play | No Plug and Play |
As Table 1 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:
Kernel-mode functionality in Windows NT 5.0 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.
Figure 1. Windows NT 5.0 Plug and Play architecture
Plug and Play modules shown in Figure 1 are described at length in the following sections.
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.
The Power Manager is the kernel-mode component that works in combination with the Policy Manager to handle power management APIs, coordinates power events, and generates 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.
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 NT 5.0 include the I/O manager, a Plug and Play driver can be manually installed on Windows NT 4.0 and can function as a Windows NT 5.0 Plug and Play driver.
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 the "Introduction to Plug and Play" Help file in the Memphis DDK Preview.
From 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 nonlinear 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.
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.
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.
Windows NT 5.0 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 NT–specific capabilities that are not provided under WDM.
Notice that a driver that supports features specific to Windows NT is no longer compatible with Memphis. If a driver will be used under both Windows NT and Memphis, only WDM interfaces can be used.
Bus power management and Plug and Play are controlled by WDM bus drivers, which are standard WDM drivers that expose bus capabilities. Note 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 I/O request packets (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 peripheral component interface (PCI), Plug and Play Industry Standard Architecture (ISA), small computer systems interface (SCSI), and Universal Serial Bus (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 dynamic-link library (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 are usually the function driver/minidriver pair and filter drivers discussed 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.
The Windows NT 5.0 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, the Configuration Manager is a virtual device driver (VxD) that exposes these routines as services to both ring 0 and ring 3 components.
In Windows NT 5.0, these routines expose functionality from the user-mode Plug and Play Manager and are exclusively user-mode APIs. The Windows NT 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 NT 5.0 provides APIs that applications can use for customized hardware event management and to create new hardware events.
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 needed in this discussion.
Figure 2. Sample Windows NT 5.0 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.
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.
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.
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.
Note 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 IRPs, it must pass the IRP all the way down the device stack to the PDO and its associated bus driver.
A major factor in the customer experience for Windows NT 5.0 will be the availability of tested, certified Plug and Play device drivers at the time the operating system ships. The list of supported Windows NT Plug and Play drivers will allow us to notify customers of hardware issues that they may encounter during the operating system upgrade. This 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. We recommend 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 and certification.
Look for more information on Plug and Play drivers in the coming Windows NT 5.0 beta 1 DDK and in future articles in the Hardware News Letter.
For more information about device drivers see the Microsoft DDKs for Windows operating systems, including the Network Device/Driver Interface Specification (NDIS documentation), available to Professional-level subscribers of MSDN Library, or visit MSDN Online at (http://www.microsoft.com/msdn/).
Note The Windows NT 5.0 Device Driver Kit, to be supplied with Windows NT 5.0 Beta 1, documents the Plug and Play interfaces and provides background information on Plug and Play, power management, and the Win32 Driver Model. The Windows NT 5.0 DDK will be substantially updated from the Memphis DDK Preview, which provided an early introduction to this material.
For "OnNow and ACPI: Introduction and Specifications," and other related articles on power-management specifications for device and bus classes please see the Microsoft Hardware Development Web site (http://www.microsoft.com/hwdev/hwdev4.htm); on that page select "Design Initiatives," and choose your topic from the drop-down list provided.
For the article "OnNow Power Management and the Win32 Driver Model," see the Microsoft Hardware Development Web site (http://www.microsoft.com/hwdev/pcfuture/onnowwdm.htm).
For Plug and Play specifications, visit the Microsoft Hardware Development Web site section on specifications (http://www.microsoft.com/hwdev/specs/).
For the Advanced Configuration and Power Interface Specification, Version 1.0, visit the ACPI section of the Teleport Internet Services Web site (http://www.teleport.com/~acpi/).
For the PCI Local Bus Specification, Revision 2.1 (PCI 2.1), visit the PCI Web site (http://www.pcisig.com).
For PCMCIA standards, visit the PCMCIA Web site (http://www.pc-card.com).
For the USB Specification, Version 1.0, visit the Universal Serial Bus Implementers Forum Home Page (http://www.usb.org).
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.