我们一起讨论把驱动自动安装的问题搞定搞清楚好吗？

我看了一些文章，好像有以下几种方法，但最后都没有给出可以实用的结果，我们大家一起来搞定她好吗？

已有oem6.sys 和一个sys二进制文件。

1。在installshield中添加代码实现：
我试着加了一下代码：
//shuzhi add begin:自动加载驱动程序
if (GetSystemInfo (OS, nvResult, svResult) == 0) then
      if (nvResult==IS_WINDOWS9X) then
          //Windows 9x
 szProgram = \"rundll.exe\";
 szCmdLine = \"setupx.dll,InstallHinfSection   DefaultInstall 132 \" + SRCDIR + \"OEM6.INF\";
 LaunchAppAndWait(szProgram,   szCmdLine, WAIT);    
  else
     //Windows NT / 2000
          szProgram = \"rundll32.exe\";
          szCmdLine = \"setupapi.dll,InstallHinfSection DefaultInstall 132 \" + SRCDIR + \"OEM6.INF\";
          LaunchAppAndWait(szProgram, szCmdLine, WAIT);
       endif;
    endif;
执行完后，我看注册表中并没有加入任何东西，这种方法能行吗？inf文件有没有特殊要求？

2。使用ddk中src下的install程序或者使用devcon这个程序。我用了
devcon这个程序，用
：devcon install d:\\oem6.inf USB\\VID_0547&PID_4a44 老是提示执行不成功。

这两种方法都没有成功。
各位高手大侠多指教，我们菜鸟多多努力！！！！！

请斑竹置顶：）

没有人支持啊，只有自己顶一下了

devcon是什么软件啊？

devcon是一个小程序，可以加载驱动程序，其原理和ntddk源码中的install差不多吧

我现在要做一个在98下自动装猫的程序，一筹莫展啊

关于驱动程序安装，只要你细心看了ddk,就应该知道怎样作
对于即插即用简单地说要对付2种情况
1。在你的设备未安装前，安装驱动程序这叫预先安装。
最简单的方法就是使用SetupCopyOEMInf函数。

具体做法是：
将SetupCopyOEMInf封装在一个动态库里。
用installshield将所有文件copy到一个临时目录。
调用动态库使用SetupCopyOEMInf函数copy临时目录下的inf文件（路径）。
installshield让计算机重启。

插上设备，自动识别。
[编辑 -  4/15/04 by  hglzw]

[编辑 -  4/15/04 by  hglzw]

2.你的设备已安装，弹出安装向导。
很简单，让用户搜索你的安装盘，即可完成安装。

我认为，没有特别必要的情况下，没必要使用coinstall.
对与非即插即用设备，要区别对待。

[编辑 -  4/15/04 by  hglzw]

关于打印机的安装：
非即插即用，如并口。
1。使用添加打印向导，简单的不能再简单了。
2。将AddPrinter,AddPrinterDriver,AddMonitor等封装在动态库。
使用installshield制作安装copy必要的文件到指定的目录。然后调用这个动态库里的这些函数。祥见ddk.

即插即用如usb
和通用即插即用安装方法类似。
ddk里有详细的说明。
重要的一点，在你的固件（firmware),响应IOCTL_GET_DEVICE_ID时
返回IEEE1284兼容的设备ID，格式详见sdk.
关于详细的标准，请查阅usb工作组的设备类规范。


[编辑 -  4/15/04 by  hglzw]

这些是关于即插即用的安装，大多数情况不必修改注册表，对于老式nt的程序则需要。
其实在注册表里添加东西不必大费周张，很简单，installshield就支持对注册表的任意修改。不必用什么函数，即改即用，方便。

关于扫描仪和照相机的安装
1.非即插即用如串口。
a.可以使用安装向导。
b.installshiel或coinstall
2.即插即用如usb
同前面的即插即用安装一样。

扫描仪和照相机多出的是接口数据源的安装，如twaince。





[编辑 -  4/15/04 by  hglzw]

象串口modem这样的设备，使用添加新硬件向导，让系统自动搜索新设备和驱动程序，也能很好的安装。
当然感兴趣的仍可用coinstall。

能说说modem在98下怎么装吗？我已经参考fastinst在98下把modem装上去了，在设备管理器中能看到，在控制面板的modem中也能看到，但在拨号网络中却看不到，这是怎么回事啊？能指点一下吗？？

[编辑 -  4/16/04 by  lxxmmd]

看了hglzw的回复，有的地方还是不清楚。我希望自动安装就是不再让用户去查找Inf文件和sys文件的路径，只用一个exe安装文件完成傻瓜式的操作，就像一些通用驱动一样。

还有，SetupCopyOEMInf这个函数好像98下不支持啊

用devcon install 可以装上，但设备列表里有叹号且要求重启，并且重启后还弹出找到新硬件的对话框，各位大侠们多多指教啊。

刚才去一个国外的网站上看了看，说还要分：
1。先插入硬件再放入安装盘，这时安装程序要能auto run 且能自动更新驱动。
2。先放入安装盘安装再插入硬件。这时好像是用SetupCopyOEMInf。

coinstall是什么意思啊？

我看了一些文章，好像有以下几种方法，但最后都没有给出可以实用的结果，我们大家一起来搞定她好吗？

已有oem6.sys 和一个sys二进制文件。

1。在installshield中添加代码实现：
我试着加了一下代码：
//shuzhi add begin:自动加载驱动程序
if (GetSystemInfo (OS, nvResult, svResult) == 0) then
      if (nvResult==IS_WINDOWS9X) then
          //Windows 9x
 szProgram = \"rundll.exe\";
 szCmdLine = \"setupx.dll,InstallHinfSection   DefaultInstall 132 \" + SRCDIR + \"OEM6.INF\";
 LaunchAppAndWait(szProgram,   szCmdLine, WAIT);    
  else
     //Windows NT / 2000
          szProgram = \"rundll32.exe\";
          szCmdLine = \"setupapi.dll,InstallHinfSection DefaultInstall 132 \" + SRCDIR + \"OEM6.INF\";
          LaunchAppAndWait(szProgram, szCmdLine, WAIT);
       endif;
    endif;
执行完后，我看注册表中并没有加入任何东西，这种方法能行吗？inf文件有没有特殊要求？

2。使用ddk中src下的install程序或者使用devcon这个程序。我用了
devcon这个程序，用
：devcon install d:\\oem6.inf USB\\VID_0547&PID_4a44 老是提示执行不成功。

这两种方法都没有成功。
各位高手大侠多指教，我们菜鸟多多努力！！！！！

请斑竹置顶：）

devcon install d:\\oem6.inf \"USB\\VID_0547&PID_4a44\"

要加上双引号的

谢谢blackeye527
我加上双引号可以了

以下是在msdn中查到的：

MSDN Home >  MSDN Library >  Windows Development >  Device Installation >  Design Guide  
  
Device Installation: Windows 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.


Built on Thursday, March 25, 2004  

有谁搞定了吗？

不知道有没有大虾把这个问题搞定了？
也有朋友来信问我这个问题彻底解决了没有。我也没有彻底解决啊，关键是SetupCopyOEMInf这个函数98下不支持，这个很讨厌。

这段时间有别的任务，这个问题搁了一下。请各位高手大侠多指教！

我不太明白WIN98上为什么要用SetupCopyOEMInf，能不能直接拷贝文件到系统INF目录里，然后自己写注册表么（HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Setup\\SetupX\\INF\\OEM Name）？
我是在98上执行
SetupDiCreateDeviceInfo（）一句出的错0x0000000d，憋了2天了都还没有进展,要不就可以验证一下这个想法行不行。。。。