Normally there is one way to integrate drivers in Windows 2k/xp/2k3.
Specify oempnpdriverspath in winnt.sif / unattend.txt / ristndrd.sif / sysprep.inf or patch the resulting DevicePath Registry Value directly using SetDevicePath.exe by Pyron. The problem is there is a length limit of 4096 characters.

I developed two little scripts which will solve the problem of driver integration in a different way (exception: disk drivers).

Script 1 'drvls.cmd' will scan a subdirectory structure where it sits at the very top for INF-files and call

Script 2 'drvcp.cmd' which will create a temporary INF-file in the subdirectory and for the INF-file passed by 'drvls.cmd'. It will then use the INF command 'CopyINF' to integrate the INF-file in Windows. CopyINF
- creates oem<sequencenumber>.inf in %WINDIR%\inf
--> this is an exact copy of the INF-file to be integrated
- creates oem<sequencenumber>.pnf in %WINDIR%\inf
--> this is a compiled INF-file that contains device-ID(s) and (most important) the full path to the original driver location (that was passed to 'drvcp.cmd' by 'drvls.cmd').
- integrates the signature .cat file (if it exists) in the catalog-DB
Finally it will delete the temporary INF-file.

As a result Windows can successfully install any device driver in the subdirectory structure with the normal PnP mechanism. The subirectory names can be readable and contain Spaces etc. since there is no limit resulting from a Registry Value Length etc.

So there are 5 files needed:
- drvls.cmd
- drvcp.cmd
- header.txt (header for temporary INF-file)
- footer.txt (footer for temporary INF-file, needed for W2K only)
- cocpyinf.dll (CoInstaller DLL, needed for W2K only)

Now I try to post these files to this forum as a ZIP .

Any suggestions?

EDIT: 19.4.2005 20:20 -> Script solution REMOVED.

Please use SetupCopyOEMInf.exe from Pyron based on his SetDevicePath.exe and my scripts. Downloadable in this thread. Tested successfully on 2k, xp and 2003.

Amazing

But can it be used DURING setup? I don't think so. As far as I understand, this is for in-Windows use. OK, you can install devices from there, but I don't know if the drivers will get installed correctly using this method?

Anyway, superb work! I will definetely try out this one as soon as I can!

I'm sure it can be used during setup.
When using SetDevicePath.exe by Pyron the subdirectory structure will be scanned and Paths with INF-files are included in the DevicePath Registry Value. Instead of using SetDevicePath.exe you simply call 'drvls.cmd' and from this point on Windows will be able to install the additional drivers just as it would be if it knew the Paths from DevicePath.

I already wrote PM to Pyron if he will implement a new tool beside SetDevicePath.exe (the part that scans for INF-files will be exactly the same, instead of creating the registry value DevicePath it will be the task to find the correct API-call to implement the CopyINF from a binary instead of using rundll32 and a temporary INF file).



Documentation by M$ on this subject:
Copying INFs

INF CopyINF Directive

API call to be used by Pyron (hopefully) :-)

Hi there, took me quite some time to recover my forum password...

First of all, nice idea!

The implementation in C++ is actually quite simple, but I didn't have the time to test it during an unattended installation. (just came home from work)

Usage is like this:

It scans a dir recursively and calls SetupCopyOEMInf for every .inf it finds.

Windows may have problems when the referenced driver files are not in the same directory as the .inf, couldn't check that either.

Feel free to try it yourself

--
Pyron

WOOOOOOOOW

That was a VERY VERY fast implementation.
Thank you so much.
I just built a driver structure with tons of Monitor Drivers (with ICC Profiles) and HP Deskjet / Laserjet / Officejet / Designjet drivers. It integrated ALL of them. After a reboot, my Philips 150B3 was suddenly installed with the ICC profile. No more 'Plug and Play Monitor'.
I think it works, but I suggest to test it thoroughly with BTS's Driverpacks for example or other manually created driver structures, especially during unattended setup or sysprep. Any volunteers?

