简单的驱动安装，从坛子上某位老兄的帖子里改的

正在做一个项目，一个pci卡驱动，驱动合inf文件已经写好了，原来是手动安装的，现在要改成自动安装，初步的想法是做个dos下的程序，直接抵用inf何sys文件安装得了，从网上找了一段代码，改了改，我采用的方法是直接安装，如果卡没插，就失败，提示请插卡后再试，感觉只要调用UpdateDriverForPlugAndPlayDevices 函数就完事了，我认为代码中的SetupDiGetINFClass（）SetupDiCreateDeviceInfoList（） SetupDiSetDeviceRegistryProperty（） 等函数是用来处理Reinstalling an Unplugged Device 情况下的安装，即这张卡以前装过，现在没有插上，但系统中有此信息，如果安装时需要把那个信息找出来置个标记，以免多次安装。既然我要求先插卡才能安装，所以暂时不考虑这些函数。
  以上是我自己的理解，不知道理解的对不对，还请各位大侠指点。程序比较简陋，临时测试用。代码需要在ddk 命令行方式下编译。

顺便贴一下微软ddk里面写的如何写一个驱动安装应用程序

Writing a Device Installation Application
If your driver package includes drivers and INF files that replace "in-box" drivers and INF files, or if your package includes device-specific applications, it should include a device installation application that installs those components. The device installation application should be invoked by Autorun (described in Platform SDK documentation), so that it starts automatically when a user inserts your distribution disk.

Your driver package must handle two situations:

The user plugs in your hardware before inserting your distribution medium.
The user inserts your distribution medium before plugging in your hardware.
User Plugs in Hardware Before Inserting Distribution Medium
If the user plugs in new hardware before inserting your distribution medium into a drive, there are two scenarios to deal with:

System-supplied in-box drivers support the device.
In this case, Setup automatically installs the device based on INF files and drivers stored on the system disk. The system will not ask the user to insert vendor-supplied distribution media, so if you have provided a distribution medium containing device-specific applications, the applications are not installed at this time.

System-supplied in-box drivers do not support the device.
In this case the Found New Hardware wizard starts executing and asks the user for a distribution medium. When the user inserts the medium, the Autorun-invoked device installation application checks for in-progress installations. Because the Found New Hardware wizard is active, the device installation application should stop itself. The wizard can then search the medium for an appropriate INF file. You can provide a co-installer that installs device-specific applications, as described in Installing Device-Specific Applications.

In either of these cases, the system will also attempt to access the Windows Update Web site to see if newer drivers and INF files are available. If they are, these drivers and INFs will be used instead of those already on the system or on the distribution medium. If the Web site is inaccessible or if no new drivers are available there, the system uses the drivers and INFs available in-box or on the distribution medium (whichever are newer).

Your distribution medium can contain an Autorun-invoked device installation application. When the user inserts your distribution medium, this application will start automatically. Assuming the user inserts the medium after the device has been plugged in and installed, the device installation application can do either or both of the following:

If the system installed the device using in-box drivers, the device installation application can reinstall the device using drivers and INF files supplied on the distribution medium, using UpdateDriverForPlugAndPlayDevices.
If the distribution medium contains device-specific applications, and a co-installer didn't install those applications in response to a DIF_NEWDEVICEWIZARD_FINISHINSTALL function code, the device installation application can use Microsoft? Installer to install them. (Microsoft Installer is described in Platform SDK documentation.)
User Inserts Distribution Medium Before Plugging in Hardware
If the user inserts your distribution medium before plugging in the hardware, an Autorun-invoked device installation application on the medium can:

