Unlimited number of drivers + keeping the drivers.

[RogueSpear]

Ok, so I've been trying to put together everything from this thread and the other thread "Having Windows keep the drivers." Is the end goal here to have a cab file full of drivers, the necessary inf files in place, and entries made in drvindex or txtsetup or whatever is appropriate?

I've read these threads over and over again and I'm not new to all this, but I'm having some difficulty wrapping my brain around it. I'd definately like to help out where possible, though I am admittedly not very proficient in batch. If anything needs to be done in VBscript, lemme know though.

OT - just started a divorce and my head isn't quite all there lately. Just be patient with me and I'll get it eventually

[schalti]

Ok, so I've been trying to put together everything from this thread and the other thread "Having Windows keep the drivers."  Is the end goal here to have a cab file full of drivers, the necessary inf files in place, and entries made in drvindex or txtsetup or whatever is appropriate?

The goal is

- to make it easy to integrate drivers (except disk drivers). You create your subdirectory structure (pack it and unpack it just before running SetupCopyOEMInf.exe just as you wish), run SetupCopyOEMInf.exe (during Setup i.e. together with or instead of SetDevicePath.exe) and boom Windows will find the drivers for its PnP mechanism.

- to make it possible to use normal subdirectory names instead of very short ones because of length limitations in some registry value DevicePath

- to make it possible to integrate an unlimited number of drivers. You want to integrate 500 printer drivers and 300 monitor drivers and 250 sound drivers and 150 video drivers? Ok, no problem.

Maybe we will see an improved setupapi.dll FINALLY in Windows XP SP3 or in Longhorn that will scan subdirectories for drivers just as the interactive wizard does. The guy who programmed this DevicePath-solution at M$ sure doesn't have any practical experience rolling out 2k or xp or 2k3 in a mixed environment with plenty of different PCs.

[RogueSpear]

See one of the things that is important to me is being able to either A.) keep the drivers on the HD after the install or B.) have the drivers on the install CD and let the wizard find them there. Just something so that when someone plugs in a new device it will be enumerated and install properly. Even if it's not the latest up to date driver, whatever the person had at the time of install would likely be better the MS supplied driver if there is one or the always bloated with crap install CD that vendor seem to be supplying these days (think Dell AIO devices).

[Astalavista]

And there was light!

[Bilou_Gateux]

@schalti

just have a try with yours scripts on a Windows 2000 based installation.

don't works as expected for me and just start to debug the process.

My directory structure for PnPDrvrs:

C:\PnpDrvrs

C:\PnpDrvrs\Chipset

C:\PnpDrvrs\Chipset\815.INF

C:\PnpDrvrs\Chipset\815.CAT

.../...

here a sample of the first I_N_F.inf file created by your script:

[Version]
Signature = "$CHICAGO$"
Provider  = "schalti"
DriverVer = 01/02/2004, 5.10.2600.0000

[DefaultInstall]
CopyINF=815.INF

[DefaultInstall.CoInstallers]
AddReg=CoInstallers.AddReg
CopyFiles=CoInstallers.CoInstallersCopy

[CoInstallers.AddReg]
HKR,,CoInstallers32,0x10008,"cocpyinf.dll,CoCopyINF"

[CoInstallers.CoInstallersCopy]
cocpyinf.dll,,,0x10

When i try to run at hand the command (debugging stage):

rundll32.exe setupapi,InstallHinfSection DefaultInstall 128 C:\PnPDrvrs\CHIPSET\I_N_F.inf

nothing happens?

no new OEM0.INF file in %windir%\inf

no new OEM0.CAT file in %windir%\system32\CatRoot\{xxxxx}

And i have edited drvcp.cmd to solve an copy error:

rem W2K only

copy /Y "%~dp0cocpyinf.dll" "%INFPATH%cocpyinf.dll"

before editing the original line

rem copy /Y "%~dp0cocpyinf.dll" "%INFPATH%I_N_F.inf"

the <subdir>\I_N_F.inf file was overwrited with cocpyinf.dll

