I'm curious how the windows device manager obtains the hardware IDs for a device, even though no device driver may be loaded for the device yet. Anybody have a clue on how Windows goes on about this?
On a related note, I am interested in supporting language localization for the software we are writing; is it possible for a device and/or driver to report back its friendly name and description in a localized fashion? Is there a common practice for this already?
Thanks for your time.
The top level process is called enumeration. Most modern device buses support a mechanism that lets the OS query the buss and determine what devices are connected to the bus.
The PCI family of buses all support enumeration. The PCI bus has a special enumeration space just for this. This is where "Plug-n-Play" ID's come from.
The device id's uniquely identify a device on the bus and enable the OS to find the correct driver for that device.
Other buses, including USB and FireWire have enumeration strategies
Device ID, is a combination of information given from the device. For example, for a USB device, the string is based on the VID and PID (Vendor ID and Product ID). Now, this cannot happen if no driver is loaded. Atleast some driver, bus driver would have to be loaded for the OS to get the Device ID.
Now, for language support, I guess for WDM driver, there is a QUERY_LANG or something, I dont remember properly, alternatively some devices like USB, have Language ID support. This language ID determines the language of the Product descriptor string.
First, to understand the order of drivers being loaded, you're recommended to switch the Device Manager into View | Devices by Connection mode.
As you would notice, the devices are located below their bus driver. For PCI devices, it'll be "PCI bus". For USB devices, it would be their USB hub. Each bus driver has its own idea about how the identifier strings should be formatted:
It returns them in response to IRP_MN_QUERY_ID (BusQueryInstanceID, BusQueryHardwareIDs, BusQueryCompatibleIDs) and IRP_MN_QUERY_DEVICE_TEXT (DeviceTextDescription, DeviceTextLocationInformation etc.)
Of course, since the bus driver enumerated the devices (i.e. created the child devices you're seeing) in the first place (through whatever standard interface appropriate for the bus; e.g. 'Get Device/String Descriptor' on USB), it knows their vendor ID, product ID etc.
The device's driver does not have to be loaded at this time. In fact, it can't be loaded. The device IDs are precisely what instructs the PnP system as to which driver matches the device.
As to localization:
Unlike IRP_MN_QUERY_ID, which provides opaque strings intended for device matching, the IRP_MN_QUERY_DEVICE_TEXT information was indeed intended to be localized. For that purpose, you receive the requested Locale ID (LCID) in the input data (Parameters.QueryDeviceText.LocaleId).
[As Alphaneo noted, a USB hub driver might pass this LCID onwards to the USB device (within a Get String Descriptor request), hoping that the USB device itself has localized strings.]