In V5.04.10 I'll put a beta implementation of this! At least, I'll try to...

Well, before i dive in to some advanced testing, need some more "simple" info.
I have my machine still ready for a format and installations.

Is it going to help us all/Bashrat with the development of the driverpacks and helping to bypass the known limit of 4096 characters?
etc etc.

Pure basic, i'm willing to help out, but i'm not that superb with inf files etc.

If i can get enough time, i will help.

EDIT: O.K. i saw that and get the point.. it helps Bashrat for sure... (**** he beat me)

It should help both BTS and all poor lonesome administrators far away from home to integrate drivers. The only thing left to be done is to unpack the drivers properly such as an INF (or several INFs) is visible and to build a directory structure. Maybe optimize it a bit -> find common binary identical files and make two drivers share a common directory to save some space. With this solution you can also finally name the subdirectories the way you want to.
Example: My XP driver structure for HP Deskjet and Laserjet:
-Printer
-- HP
--- Deskjet
---- 6xx 8xx 9xx
---- 450
---- 1220
---- 1280
---- 3320 3420
---- 3500 3600
---- 3740 3840
---- 3810 3816
---- 3820 5550
---- 5100 5600
---- 5700 6500
---- 5800
---- 6122 6127
---- 9300 9600
--- Laserjet
---- 4 5 6
---- 24x0
---- 1000
---- 1005
---- 1010
---- 1015
---- 1100 1100A
---- 1150 1300
---- 1160 1320
---- 1200 1220
---- 1500 color
---- 2100
---- 2200
---- 2300
---- 2500 color
---- 2550 color
---- 3300
---- 3500 color
---- 3550 color
---- 3700 color
---- 4000
---- 4050
---- 4100
---- 4200
---- 4250 4350
---- 4300
---- 4500 color
---- 4550 color
---- 4600 color
---- 4650 color
---- 5000
---- 5100
---- 5500 color
---- 5550 color
---- 8000
---- 8100
---- 8150
---- 8550 color
---- 9000
---- 9050
---- 9500 color

How do you get all those printer drivers installed in a PnP way?

I have this driver structure on %systemdrive% and run at some point during Setup SetupCopyOEMInf.exe against this structure (cmdlines.txt or [GuiRunOnce]). When sysprep (or Unattended/RIS) runs on a workstation that has any Deskjet or Laserjet printer attached XP installs the driver automatically because it finds the DeviceID in one of the .PNF-files that were created by the API-Call SetupCopyOEMInf -> PnP.

Currently I am building driver structures to be able to port my Setup to other customers without having to add many drivers there.
I started with Monitor Drivers from EIZO and Philips (Samsung, Benq, Dell and HP left) and Printer Drivers from HP (Kyocera, Lexmark, EPSON, Dell and Canon left). With Video Drivers I will wait as long as possible until the new driver model from ATI / Nvidia is ready that will provide a standard driver for Notebooks too with just a small amount of files that are OEM-dependent.

Oh, of course, didn't think of that!

Would you like to cooperate with me on that one? Then I'll add a DriverPack Printer and a DriverPack Monitor. With this method this has finally become completely possible. I already got all Hyundai monitor drivers.

Ok. As soon as the package is complete I'll send it to you.
Monitor drivers are language-independent, Printer Drivers however are in German for most of my customers. Maybe I'll find the time to build it in English in parallel.

I changed the topic title for a better description. Don't shoot me, schalti!

EDIT: and now some good reason for this post (this edit was planned of course ): I added the option to let Windows keep the drivers or not to the DriverPacks BASE!

This post has been edited by Bâshrat the Sneaky: Apr 17 2005, 01:14 PM

Yeah!! Awesome

now I really can't wait for the next DP release

@schalti & Pyron

GREAT job guys

I gotta say, theres quite an ammount of progress in this thread. I cant wait to see the outcoming results.

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

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.

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).

And there was light!

@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:



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:


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.