All configuration management in the Plug and Play system is directed by the Configuration Manager, which is implemented as a VxD. Configuration Manager manipulates three major data stores:
Configuration Manager works with four major software components:
A device node is the basic in-memory representation of a device that is physically present on the system. This data structure contains information relating to the device and its drivers. The major information stored in a device node is:
Device nodes are created only by enumerators. The creation of a device node causes the appropriate driver to be loaded. Driver writers typically need not concern themselves with creating device nodes or device IDs.
A device ID is a unique ASCII string. This string can be used to cross-reference data about the device stored in the registry. Examples of device IDs are:
For more information about device IDs, see
Drivers examine this portion of the device node to determine which resources have been allocated for the device. For Plug and Play cards, the assigned resources for a given device may change from one boot to the next, or even while the computer is running (dynamically).
Logical configurations describe the various configurations that are valid for a given piece of hardware. Most driver writers will not need to examine or modify the logical configuration list for a given device node. Enumerators are responsible for creating the appropriate logical configurations when they create a device node.
Information about the state of a device, such as whether it is disabled or configured, is maintained by Configuration Manager in each device node. Drivers can query this information.
When a driver is loaded for a specific device node, it registers with Configuration Manager, passing an entry point that will be called to assign or change hardware configurations.
Device nodes that have child nodes will have enumerators. Enumerators are the components of Plug and Play that identify installed hardware and create device nodes. Most driver writers will not need to write an enumerator.
Arbitrators are the components of Plug and Play that assign ownership of various resources, such as IRQs and I/O ports. Most driver writers will not need to write an arbitrator.
The devnode tree is a hierarchical tree of device nodes. Any device node that has an enumerator can create new child device nodes. Any of these child device nodes can have an enumerator that creates further children of that device node. Normally, drivers do not know or care about their exact location within the tree. Drivers typically are only concerned with their own hardware device or device node, and are oblivious to the layers above or below them in the tree.
The devnode tree has two purposes:
1. Describe all hardware that is present in the system.
2. Provide a mechanism for enumerators to configure their children's hardware, allowing bus-independent drivers.
The distinction between the devnode tree and the registry is important. In a fully Plug and Play system, the devnode tree will be an accurate hierarchical representation of the currently installed devices. By contrast, the registry contains information for all devices ever installed (even if they are not currently present) and the location of a device in the registry does not fully reflect the hierarchical structure described in the devnode tree. (In the registry, devices are located beneath their enumerator but all enumerators are kept in a flat list.) The devnode tree exists in memory only, whereas the registry is saved on disk.
The following sample devnode tree shows the device IDs of some typical devices and where in the hierarchy one might expect to find them. The actual contents of each device node other than the device ID are not shown.
Htree\Root\0 - Root node of devnode tree
\Root\*PNP0801\0 - Old-style Sound Blaster compatible sound device
\Root\*PNP0C00\0 - Plug and Play BIOS
\BIOS\*PNP0901\0 - Super VGA compatible display adapter
\BIOS\*PNP0000\0 - AT Interrupt Controller
\BIOS\*PNP0100\0 - AT Timer
\BIOS\*PNP0200\0 - AT DMA Controller
\BIOS\*PNP0301\0 - PS/2 Style Keyboard Contoller
\BIOS\*PNP0400\0 - Standard LPT printer port
\BIOS\*PNP0400\1 - Standard LPT printer port
\BIOS\*PNP0501\0 - 16550 COM port
\BIOS\*PNP0501\1 - 16550 COM port
\BIOS\*PNP0700\0 - PC standard floppy disk controller
\BIOS\*PNP0800\0 - AT style speaker sound
\BIOS\*PNP0901\0 - SVGA compatible display adapter
\BIOS\*PNP0B00\0 - AT Real Time Clock
\BIOS\*PNP0C01\0 - System memory
\BIOS\*PNP0E00\0 - PCMCIA Controller
\PCMCIA\3C08AF\0 - Network adapter
The registry is a system-wide database, accessed in both Windows 95 and Windows NT through the Microsoft Win32® API set. Additionally, Windows 95 provides real-mode access to the registry to allow its use during boot-up prior to the switch to protected mode.
The registry stores a hierarchical tree of "Keys" and "Values," similar to entries in Windows 3.1-format .INI files (except that Windows 3.1 .INI files have a flat structure, as opposed to the tree structure of the registry.) Windows 95 Plug and Play uses the registry to store information about which drivers should be loaded when a particular device is enumerated, as well as such information as the driver revision number, manufacturer, and potential logical configurations of the device.
Most Plug and Play registry entries are stored in the ENUM tree. (That is, \\HKEY_LOCAL_MACHINE\ENUM.) Under ENUM, each enumerator gets its own branch, with one child under the enumerator for each device it has ever enumerated and set up. There is one special enumerator branch called ENUM\ROOT which contains the registry entries for old-style, non-Plug and Play hardware for which there is no enumerator but which can be detected using other means. The Device Installer creates new registry entries when an enumerator detects a device for which there is no registry entry. Most of the information is provided either by the .INF file provided with the device or directly by the device's setup module.
The registry also stores configuration-specific information (that is, information which is relevant to whether a capable portable computer is docked or undocked) as well as user-specific information. For any particular setting, the application or device driver must determine whether it is configuration-aware or user-aware, and write the entries to the registry in the proper location.
General configuration-specific information is stored in the \\HKEY_LOCAL_MACHINE\CONFIG\configname branch of the registry. The rules for storing information in these configuration specific branches should be the same as the rules for their grandparents. Typically, creators and consumers of config- and user-specific information read and write to the predefined keys HKEY_CURRENT_CONFIG\ and HKEY_CURRENT_USER which automatically selects the appropriate subbranch of the CONFIG and HKEY_USERS trees.
Since information about static devices (that is, non-Plug and Play hardware) is stored in \\HKEY_LOCAL_MACHINE\ENUM\ROOT\*, information about static devices that only applies to a particular configuration is stored in: \\HKEY_LOCAL_MACHINE\CONFIG\xxxx\ENUM\ROOT.
ENUM\ROOT\*PNP0000\0000
DrvDesc="Programmable Interrupt Controller"
Class="System"
BootConfig=(I/O ports 20h, 21h, A0h, and A1h - Binary resource data)
Driver="System\0000"
HardwareID="*PNP0000"
InfName="MACHINE.INF"
Mfg="Microsoft"
NoSetupUI="1"
ENUM\BIOS\*PNP0000\0000\LogConfig
0=(Binary resource data, in this case same as BootConfig above)
SYSTEM\CurrentControlSet\Services\Class\System\0000
DriverDesc="Programmable Interrupt Controller"
DevLoader="*VPICD"
EnumPropPages="Sysclass.dll,EnumPropPages"