All VxDs were loaded under Windows 3.x by the real-mode VxD loader. Windows 95 supports both dynamically loaded drivers and static VxDs. Static VxDs can have a real-mode initialization portion.
Windows 95 has added several new capabilities for statically loaded VxDs:
The VMM32 loader loads VxDs in three distinct steps:
1. Base drivers specified in the registry
2. Static VxDs for devices enumerated by other VxDs
3. Static VxDs specified in SYSTEM.INI
VMM32 examines the registry branch SYSTEM\CurrentControlSet\Services\VxD and enumerates all keys under this branch. ("Enumerate" here refers to the enumeration of registry keys, not to Plug and Play enumeration.) If it finds a value "StaticVxD=", it will load that static VxD and execute its real mode initialization portion. For example:
SYSTEM\CurrentControlSet\Services\VxD\V86MemoryManger
Description=MS-DOS Virtual 8086 Memory Manager
Manufacturer=Microsoft
StaticVxD=*V86MMGR
Start=0
EMMEXCLUDE=E000-EFFF
SYSTEM\CurrentControlSet\Services\VxD\ConfigMG
Description=Plug and Play Configuration Manager
Manufacturer=Microsoft
StaticVxD=*CONFIGMG
Start=0
SYSTEM\CurrentControlSet\Services\VxD\IOServices
Description=IO Services Driver Version 4.0
Manufacturer=Microsoft
StaticVxD=*IOS
Start=0
Entries exist in this section of the registry for every VxD that is not directly associated with any hardware. These drivers used to be specified under [386ENH] in SYSTEM.INI. Examples of these devices are DOSMGR, V86MMGR, Reboot, VMPoll, and BiosXlat.
Device specific information can be stored in the registry under the same key as the driver. In the preceding example, the V86MemoryManager key contains the value EMMEXCLUDE=E000-EFFF, which is a setting specific to the V86MMGR VxD. Any other VxD-specific information can be grouped with the driver it is associated with in the same way. VxDs can use the VMM services _GetRegistryKey or _GetRegistryPath to discern the location from which they were loaded, and then use this information to read any associated values. Although loading VxDs from SYSTEM.INI (and the associated ReadProfileString and WriteProfileString functions) will still be supported for compatibility with older drivers and setup programs, driver writers are encouraged to use this location and load method for new VxDs and associated switch settings.
Most driver writers will not write enumerators. However, most drivers will be loaded as the result of an enumerator identifying a hardware device. Enumerators are also responsible for configuring devices on the relevant bus.
The following sections discuss some specific enumerators.
The root enumerator is part of Configuration Manager. This enumerator contains no special detection logic and relies on the registry to determine whether a device exists. If there is an entry in the registry, the root enumerator assumes that it exists and the appropriate drivers are loaded. This is the method by which old hardware is supported, since it is usually impossible to determine with complete accuracy and safety that a particular ISA card is installed.
The BIOS enumerator is responsible for identifying all hardware devices on the motherboard of the computer. The BIOS enumerator supports the Plug and Play BIOS API which allows all Plug and Play computers to be queried in a common manner.
This enumerator uses the ISA Plug and Play card detection mechanism to detect with complete accuracy and safety any ISA Plug and Play-compliant cards in the system.
This enumerator uses the PCI BIOS and the PCI device configuration space to detect and configure any PCI-compliant cards in the system.
This enumerator uses a Socket Services driver to determine whether a PCMCIA cards is inserted in each socket in the system, and for those which are present, the tuple space of the card is read to identify which card is inserted and what resources are required.
This enumerator queries the EISA CMOS to discern which EISA devices are installed and what resources they consume. This enumerator will not reconfigure EISA devices.
This enumerator follows the Plug & Play COM specification for identifying compliant devices attached to a serial port.
This enumerator uses the IEEE P1284 specification for identifying devices attached to P1284-capable parallel ports.
In Windows 3.x, all VxDs are loaded from the [386ENH] section of SYSTEM.INI. Windows 95 has moved most VxD loading to the registry, in order to better encapsulate driver-specific information and to enable driver loading from automated device enumeration. However, once all drivers have been loaded from the registry, any "device=" lines in SYSTEM.INI will be executed unless the device specified conflicts with a device loaded from the registry. In the case of a conflict, the device specified in the registry takes precedence and the device specified in SYSTEM.INI will not be loaded.