Check for in-progress installations, and stop executing if other installation activities are in progress.
"Preinstall" driver files and INFs (see Pre-installing Driver Files).
Use Microsoft Installer to install device-specific applications.
If the device is "hot-pluggable," tell the user to plug it in. (If the bus doesn't provide hot-plug notification, initiate reenumeration by calling CM_Reenumerate_DevNode.)
If the device is not hot-pluggable, tell the user to turn the system off, plug in the device, and turn the system back on.
Determining Whether the Device Is Plugged In
Note that the behavior of an Autorun-invoked device installation application must depend on whether the user plugs in the hardware first or inserts the distribution medium first. Since vendors typically provide one distribution disk, and a disk can only have one Autorun-invoked application, your Autorun-invoked device installation application must determine if your device has been plugged in.

To determine if a device is plugged in, the application can call the UpdateDriverForPlugAndPlayDevices function, passing the hardware ID of the device. The device is plugged in if:

the function returns TRUE. (This also installs the driver for the device.)
the function returns FALSE and the Win32 GetLastError function returns NO_ERROR. (No installation occurs.)
The device is not plugged in if the function returns FALSE and GetLastError returns NO_SUCH_DEVINST. (No installation occurs.)

Reinstalling an Unplugged Device
When a device that formerly was attached has been unplugged, the device's devnode remains in the system, although it is both inactive and hidden. Before you can reinstall such a device, you must first find this "phantom" devnode, and mark it as needing reinstallation. Then, when the device is plugged back in, Plug and Play will reenumerate the device, find the new driver for it, and install the driver for the device.

To reinstall an unplugged device:

Call the SetupCopyOEMInf function (described in the Platform SDK documentation).
The SetupCopyOEMInf function ensures that the correct INF file is present in the %windir%\inf directory.

Find the unplugged devices.
Call the SetupDiGetClassDevs function. In the call to this function, clear the DIGCF_PRESENT flag in the Flags parameter. You need to find all devices, not just those that are present. You can narrow the results of your search by specifying the particular device class in the ClassGuid parameter.

Find the hardware IDs and compatible IDs of unplugged devices.
SetupDiGetClassDevs returns a handle to the device information set that contains all installed devices, whether plugged in or not, in the device class (assuming that you specified a device class in the first step). By making successive calls to the SetupDiEnumDeviceInfo function, you can use this handle to enumerate all of the devices in the device information set. Each call provides you with an SP_DEVINFO_DATA structure for the device. To get the list of hardware IDs, call the SetupDiGetDeviceRegistryProperty function with the Property parameter set to SPDRP_HARDWAREID. To get the list of the compatible IDs, call the same function, but with the Property parameter set to SPDRP_COMPATIBLEIDS. Both lists are MULTI-SZ strings.

Look for a match between the ID of your device and the hardware IDs (or compatible IDs) of the previous step.
Make sure that you perform full string comparisons between the hardware ID/compatible ID and the ID for your device. A partial comparison can lead to inappropriate matches.

When you find a match, call the CM_Get_DevNode_Status function, passing SP_DRVINFO_DATA.DevInst in the dnDevInst parameter. If this function returns CR_NO_SUCH_DEVINST, that confirms that the device is unattached (that is, has a phantom devnode).

Mark the device.
Call the SetupDiGetDeviceRegistryProperty function with the Property parameter set to SPDRP_CONFIGFLAGS. When this function returns, the PropertyBuffer parameter points to the device's ConfigFlags value from the registry. Perform a bitwise OR of this value with CONFIGFLAG_REINSTALL (defined in regstr.h). After doing this, call the SetupDiSetDeviceRegistryProperty function, passing SPDRP_CONFIGFLAGS. This action modifies the registry's ConfigFlags value to incorporate the CONFIGFLAG_REINSTALL flag. This causes the device to be reinstalled the next time the device is reenumerated.

Plug in the device.
Plug and Play will reenumerate the device, find the new driver for it, and install that driver.


Pre-installing Driver Files
To preinstall driver files, your device installation application should follow these steps:

On the target system, create a directory for the driver files. If your device installation application installs an application, the driver files should be stored in a subdirectory of the application directory.
Copy all files in the driver package from the distribution media to the directory created in Step 1. The driver package includes the driver or drivers, the INF file, the catalog file, and so forth.
Call SetupCopyOEMInf (described in Platform SDK documentation), specifying the INF file in the directory created in Step 1. Specify SPOST_PATH for the OEMSourceMediaType parameter and specify NULL for the OEMSourceMediaLocation parameter. SetupCopyOEMInf copies the INF file for the driver package into the %windir%\Inf directory on the target system and directs SetupAPI to store the source location of the INF file in its list of preprocessed INF files. SetupCopyOEMInf also processes the catalog file, so the PnP Manager will install the driver the next time it recognizes a device listed in the INF file.
When the user plugs in the device, the PnP Manager recognizes the device, finds the INF file copied by SetupCopyOEMInf, and installs the drivers copied in Step 2. (For more information about copying INF files, see Copying INFs.)

Installing Device-Specific Applications
If your distribution medium includes device-specific applications, the medium should include two methods for installing those applications:

A device-specific co-installer that installs the device-specific applications when it receives the DIF_NEWDEVICEWIZARD_FINISHINSTALL function code.
If the user plugs in the device before inserting the distribution medium, and the device is not supported by in-box drivers, Setup calls the co-installer during the installation process. The co-installer should determine if the device-specific applications have already been installed and if they have not, it should install them. For more information, see Writing a Co-installer.

A device installation application that uses Windows Installer to install the device-specific applications.
If the user inserts the distribution medium before plugging in the device, the medium's Autorun-invoked device installation application should determine if the device-specific applications have already been installed and if they have not, it should install them using Windows Installer. For more information, see the Platform SDK documentation.

Checking for In-Progress Installations
If your device installation application will be invoked by Autorun when the installation CD is inserted, there is another consideration. If your application is meant for use on Windows 2000 and later (but not Windows 95/98/Me), it should determine if other installation activities are in progress before performing its installations. To make this determination, the application should call CMP_WaitNoPendingInstallEvents, typically with a zero time-out value. If the return value from this function indicates other installation activities are pending (for instance, the Found New Hardware wizard might be active), the device installation application should exit.

To make your device installation application compatible with platforms that don't support CMP_WaitNoPendingInstallEvents, the application should include the following code:

BOOL
IsDeviceInstallInProgress (VOID)
{
    HMODULE hModule;
    CMP_WAITNOPENDINGINSTALLEVENTS_PROC pCMP_WaitNoPendingInstallEvents;

    hModule = GetModuleHandle(TEXT("setupapi.dll"));
    if(!hModule)
    {
        // Should never happen since we're linked to SetupAPI, but...
        return FALSE;
    }

    pCMP_WaitNoPendingInstallEvents =
        (CMP_WAITNOPENDINGINSTALLEVENTS_PROC)GetProcAddress(hModule,
                                             "CMP_WaitNoPendingInstallEvents");
    if(!pCMP_WaitNoPendingInstallEvents)
    {
        // We're running on a release of the operating system that doesn't supply this function.
        // Trust the operating system to suppress Autorun when appropriate.
        return FALSE;
    }
    return (pCMP_WaitNoPendingInstallEvents(0) == WAIT_TIMEOUT);
}

int
__cdecl
_tmain(IN int argc, IN PTCHAR argv[])
{
    if(IsDeviceInstallInProgress()) {
        //
        // We don't want to start right now.  Instead, our
        // device co-installer will invoke this application
        // (if necessary) during finish-install processing.
        //
        return -1;
    }
    .
    .
}
Use of this code is based on the premise that if a platform doesn't support CMP_WaitNoPendingInstallEvents, the platform does not invoke Autorun if installation activities are in progress. For a sample usage of this code, see the toaster installation package under the DDK's src/general subdirectory.

Guidelines for Writing Device Installation Applications
Device installation applications must do the following:

Support removal ("uninstall") of all device-specific applications that it installs. As part of that uninstall process, the device installation application should check to see if any associated devices are still present on the system and, if so, warn the user.
Follow the guidelines for installing devices on 64-bit systems.
List all installed applications in Add/Remove Programs, using Microsoft? Windows? Installer (MSI), so the user can uninstall them if desired.
Follow the guidelines for Microsoft? Windows? applications. See the Microsoft Developer Network (MSDN) Web site for more information. (Submit device-specific applications to the appropriate Windows Logo program for software. See the MSDN Web site for more information.)
Device installation applications must not do the following:

Do not instruct the user to copy or overwrite any files, especially .inf and .sys files.
Do not delete the installed driver files from the system during the uninstall operation, even if the hardware has been removed.
Do not force any unnecessary system reboots. Reboots are generally not required for installing PnP devices or software applications. The UpdateDriverForPlugAndPlayDevices function's bRebootRequired parameter indicates the need for a reboot.
Do not use "RunOnce" registry entries to spawn device installation applications, because this requires a system reboot.
Do not use a device or class co-installer, or a class installer, to spawn a device installation application, because the state of the system during device installation cannot be guaranteed to be safe for installing software applications. Specifically, if the device installation application runs on the server side, the system will hang. (However, device installation applications can be spawned from within finish-install wizard pages supplied by class installers or co-installers.)
Do not use the Startup Group to spawn device installation applications.
Do not use win.ini entries to spawn device installation applications.
Do not force the user to install any device-specific applications, unless the device will not operate without the application. Examples might include utilities for setting configurable keyboard keys or for setting a modem's country/region code, if an in-box application does not support such a capability.

文档里面说了几种情况，我简单的归纳了一下。
如果是 硬件已经插上了，直接调用 UpdateDriverForPlugAndPlayDevices 函数 带上inf文件和硬件id作为参数。就可以安装了。
如果没有插硬件，且以前也没装过此驱动，则调用SetupCopyOEMInf 函数，此函数会拷贝inf文件到inf目录。看意思是以后插上硬件后系统就能够自动识别，没试过，猜测而已。
如果以前装过此硬件，现在硬件没插上，需要再次安装的话，通过 SetupDiGetClassDevs 函数找出此机器中所有的此类的所有硬件信息，包括存在的硬件和不存在的以前安装过的。此函数返回一个指向 device information set 结构的句柄。通过这个句柄和 SetupDiEnumDeviceInfo 函数可以枚举每一个硬件信息。这些信息保存在 SP_DEVINFO_DATA  结构中，再通过SetupDiGetDeviceRegistryProperty  函数获取到这些硬件的id。通过此方法找到和你需要安装的硬件相同id的项。再通过CM_Get_DevNode_Status  判断此是否是unattached（按我的理解应该就是以前装的留下的一些记录），然后通过 SetupDiSetDeviceRegistryProperty 函数 置一个 CONFIGFLAG_REINSTALL  位，然后把硬件插上的话是不是系统就会自动安装，我没试过。

 以上是我看了一天ddk的理解。希望其中的错误理解不会误导大家。

多一些讨论，多一份分享！

如果没有插硬件，且以前也没装过此驱动，则调用SetupCopyOEMInf 函数，此函数会拷贝inf文件到inf目录。看意思是以后插上硬件后系统就能够自动识别，没试过，猜测而已。
关注

没错！

好，一个字。就说一次。
<多多交流.......

下载回来研究测试一下，谢谢你的分享！

学习一下。谢谢

引用第4楼qiuzhenqing于2007-08-30 22:20发表的  :
如果没有插硬件，且以前也没装过此驱动，则调用SetupCopyOEMInf 函数，此函数会拷贝inf文件到inf目录。看意思是以后插上硬件后系统就能够自动识别，没试过，猜测而已。
关注

我式了下，用SetupCopyOEMInf拷贝完后，系统还是会提示安装新硬件。
从http://bbs.driverdevelop.com/htm_data/81/0411/81228.html
知道，如果你的驱动不是可信任的，每次换口都有发现新硬件弹出～

dddd