Installing the driver (1)----Driver Pre-installation

The installation of the front toaster driver is installed by manual installation, the Sys/inf and other files to the system. To be honest, this is a complicated process, except the developer, the other people can smooth installation of the driver is really impossible. If the reader has bought computer accessories in Computer city, such as wireless card, Bluetooth adapter, should have the impression: hand in addition to the device itself, will also come with a small CD-ROM and a installation instructions to provide the installation program. Installation instructions generally require you to run the installer and then restart the device before the device can be used normally. This CD is the so-called pre-installation CD, the program is to drive the pre-installation program, which is the topic of this article-the driver pre-installation program.

The WINDDK sample directory Src/setup/devcon provides a pre-installed driver method. After compiling, the driver can be installed by DevCon install Path_to_inffile hwid or by updating the driver by DevCon update Path_to_inffile hwid, which is the latter extension. DevCon Update Call newdev.dll! The UpdateDriverForPlugAndPlayDevices function implements the update of the driver. The path of the incoming INF file and the DeviceID in the INF file are called. However, as described in MS documentation, UpdateDriverForPlugAndPlayDevices can only be updated for devices that already exist, as well as the so-called Hardware-first installation method.

HardwareID [in]    

Take the toaster drive as an example, in the case where the underlying bus driver Busenum.sys has been successfully installed, performing a devcon update will prompt the installation to fail, and the execution DevCon install will successfully pre-install the driver:

C:\studio><span style= "color: #FF0000;" >devcon update</span> C:\studio\toaster\wdm\inf\amd64\simple.inf {b85b7c50-6a01-11d2-b841-00c04fad5171}\ Mstoasterupdating drivers for {b85b7c50-6a01-11d2-b841-00c04fad5171}\mstoaster from C:\STUDIO\TOASTER\WDM\INF\AMD64 \simple.inf.<span style= "color: #FF0000;" >devcon failed.</span>

C:\studio><span style= "color: #FF0000;" >devcon install</span> C:\studio\toaster\wdm\inf\amd64\simple.inf {b85b7c50-6a01-11d2-b841-00c04fad5171} \mstoasterdevice node created. Install is complete when drivers is installed ... Updating drivers for {b85b7c50-6a01-11d2-b841-00c04fad5171}\mstoaster from C:\studio\toaster\wdm\inf\amd64\ Simple.inf.<span style= "color: #FF0000;" >drivers installed successfully.</span>

Shows that the TOASTER device instance is root\toaster\0000 after the DevCon install driver is installed. From the results, although the driver is installed, but is not installed under the Busenum bus, and appears under the root bus, in other words, the toaster drive does not run just quietly squat in the corner; when the real toaster device accesses the system, A driver that is preinstalled by the PNP manager for the device that matches the DevCon install.

Now that UpdateDriverForPlugAndPlayDevices is the Hardware-first installation method, if you run Enum.exe-p 1 (because there is no driver, a yellow exclamation mark will appear under Device Manager unknow Devices), and then install the device driver after the DevCon update mode, also can make the front virtual out of the toaster device to work properly. Before proceeding with the new content, let me summarize the role of the updatedriverforplugandplaydevices function: Essentially, the installation driver relies on the updatedriverforplugandplaydevices function, Executing this function is equivalent to clicking "Scan for hardware changes" on the Device Manager right-click menu. It finds and installs drivers for hardware devices that are currently added to the system but do not already have drivers installed.

The Cmdupdate function described earlier does not implement a driver preinstallation, so let's take a look at its enhanced version----Cmdinstall, which is how to implement a driver pre-installation. The system does not have device information before the device is plugged into the system, so Cmdinstall is doing a virtual device (a virtual device under root) and registering it in the system registry.

Cmdinstall first calls Setupdigetinfclass to obtain the device class GUID from the INF file. The obtained device class GUID is then passed to Setupdicreatedeviceinfolist to create the device information block list and setupdicreatedeviceinfo to create the device information block. This is a good understanding, Windows will attribute similar devices to the same device class, such as USB class, HID class. The system should maintain a list of devices in the device class, and in addition there should be a descriptor like the base class in the object-oriented language that describes the properties of the device class (I guess by the code, after all, the PNP Manager for Windows is not exposed). Now to create a new device under this device class, it is necessary to obtain a descriptor for the device class and add a new device property---The device's HardwareID (just as the derived class has its own properties in addition to the base class's public properties), and then adds a new device to the device class list. Setupdisetdeviceregistryproperty complete the registration of the new equipment. After everything is done, also call the class installer to do similar work when the device class is installed (such as setting up the registry, copying files, etc.), and this action responds to the code by calling Setupdicallclassinstaller. Now that the virtual device already exists, you can call the UpdateDriverForPlugAndPlayDevices update driver. These processes have completed our goal----pre-installed drivers.

The Cmdinstall function is powerful enough to pre-install a bus driver/function driver and a simple filter driver if the INF file provides HardwareID. At the end of this article, the next article discusses the installation of class-filtering drives and multi-layer filter drivers.

Installing the driver (1)----Driver Pre-installation