Though Windows XP and Windows Server 2003 are based on the Windows NT/2000 kernel, the Plug and Play support provided by these newer operating systems has been further enhanced, improved
Trang 1Registry and Plug and Play Subsystem
At the end of Chapter 1, there was a simple example providing a general understanding of the process used by the system to install new devices and resolve hardware conflicts However, this example was overly simplistic and, more importantly, covered the process
of hardware installation only from the user's point of view But what actually happens when the system installs new hardware? What components are required to accomplish this task? How should we configure hardware and resolve hardware conflicts? These are clearly topics of great interest to anyone who is initiating full-scale support for Windows
XP and Windows Server 2003 With the release of Windows 95, Microsoft introduced a new concept for simplifying PC usage: Plug and Play (or PnP) What is Plug and Play? A standard, a specification, or a concept? Actually, Plug and Play is a combination of the general approach to designing PCs and a set of specifications describing the hardware architecture Strictly speaking, it is a combination of the system BIOS, hardware devices, system resources, device drivers, and the operating-system software
All Plug and Play components have the same purpose: to facilitate the automatic
functioning of the PC, peripheral devices, and their drivers, with a minimum of
intervention from the user Users working with systems that meet all Plug and Play
requirements don't have to spend time wondering if a newly installed device will create hardware conflicts with another device The registry provides the basis for developing such a system
The HKEY_LOCAL_MACHINE/HARDWARE registry key contains a description of the system hardware and the relationship between hardware devices and their drivers Before we go any further, you should note that this key is volatile and that all of the information it contains is re-created every time the operating system is booted
The hardware recognizer (Ntdetect.com) collects information related to system hardware, and the OS kernel stores the information under the
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION registry key As the drivers are loading, they pass their information on to the system so that it can associate the
hardware devices and their appropriate drivers The operating system saves this
information under the HKLM\HARDWARE\DEVICEMAP registry key Finally, all the necessary information related to resources for the hardware devices (including ports, DMA addresses, IRQs) is stored under HKLM\HARDWARE\RESOURCEMAP
With the arrival of Windows 2000, two new Executive subsystems were introduced: Plug and Play Manager and Power Manager Plug and Play Manager is integrated with the I/O Manager and doesn't participate in the initialization process However, the drivers are initialized in such a way that Plug and Play drivers recognize some hardware devices
Trang 2Windows NT 4.0, on the other hand, uses only Ntdetect.com to recognize hardware devices, because of its limited Plug and Play support
Though Windows XP and Windows Server 2003 are based on the Windows NT/2000 kernel, the Plug and Play support provided by these newer operating systems has been further enhanced, improved, and optimized The general idea of this design was to
combine the respective advantages of the two lines of Windows products — Windows NT/2000 and Windows Millennium Edition (Windows ME) The approach has been a success, providing greater stability in the OS and delivering better device compatibility
For the moment, Windows XP and Windows Server 2003 include Plug and Play support for hundreds of devices not recognized by Windows 2000, including scanners, cameras, audio devices, storage devices, and media (CDs and DVDs) At the same time, these systems also provide better support for Universal Serial Bus (USB), IEEE 1394,
Peripheral Component Interconnects (PCI), and other buses Improvements introduced in the Plug and Play subsystem have lead to better stability and performance This is
especially true with regard to the device-installation process, which has been streamlined and automated, as shown in the example in Chapter 1 Beside this, power-management support has also been improved, which is of benefit to both desktop and mobile computer users
Plug and Play Historical Overview
Plug and Play is a technology that allows the automatic configuration of the PC and all of the devices installed on the system It allows you to start using newly installed hardware (for example, a sound card or modem) immediately after installation, and without having
to configure the device manually Plug and Play operates at the hardware level, the
operating-system level and in the device drivers and BIOS
The introduction of Plug and Play was the result of cooperation between software and hardware vendors, who created an industrial committee in order to unite their efforts This committee was founded in May of 1993, and initially included three corporations: Microsoft, Intel, and Compaq By the end of 1995, a number of vendors were already producing hundreds of hardware devices complying with this standard
Microsoft® Windows® 95 was the first operating system that implemented Plug and Play support However, since then, PnP standards have undergone a significant evolution, mainly as a result of the efforts of the members of the OnNow industry initiative OnNow
is aimed at identifying a standardized approach to controlling both the operating system and hardware-device configuration The main achievement of OnNow has been the
Advanced Configuration and Power Interface (ACPI) Version 1.0 specification, which
defines the basic interface between the motherboard and the system BIOS This interface
Trang 3expands Plug and Play capabilities, allowing the operating system to control power and provide other extended configuration capabilities
Windows 2000, Windows XP and Windows Server 2003 all provide extended Plug and Play functionality Windows 2000 was the first operating system from the Windows NT family that provided full-featured support for Plug and Play and power management However, those of you who want all of the advantages of Plug and Play and
power-management support need to ensure that both the system BIOS and the computer system
as a whole meet ACPI specification requirements More detailed information concerning this topic will be provided later in this chapter
At present, Plug and Play technologies are defined for USB, IEEE 1394, PCI, ISA, SCSI, ATA, LPT, COM, and Card/CardBus Each Plug and Play device must have the
following capabilities:
Be uniquely identifiable
Be able to provide a list of services that it supports and resources it requires
Be able to identify the driver that supports it
Be able to provide the software capabilities for its configuration
Plug and Play Implementation in Windows 2000, Windows XP, and Windows
Server 2003
Plug and Play systems require interaction between the PC BIOS, hardware components, device drivers, and operating-system software In contrast to all the previous versions of Windows NT, Windows 2000/XP and Windows Server 2003 provide improved reliability and decreased downtime These improvements are the result of an extended range of supported hardware and full-featured Plug and Play support The introduction of all of the new capabilities is part of the Microsoft Zero Administration initiative, which is aimed at minimizing Windows downtime For example, Plug and Play devices can often be
plugged in or removed while Windows is running, and the system detects the change automatically Devices that can be removed while the system is running include any USB device and a number of IEEE 1394
Decreasing the frequency of required reboots is one of the most significant advantages here, as it simplifies the procedure of installing both the operating system and hardware components In most cases, new devices can be added dynamically; that is, without
rebooting the system The Hardware Compatibility List has also been extended
significantly Now, the HCL includes hundreds of new printers, modems, tape devices, floptical drives, and other devices All of this is possible thanks to full-featured Plug and Play support and Power Management features
Trang 4Removing a device from a computer without prior notifying the operating system is
known as a surprise removal Typically, Windows XP and Windows Server 2003 can handle this situation effectively, since device drivers developed according to the Windows
XP/Windows Server 2003 Logo Requirements specification must notify the operating
system when the device is removed For such devices, the removal of the device does not affect the system However, surprise removal is not always recommended Particularly, the surprise removal of some storage devices, modems, and network adapters causes the
operating system to display an Unsafe Removal of Device screen (Fig 5.1), which tells
the user to use the Safe Removal application when unplugging the device the next time The user can manually disable the message for devices that can withstand surprise
removal The Safe Removal application is used to notify the operating system that a device is going to be unplugged, and can be found in the notification area (Fig 5.2), if such a device is installed on the system
Figure 5.1: The Unsafe Removal of Device window
Figure 5.2: To remove a hardware device safely, it is necessary to notify the OS that a device is going to be unplugged using the Safe Removal application, which can be found
in the notification area
Note Some devices must be installed or removed only when the system is turned off When the device requires internal installation on the computer, this is the case Also, if data transfers are in progress while certain devices are removed or if the
Trang 5operating system tries to access particular types of devices that have been removed, data loss, data corruption, or even a system failure might result For example,
surprise removal of a PC Card, a CardBus, or parallel or COM-port devices while the device driver is attempting to write to its ports can freeze the system or cause a STOP error, which requires you to reboot the system
In contrast to Windows 95, Plug and Play implementation in Windows 2000, Windows
XP, and products of the Windows Server 2003 family isn't based on Advanced Power Management (APM) BIOS or Plug and Play BIOS These two legacy Plug and Play functions are supported for backward compatibility only Actual Plug and Play support in Windows 2000, Windows XP and Windows Server 2003 is based on the ACPI interface
Some ACPI-compliant types of system BIOS may cause STOP errors in Windows 2000, Windows XP and Windows Server 2003 To minimize this possibility, Microsoft
developers have included a special function with a text-based phase of the OS installation procedure This capability allows for the disabling or activating of ACPI mode support based on the following lists:
Good BIOS list This list is used for activating ACPI mode for some types of
BIOS' dated earlier than 01/01/1999 If the system BIOS ACPI tables match any entries in the Good BIOS List, ACPI mode will be enabled Microsoft isn't adding any new entries to the "Good BIOS List"
Incompatible BIOS list This list is used to disable the ACPI mode for certain
BIOSs dated 01/01/1999 or later If the system BIOS ACPI tables match any entries in the "Windows Non-Compliant ACPI List", the ACPI mode will be disabled BIOSs are added to this list if they have been found by the Microsoft test teams or the BIOS developers to cause system-stability problems If a system doesn't pass the ACPI Hardware Compatibility Test (HCT), fails to boot, or
doesn't provide minimal functionality operating on Windows 2000, then Microsoft will place the machine's BIOS on the "Windows Non-Compliant ACPI List" The ACPI HCT is available on the Web at
http://www.microsoft.com/hwdev/acpihct.htm
If a system's BIOS isn't on either of these lists, the ACPI mode will be enabled if the BIOS presents itself as an ACPI BIOS that is dated later than 01/01/1999 The date that's used by the operating system is the standard PC-AT date, which is found at F000:FFF5 Note If the ACPI BIOS is detected as non-compliant in the Windows 2000, Windows XP
or Windows Server 2003 pre-setup system check, then the BIOS must be updated to ensure complete Plug and Play and power-management functionality Complete information on this topic is available at http://www.Hardware-Update.com
Trang 6For x86-based systems, there is a significant difference in the way the system BIOS
interacts with the Plug and Play devices For some systems, the BIOS Setup program
contains the Enable Plug and Play operating system option, which affects this
interaction Strictly speaking, this option specifies whether the system BIOS or the
operating system controls the hardware If you have a non-compliant ACPI system or a
non-ACPI system, it is recommended that you set this option to No/Disabled Microsoft
also recommends that you disable this option if you dual-boot Windows XP or Windows
Server 2003 and Windows 9x/ME, especially if the system check for Plug and Play on a
Windows 98/ME ACPI system passes but the system check for Plug and Play on
Windows XP/Windows Server 2003 fails If you have a fully compliant ACPI system (which means that ACPI BIOS is present and ACPI HAL installed), the device resources are assigned by Windows XP/Windows Server 2003, rather than by BIOS settings BIOS
settings are ignored, including the Enable Plug and Play operating system option
Because of this, this BIOS setting can be left as it is However, Microsoft still suggests
the No/Disabled setting as the preferable option
The main idea of Plug and Play implementation is the simplification of PC operation for end users The presence of Plug and Play in Windows 2000, Windows XP and Windows Server 2003 also carries out the following tasks:
Extending the existing Windows NT I/O infrastructure in such a way as to support Plug and Play and power management while providing backward compatibility for existing Plug and Play hardware
Developing common driver interfaces that support Plug and Play and power
management for multiple device classes under Windows 2000/Windows
XP/Windows Server 2003 and Windows 98/ME
Optimizing Plug and Play support for various types of computers, including
portables, desktops, and servers equipped with ACPI-compliant motherboards Additionally, support for Plug and Play drivers is provided by Microsoft Win32® Driver Model, WDM, which also supports power management and other new and extended functions that can be configured and managed by the operating system
ACPI Specification
The Plug and Play system requires the interaction of the system BIOS, its hardware components, device drivers, and the operating system The ACPI specification identifies all the necessary requirements for the motherboard and system BIOS to support Plug and Play in Windows 2000, Windows XP and Windows Server 2003 Both Windows 98/ME and Windows 2000/XP/Windows Server 2003 use this specification as a basis for Plug and Play architecture, according to the requirements of the OnNow initiative
The ACPI specification defines the new interface between the operating system and the hardware components that provide power management and Plug and Play support Notice
Trang 7that all of the methods defined in ACPI are independent of both the operating system and the processor type ACPI defines the interface on the registers level for basic Plug and Play and power management functions It also defines a descriptive interface for
additional hardware functionality This allows developers to implement a whole range of Plug and Play and power management functions for multiple hardware platforms while using the same driver ACPI also provides a general mechanism for managing system events for Plug and Play and power management
Besides ACPI, there are other industrial standards For example, Universal Serial Bus, Version 1.0, PCI Local Bus Specification, Revision 2.1, and PCMCIA
Support Levels for Devices and Drivers
The Plug and Play support level that is provided by a device depends both on the
hardware support for Plug and Play and on the Plug and Play support provided by the device driver This concept is illustrated by the data presented in Table 5.1
Table 5.1: Plug and Play Support Levels for Devices and Drivers
driver
Plug and Play device Full-featured Plug and Play
support
No Plug and Play support
Non-Plug and Play
device
Partial support for Plug and Play No Plug and Play support
As shown in this table, the appropriate driver is necessary for providing complete PnP support A brief description of all possible configurations is given below
Full-featured support — both the device and its driver support Plug and Play To
provide optimum Plug and Play support, the hardware component has to meet the OnNow initiative requirements, including ACPI specification Plug and Play support introduced in Windows 2000, Windows XP and Windows Server 2003 is oriented towards ACPI systems only
Plug and Play device/legacy driver — no Plug and Play support If the device
driver doesn't support Plug and Play, then the Plug and Play device will behave as
a legacy device Notice that this may limit Plug and Play functionality for the whole system
Legacy device/Plug and Play driver — this combination may provide partial Plug and Play support If you have a legacy device that doesn't support Plug and Play at
the hardware level, it may provide limited PnP support if the appropriate Plug and Play driver has been loaded Although this system won't be able to automatically
Trang 8and dynamically detect hardware and load the appropriate drivers, it will be
capable of managing hardware resources This system will also provide the
interface for the driver to interact with the Plug and Play subsystem and register device-notification events If your hardware device has a Plug and Play driver, it will be displayed by the Device Manager The tabs that allow you to configure device properties are available in the Device Manager window
Neither the device nor its driver support Plug and Play: no Plug and Play support
Legacy drivers will function as usual, but they won't support Plug and Play
functions All newly developed drivers should support Plug and Play
As you can see, Plug and Play support depends on both the hardware device and the device driver For example, if you have a manually installed legacy device, you can still gain functionality and provide partial Plug and Play support by installing a Plug and Play driver
Note Windows XP and Windows Server 2003 support Plug and Play for monitors only if the monitor, the display adapter, and the display driver are Plug and Play
Otherwise, the monitor is identified by the system as a default monitor
Plug and Play Architecture in Windows 2000, Windows XP, and Windows Server
2003
The Windows 2000/XP/Windows Server 2003 kernel provides Plug and Play support during booting It provides interfaces to interact with various operating-system
components, such as the Hardware Abstraction Layer (HAL), the Executive subsystem, and device drivers User-mode functions interact with kernel-mode functions, thus
providing the capability for dynamic configuration and interface with all other
components supporting Plug and Play, such as Setup program and Control Panel applets
A schematic representation of PnP architecture in Windows 2000, Windows XP, and Windows Server 2003 is shown in Fig 5.3
Figure 5.3: Plug and Play architecture in Windows 2000, Windows XP, and Windows Server 2003
Trang 9Kernel-Mode Plug and Play Manager
The Kernel-mode Plug and Play Manager supports functions for centralized management and manages bus drivers during enumeration It also supports device drivers, which include adding or starting a new device
For example, Plug and Play Manager queries if the device can be unplugged or removed, and allows the driver of this device to synchronize pending I/O requests with the newly received one The kernel-mode Plug and Play Manager interacts with the user-mode Plug and Play Manager when identifying devices available for these operations
Power Manager and Policy Manager
Power Manager is the kernel-mode component that works together with Policy Manager
to process API calls, coordinate events, and generate I/O Request Packets (IRP) For example, if devices send unplugging requests, Power Manager collects these requests, identifies which of them should be serialized, and generates the appropriate IRPs
Policy Manager monitors system activity and collects integrated status information on the users, applications, and device drivers Under certain conditions (or by direct request), Policy Manager generates IRPs for changing device-driver status
Input/Output Manager
Input/Output Manager provides basic services for device drivers Input/Output Manager
is the kernel-mode component that translates user-mode read and write commands into the appropriate IRPs I/O Manager also manages all of the other basic operating system IRPs These interfaces function the same way as those in Windows NT 4.0
Note Windows XP and Windows Server 2003 enhance the I/O subsystem by adding new APIs that will be available to drivers developed according to the Windows
XP/Windows Server 2003 Logo requirements Device drivers written specially for Windows XP or Windows Server 2003 will take advantage of the new functions, including System Restore (Windows XP systems only) and Volume Snapshot
Service At the same time, Windows XP and Windows Server 2003 provide full backward compatibility with drivers developed for Windows 2000 Notice that, despite the fact that all existing Windows 2000 drivers will work with Windows XP and Windows Server 2003, it is strongly recommended that you check if Windows XP/Windows Server 2003 drivers are available To obtain an updated driver,
contact the device vendor or visit the Windows Update site
WDM Interface for Plug and Play
Trang 10The Input/Output system provides leveled driver architecture This section discusses types of WDM (Win32 Driver Model) drivers, driver levels, and device objects If you are interested in this topic and intend to develop device drivers, you can find all of the necessary information in the documentation supplied with the latest version of Windows DDK
Driver Types
From the Plug and Play system point of view, there are the following types of drivers:
Bus driver — serves the bus controller, adapter, bridge, or any other device that
has child devices Bus drivers are required drivers and are normally supplied by Microsoft Each type of the bus present in the system has its own bus driver
Function driver — this is the main device driver, which provides the operational
interface for the device This 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 set up as a driver/minidriver pair In
these driver pairs, a class driver (usually written by Microsoft) provides the
functions required by all devices of that type and a minidriver (usually written by
the device vendor) provides device-specific functions The Plug and Play Manager loads one function driver for each device
Filter driver — sorts I/O requests for a bus, a device, or a class of devices Filter
drivers are optional, and any number of them can exist placed above or below a function driver and above a bus driver Usually, system original-equipment
manufacturers (OEMs) or independent hardware vendors (IHVs) supply filter drivers
In most cases, lower-level filter drivers modify the behavior of the device hardware For example, a lower-level class filter driver for mouse devices can provide acceleration, performing a non-linear conversion of mouse movement data
Upper-level filter drivers usually provide value-added features for a device For example,
an upper-level device filter driver for a keyboard can enforce additional security checks
Driver Layers
For any 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