As i understand, for WIN 2000, the dll should be copied in each subdir where is the I_N_F.inf file before running the command. I'm right?

EDIT:

After reading MSDN Device Installation: Windows DDK INF CopyINF Directive:

System support for the CopyINF directive is available in Windows XP and later operating system versions. You can also use the directive with Windows 2000 if you install and register the cocpyinf co-installer, which is supplied with this DDK in the /tools directory.

I have tried to run this command first:

regsvr32 c:\pnpdrvrs\cocpyinf.dll

but don't works.

Have you the answer to this problem specific to WIN2K?

Or can you attach the full content of DDK tools directory in a zip file i can check by myself.

[schalti]

@schalti

just have a try with yours scripts on a Windows 2000 based installation.

don't works as expected for me and just start to debug the process.

...

here a sample of the first I_N_F.inf file created by your script:

[Version]
Signature = "$CHICAGO$"
Provider  = "schalti"
DriverVer = 01/02/2004, 5.10.2600.0000

[DefaultInstall]
CopyINF=815.INF

[DefaultInstall.CoInstallers]
AddReg=CoInstallers.AddReg
CopyFiles=CoInstallers.CoInstallersCopy

[CoInstallers.AddReg]
HKR,,CoInstallers32,0x10008,"cocpyinf.dll,CoCopyINF"

[CoInstallers.CoInstallersCopy]
cocpyinf.dll,,,0x10

...

And i have edited drvcp.cmd to solve an copy error:

rem W2K only

copy /Y "%~dp0cocpyinf.dll" "%INFPATH%cocpyinf.dll"

before editing the original line

rem copy /Y "%~dp0cocpyinf.dll" "%INFPATH%I_N_F.inf"

the <subdir>\I_N_F.inf file was overwrited with cocpyinf.dll

As i understand, for WIN 2000, the dll should be copied in each subdir where is the I_N_F.inf file before running the command. I'm right?

Sorry for the little mistake in drvcp.cmd.

I developed the script on XP and added w2k support the way M$ describes it on the DDK website.

It is correct that the cocpyinf.dll should be copied where the temporary INF-file is created. REGSVR32 should not be necessary. It may be a good optimization to run the Coinstaller just once. But first of all it has to work in w2k of course.

I run some tests on an unimportant w2k-Server tonite.

@Bilou_Gateux

EDIT: I just tested Pyron's SetupCopyOEMInf.exe on a Windows 2000 Server and it works without problem. So the API call is reliable on 2000, xp and 2003.

So the solution is easy:

- delete my scripts and use Pyron's SetupCopyOEMInf.exe (downloadable in this thread) which is based on SetDevicePath.exe and my scripts.

@Forum Administrator

Is there a way to remove the scripts I uploaded? The solution with the EXE runs faster, too.

EDIT: Ok, I could remove the script solution. Please use SetupCopyOEMInf.exe instead.

[schalti]

See one of the things that is important to me is being able to either A.) keep the drivers on the HD after the install or B.) have the drivers on the install CD and let the wizard find them there.  Just something so that when someone plugs in a new device it will be enumerated and install properly.  Even if it's not the latest up to date driver, whatever the person had at the time of install would likely be better the MS supplied driver if there is one or the always bloated with crap install CD that vendor seem to be supplying these days (think Dell AIO devices).

<{POST_SNAPBACK}>

Option A. works with SetupCopyOEMInf.exe

Option B. will only be possible if the CD is in the drive at the time the new device is installed. I'm not sure if Windows is smart enough to ask for the CD, maybe it is . A better idea probably to copy the structure to HD or to use addon-images with drivers (which I do using ZENworks imaging, a great tool).

[Bilou_Gateux]

This method is awesome.

"One small step for man, one giant leap for drivers UA."

@schalti for discovering and explaining the way to achieve this

@pyron for writing the magic exe

Many, many, many thanks.

No i understand how some manufacturers like Creative installs their WebCam drivers first on my running box and then let me plug the USB cable and let install the Cam without asking for the install media.

[Bâshrat the Sneaky]

