| 3 | SERVICE_ERROR_CRITICAL | Log error. Try last known good configuration. If this fails, force a bugcheck. |
The AddService directive may also contain a further field, which specifies a section that is used to install NT event logging registries. I found that this did not work in the Beta 2 version of Windows 2000.
Several other entries may appear in a Services section that let you insert further registry entries. Some of these are used to determine the load order of drivers that are auto-started, as described in the following text.
Locating Drivers
The Windows New Device Wizard is called into action whenever a new device is found: on power up, when a hot-pluggable device is installed, or when a device is installed from the Control Panel. It scans through all the available INF files trying to find an appropriate driver.
Windows uses the device
The Hardware and Compatible IDs that an INF file supports are listed for each product in a manufacturer's Models section. Each product is defined in a line in this section, as follows.
device_description=
The device_description is displayed to the user. install is the name of the section with the installation instructions. One hardware_id and zero or more compatible_ids can then be given.
In the Wdm1 INF file, only one Hardware ID is given, *wdmBookWdm1. For Unknown devices installed from the Control Panel, only a Hardware ID is needed because the device is always installed.
%Wdm1%=Wdm1.Install, *wdmBookWdm1
The rules for selecting a device are quite complicated. By preference, Windows selects a driver for a device whose Hardware IDs match. Otherwise, it selects the driver whose Compatible ID best matches the device's Compatible ID, or prompts the user for an alternative driver INF file.
In Windows 2000, if more than one INF file has identical Hardware IDs or Compatible IDs, the Dri
Hardware IDs come in almost any form. They can be *DeviceID, where DeviceID is a three-letter company ID followed by a 4 hex digit device ID. Many Windows Hardware IDs use pnp as the company ID (e.g., *pnp0700 is a standard floppy disk controller).
Other Hardware IDs are in a form specific to the enumerator and often start with an enumerator code and a backslash. Here are typical Hardware IDs.
PCIVEN_1011&DEV_0021 ; DEC 21052 PCI to PCI bridge
USBVID_045E&PID_000B ; Microsoft USB Keyboard
USBVID_046A&PID_0001 ; Cherry USB Keyboard
HIDVID_046A&PID_0001 ; Cherry USB Keyboard
GameportSideWinder3dPro ; Microsoft Sidewinder 3D Pro
PCMCIAACCT0N-EN2212-C817 ; Accton EN2212 Ethernet PCMCIA Adapter
ISAPNPICI1995 ; CoreLogic NetViper-100 ISDN Adapter
These Hardware IDs often include the vendor code and a device or product ID. These Hardware IDs can come in versions that are more specific. For example, USB devices can have REV_ revision numbers, MC_ multi-configuration IDs or MI_ multi-interface numbers added to the basic Hardware ID. Complicated rules apply if a USB device has more than one configuration or interface[27]. In a simple case, if you produce a new driver for your version two USB device, use REV_ in the Hardware ID to specify the latest driver. Make sure that the most desirable Hardware ID appears first in the Models list.
[models]
%USBDevice_V2%=V2Install,USBVID_ABCD&PID_EF01&REV_0002
%USBDevice_V1%=V1Install,USBVID_ABCD&PID_EF01
Compatible IDs are used if a matching Hardware ID is not found. If a suitable driver is not found for a device's Hardware ID, its Compatible ID is used in the lookup process. A standard driver might be able to control this device. If the Compatible IDs match, the standard driver is used.
Compatible IDs are primarily used by USB devices. A USB device has a vendor ID and product ID that are used to form its Hardware ID. However, a USB device should also have class, subclass, and protocol information for each interface it supports. For example, a USB HID device has an interface class code of 03 (constant USB_DEVICE_CLASS_HUMAN_INTERFACE). This forms a Compatible ID of USBClass_03.
In Windows 2000, the INPUT.INF file has a line that matches this HID Compatible ID.
%HID.DeviceDesc% = HID_Inst,GENERIC_HID_DEVICE, USBClass_03&SubClass_01,USBClass_03
In Windows 98, this case is caught in HIDDEV.INF.
%USBClass_03%=USBHIDDevice,USBClass_03
When a new USB HID keyboard (with standard capabilities) is attached to the computer, the default installer might not match the keyboard's Hardware ID, but it should match the Compatible ID. The standard HID keyboard driver is used, as described in the two previous cases. The HID USB keyboard should, therefore, install satisfactorily.
When locating a driver for a HID device where the Hardware ID is not recognized, Compatible IDs are not used. Instead, KEYBOARD. INF uses the HID_DEVICE_SYSTEM_KEYBOARD Hardware ID to locate the default driver.
A new device may require several driver-loading steps before it becomes fully operational.
Consider what happens when a Cherry HID USB keyboard is inserted for the first time. The USB class drivers should already be up and running. They will detect the new device and interrogate it to obtain its vendor ID and product ID, along with various class values. The following basic device Hardware ID is formed.
USBVID_046A&PID_0001
In Windows 2000, this Hardware ID is found in INPUT. INF. The installation section prompts the loading of the HID class drivers and the HID USB minidriver.
The HID USB minidriver is loaded for the new device. It generates a new Hardware ID to represent the HID device.
HIDVID_046A&PID_0001
In Windows 2000, this Hardware ID is found in KEYBOARD.INF. The installation section loads the system keyboard driver and the driver that provides the keyboard interface to the HID class drivers.
In Windows 98, the Cherry HID USB keyboard is installed in one step, because the KEYBOARD. INF detects the USBVID_046A&PID_0001 Hardware ID.
NT Style Driver Installation
NT style (non-WDM) kernel mode drivers for NT 3.51, NT 4, and Windows 2000[28] can be installed by hand. This means copying the driver executable to the Windows System32Drivers directory, making the right registry settings and rebooting the system. However, it is far safer to write an installation program to do the job[29].
You need to use the appropriate Win32 function calls to copy files and alter the registry. In addition, you must use the Windows 2000 Service Control Manager functions.
The code in install.cpp (on the book's CD-ROM) shows how to install an NT style driver. This is not a complete Win32 program. You must embed it in your own installation application.
The
install.cpp installs two sets of registry values that I have not mentioned before.
• Event log registry entries are added. See Chapter 13 for details.
• The driver has a Parameters subkey. The values in this subkey are used to control some global features of the driver. You might like to write a Control Panel applet or other control application to let users modify these values.
1. Get the Windows System32 directory using
2. Create the driver service (or stop the existing driver) — see the following.
3. Make the appropriate driver registry key, e.g., HKLMSYSTEMCurrentControlSetServicesAbcDriver using
Set ErrorControl, Start, and Type registry values in the previous key using RegSetValueEx.
If desired, set Group, DependOnGroup, and DependOnService registry values, etc. as described later.
4. If desired, make a Parameters registry key (e.g., HKLMSYSTEMCurrentControlSetServicesAbcDriverParameters) and set any appropriate values.
5. Open the event log registry key at HKLMSYSTEMCurrentControlSetServicesEventLogSystem.
Read the Sources value from this key.
See if your driver is in this list. If not, add your null-terminated driver name to Sources and write it back to the registry.
