Device IDs are unique ASCII strings that are created by enumerators to identify a hardware device. IDs are made up of three distinct parts, separated by a backslash. The first part of the ID identifies the enumerator that created the ID. The second part is the ID itself.
If this part of the string begins with an asterisk ("*"), this is an EISA-format ID, which are three letters followed by four hexadecimal digits. The 3-letter prefixes are assigned on a per-company basis and hardware vendors must only use those letters assigned to their company, or the PNPxxxx identifiers discussed below. EISA identifiers may be obtained from:
If you are a hardware manufacturer building ISA Plug and Play adapter boards, you are expected to procure your own three letter EISA identifier and assign your own IDs for your hardware. EISA identifiers may be obtained from:
BCPR Services, Inc. < P.O. Box 11137 < Spring, Texas 77391-1137 < (713)251-4770 (phone) < (713)251-4832 (fax)
Many enumerators generate EISA IDs when enumerating devices, and the "*" indicates that the ID comes from this generic pool, thus allowing setup to select the appropriate driver regardless of which enumerator created the ID. An ID that does not start with an "*" will require setup information specific to the enumerator that created the ID to find the appropriate driver. The third part of the ID is a unique instance number for this computer. This is used to distinguish two or more identical devices in a single computer from one another. For example, two COM ports require two unique instances.
Since many devices do not have an EISA ID, Microsoft has defined IDs for every device that Windows 95 supplies drivers for. We have reserved the EISA manufacturer's ID "PNP" and defined a set of IDs for base system components:
Other base system components are numbered in the same way. The complete current list of compatibility IDs is available on Compuserve in the PLUGPLAY forum, under the filename DEVIDS.ZIP.
ISA device IDs have the following form:
ISAPNP\device ID+_DEV0000, 0001, ...\serial number
In this example, device ID is taken from the first four bytes of the card. The entries for _DEV numbers are required only if there are many devices on the card.
The following table gives some sample ISA device IDs:
Device ID | Description |
ISAPNP\FDC0000\00000012 | future domain |
ISAPNP\ADP1522_DEV0000\E8124123 | Adaptec SCSI device (function 0) |
ISAPNP\ADP1522_DEV0001\E8124123 | Adaptec floppy device (function 1) |
For PCMCIA, the device ID is created from tuple information on the card. The goal is to create a unique ID for each card.
The ID is created by concatenating the PCMCIA prefix, the manufacturer-name string, the product-name string, a 16-bit CRC, and the instance value for the card.
PCMCIA\manufacturer_name-product_name-crc\instance
A PCMCIA device identifier might look like the following example:
PCMCIA\MEGAHERTZ-XJ124FM-936B
The CRC is created from the following tuple data:
If the CISTPL_VERS_1 tuple is not available or the manufacturer name is NULL, the string "UNKNOWN_MANUFACTURER" is used for the manufacturer name.
PCMCIA\UNKNOWN_MANUFACTURER_crc\instance
The total length of the device ID string is limited to 128 characters, including the null terminator. The manufacturer and product name are truncated, if necessary, to maintain this length restriction in the ID string.
The characters in the manufacturer and product name strings that are greater than or equal to a space (0x20) or less than (0x7F) will be copied into the name string. Any characters outside this range are skipped. This restriction makes it easier to include these characters in the .INF files for the device.
Many Windows 95 driver models, such as IOS and the network driver models, support dynamically loaded device drivers. These VxDs are not loaded by the MS-DOS real mode loader. In the case of IOS, some drivers are true dynamically loaded VxDs, and others are mini-port SCSI drivers that are Windows NT-binary compatible. IOS loads all drivers dynamically. The process used to load these drivers is identical to the process used to dynamically load the same drivers at run-time, except that the sequence of events that starts the load process is slightly different.
Dynamically loaded drivers are required to have a device loader. A device loader is responsible for loading the drivers at the correct time and in the correct order, and for making the proper initialization calls. In the case of SCSI adapter miniport drivers this device loader is IOS. A typical registry driver section for a SCSI adapter looks something like this:
Enum\ISAPNP\*ABC0507\0A35BF46
DeviceDesc=ABC SCSI Vendor ISA Adapter
Class="SCSIAdapter"
Driver="SCSIAdapter\0000"
System\CurrentControlSet\Services\Class\ScsiAdapter\0000
DevLoader=*IOS
MiniPortDriver=ABC.MPD
Since there is no StaticVxD=xxx line in this registry entry, the VMM32 real mode loader will do nothing when the ISAPNP enumerator identifies this device. IOS is a statically loaded base driver; it receives a Device_Init system control message. During this message, IOS calls Configuration Manager to load any drivers that have a DevLoader=IOS entry by calling CONFIGMG_Register_DevLoader with the following parameters:
CM_Register_DevLoader(IOS_DDB, 0);
From within this function, Configuration Manager walks the devnode tree and attempts to find any device node that has a DevLoader=IOS entry in the registry. In this example, it would find the ABC adapter. This causes Configuration Manager to call back to IOS with a system control call to load the driver.
DirectedSysControl("IOS", PNP_NEW_DEVNODE, DLVXD_LOAD_DEVLOADER, LoadDevNode)
IOS then examines the registry and finds the MiniPortDriver=ABC.MPT, loads the driver and any associated support drivers, initializes the adapter, and returns from the function.
A new callback entry point is the most significant Plug and Play work required for new device drivers. This entry point is used by Configuration Manager to assign configurations. For sample code showing this entry point, see Sample Plug and Play Driver.
Most VxDs simply call CM_Register_Device_Driver to get their configuration. The VxD's entry point must be able to respond to dynamic configuration calls, particularly CONFIG_START, CONFIG_STOP, CONFIG_TEST, and CONFIG_REMOVE.