@Bilou_Gateaux: I agree with your last sentence

[erik_demon]

Today I finally had the time to test this new method and I must say: It works SUPERB

I tested it on a couple of onboard devices, and I even tested it on my video card drivers (this test was from inside windows) It work brilliant!!

Then I tried Bashrat's new driver pack which has this method included. This time it didn't work for me. No device where installed during setup, and no devices where installed when I plugged in new hardware

I used Bashrat's pack method 2 (Pyron's method) with the following presetup.cmd

REM +===============================================+
REM | Finding CDROM driveletter                     |
REM |-----------------------------------------------|
SET tagfile=\OEM
FOR %%i in (c d e f g h i j k l m n o p q r s t u v w x y z) do if exist "%%i:%tagfile%" set CDDRIVE=%%i:


REM +===============================================+
REM | Make sure we are in System32                  |
REM |-----------------------------------------------|
CD /D %SystemRoot%\system32


REM +===============================================+
REM | Decompressing the DriverPacks to the harddisk |
REM |-----------------------------------------------|
CD /D %SystemDrive%
%CDDRIVE%\OEM\bin\7za.exe x -y -aoa %CDDRIVE%\OEM\DriverPack_*.7z -o"%SYSTEMDRIVE%"


REM +===============================================+
REM | Scanning for PERMANENT driverdirectories      |
REM |-----------------------------------------------|
%CDDRIVE%\OEM\bin\SetupCopyOEMInf.exe %SystemDrive%\D


REM +===============================================+
REM | Enable installation of unsigned drivers               |
REM |-----------------------------------------------|
START %CDDRIVE%\OEM\bin\WatchDriverSigningPolicy.exe


EXIT

For some reason, it looks like SetupCopyOEMInf.exe isn't executed during this stage (although I get no errors)

What do you think could be the problem?

[schalti]

Today I finally had the time to test this new method and I must say: It works SUPERB 

....

For some reason, it looks like SetupCopyOEMInf.exe isn't executed during this stage (although I get no errors)

What do you think could be the problem?

<{POST_SNAPBACK}>

Strange. The API-Call used is inside %WINDIR%\system32\setupapi.dll (SetupCopyOEMInfA for ANSI and SetupCopyOEMInfW for Unicode) which is available at that stage for sure. Maybe the Output-Window? I hope Pyron finds the time to write a version with a silent switch (no Output-Window) and if it still doesn't work to analyze the problem. It is a shame that at this stage debugging is probably quite difficult. Normally I would run regmon and filemon from Sysinternals to find out about failing file or registry access.

Maybe something with the signature? Are the drivers in this Driverpack signed drivers?

Maybe add a "START /WAIT" ?

Is there another stage of the Setup process where it could be started?

[RogueSpear]

It should work from DetachedProgram.

[sixpack]

works great here

i have questions tho..

can i move the driver folder D to windows folder and if not can i make it a system folder (hide it)?

the topic says "Exception: MassStorage drivers"

so they are not included? or must i delete it before running SetupCopyOEMInf.exe?

[erik_demon]

can i move the driver folder D to windows folder and if not can i make it a system folder (hide it)?

I think so:

If you modify the following lines in your presetup.cmd.

Change this:

CD /D %SystemDrive%
%CDDRIVE%\OEM\bin\7za.exe x -y -aoa %CDDRIVE%\OEM\DriverPack_*.7z -o"%SYSTEMDRIVE%"

%CDDRIVE%\OEM\bin\SetupCopyOEMInf.exe %SystemDrive%\D

To this:

CD /D %SystemDrive%
%CDDRIVE%\OEM\bin\7za.exe x -y -aoa %CDDRIVE%\OEM\DriverPack_*.7z -o"%Systemroot%"

%CDDRIVE%\OEM\bin\SetupCopyOEMInf.exe %Systemroot%\D

EDIT: I assumed you used Bashrat's pack like I did

Edited April 22, 2005 by erik_demon

[sixpack]

i use Method 1

and make a sfx file and unpacking ad t-39