Some of the information in the Windows NT registry is persistent across system boots after it has been set up, particularly information about things like an end user’s graphics display preferences, application-specific environment settings, and so forth.
However, NT reconstructs some of the registry’s configuration information every time the system is loaded so that new drivers, hardware components, and peripheral devices can be added to machines running Windows NT.
In many RISC-based platforms, the ARC firmware provides an execution environment for the system boot loader and gathers configuration information about the hardware components in the machine. In x86-based platforms, a “hardware recognizer” component called NtDetect provides comparable functionality.
These NT boot components “poke” the hardware and/or ROM BIOS in the machine to collect all hardware information that they can about the following:
·The number and type of microprocessors and coprocessors, if any, in the machine
·The firmware caches
·The I/O buses present and the type of interface, such as internal, ISA, EISA, MCA, PCI, etc. for each I/O bus
·The devices detectable on each I/O bus
·The disk, floppy, or CD-ROM from which the operating system is to be loaded
·The monitor on which strings are displayed early in the system boot process and the particular video adapter that controls it at that time
·The keyboard and pointing devices
·The parallel and serial ports
·The network card(s)
The ARC or NtDetect component collects all the hardware information it can find into a tree structure, and the OS loader writes this information into the registry for NT device drivers to use and to supplement when they, in turn, are loaded.
Higher-level NT drivers, which are loaded after device drivers, can consult the registry to get information about already loaded lower drivers and the underlying devices. Still higher-level user-mode drivers at the protected-subsystem level also can use some of the registry information supplied by NT device drivers.
Naturally, NT drivers for different types of peripheral devices use the registry to get and set somewhat device-type-specific information. Every NT driver can get any driver-specific or user-supplied machine-specific parameters that are necessary for the driver to initialize itself. Each NT driver’s parameters are stored in the registry.
Some higher-level NT drivers, such as the NT SCSI class drivers, actually do not get hardware information from the registry when they initialize themselves. Instead, SCSI class drivers get any HBA-specific configuration information from the NT SCSI port driver. As a “lowest-level” NT driver, the NT SCSI port driver does use the registry both to get and to set hardware information about each SCSI HBA in the machine.
In other words, NT device drivers or the NT video and SCSI port drivers on behalf of their respective miniport device drivers can get system-supplied hardware information from the registry, and they must set device-specific hardware configuration information in the registry. Higher-level NT drivers can use the registry information supplied by device drivers, by other lower-level drivers, or by the user as deemed necessary or useful by each driver writer.
An NT device driver also can get I/O bus-specific device configuration information by calling HAL-supplied support routines.
Every NT device driver must claim the bus-relative hardware resources, such as I/O port and memory ranges, interrupt vector/IRQL, and/or DMA channel/port, if any, that its device uses, in the registry when the driver initializes. Claiming a device’s hardware resources in the registry prevents subsequently loaded drivers from accessing an already initialized device adapter/controller and from claiming the same resources as an already loaded driver.
Because NT drivers vary in how they use the registry, this section contains an overview, rather than a device-type-specific or driver-level-specific discussion, of the following topics:
·What registry information is made available to NT drivers when they initialize themselves
·How a typical NT device driver uses information supplied in the registry and/or supplements the hardware configuration information in the registry when the driver is loaded
·How higher-level NT drivers can use system-supplied and device-driver-supplied configuration information contained in the registry