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!

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.

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.

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

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.

@Bilou_Gateaux: I agree with your last sentence

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



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?

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?

It should work from DetachedProgram.

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?

I think so:

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

Change this:


To this:



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

i use Method 1
and make a sfx file and unpacking ad t-39

I that case:

let your sfx file extract the files to your %systemroot% folder

And use



I think this should work

Hey All!

Ok, Just finished catching up.

Interesting.... But Why so complicated for the same thing?

With MY method in creating the CAB PRIOR to install, you can integrate ANY drivers into it. It then does not require entry's in the WINNT.SIF because we no longer have a ton of directory's. Just a single CAB file. With the extra help we have had in our other Thread to run a simple batch to list all the files so we can copy-paste into the DRVINDEX it only take 2 minutes to create a whole new CAB file from scratch with any drivers you want. Then with this method Windows will see the drivers DURING the OS install and install what is required and then POST install if you do any Pn'P it will ALSO detect the drivers.

So I am still confused why we are trying to complicate things further to achieve the same goal..... Or am I missing something?

X-savior, actually I'm wondering the same thing. I made a cab today of all the DPs plus my own DP and it came out to 222MB if I remember correctly. Sure it's a big file, but it's one file instead of thousands. I started thinking about how all of this could or should be implemented. There's going to be a lot of compromise one way or the other. I'll explain:

Using 7-Zip, all the drivers come in at under 150MB. The cab file as I explained above is much larger. Yes I do have a DVD burner and yes I do make a version of my project on DVD. But there are still PLENTY of circumstances where a CD is mandatory. Therefore every last byte counts. So what I'm thinking is that the process could go something like what I do currently, but with a few additions at the end.

Currently I use a modified Method 1. I run the M1 slipstream batch and let it go through all of it's steps modifying the various inf and sif files. Once it's all done, I get rid of the D directory and put the original 7z files in a directory called OEM. From DetachedProgram I call a simple batch file that decompresses the archives to the HD. In a VBscript executed via RunOnceEx, I run the control panels batch and then delete the D directory.

Ok so that's what I do now. What I'd like to do is put in a routine to run from RunOnceEx (or possibly cmdlines.txt) that makes this monster cab file from the contents of D, delete D, and make the necessary changes to the registry and anywhere else so that a future PnP enumeration will look in the custom cab in addition to the stock cab.

I hope this is making sense to some of you out there. I don't always have a flair for explaining things very clear. From what I can tell, we have all of the pieces in place. It's just a matter of implementation. So in conclusion, this would save space on our distribution media since we're still using 7z archives, get the drivers onto the hard drive in time for the initial device install portion of setup, and finally make a nice, neat cab file for future device installations. The only negative I can find so far is that we will still be bound to the 4096 character limitation in the winnt.sif file.

Thoughts? Comments?

Oh yea.. OT but interesting: I discovered today that Viewsonic makes available a single file for download that contains the drivers for dozens of their monitors. Wouldn't it be nice if all monitor manufacturers did this?

@X-Savior

I tested this method myself and I now know that this method has some advantages and two big disadvantages:

advantages:
- Windows directly identifies and installs the drivers. With our method, we always needed to tell windows to search for the drivers. With this method this isn’t necessary. (just like you plug in a new USB mouse)

- This is a by Microsoft documented method. This method is already used for some devices (scanners mostly ask to install the software first before you plug & play the device.) This method is stable.

- This method has no problem with double file names: You might think that our method doesn't have this problem either. I'm not so sure about that.

What would happen if their are two device that both use a different version of the file a.sys

Then we would have in our Drvindex.inf:



How does windows know which file to use??

In this method this is all taken care off.

disadvantages:
- It takes a lot of space on the harddrive, my D folder now is 644 MB, when this is in a .CAB file, it is only 193MB

- It takes some time to run SetupCopyOEMInf.exe With all Bashrat's DP's this could easily take 15 min.

@RogueSpear
This would take a lot of time. About 15 min on every boot. Besides with this method this isn't necessary (only you don't have any compression)



Yeah, that would be great. I would wish that all driver manufacturers did this. I think that there is one big reason why this doesn't happen. Just think about all the poor souls with their 56K modem



This method solves this problem

@schalti

Would it be possible to let SetupCopyOEMInf.exe scan inside a .CAB or .7z file?

You can make scan SetupCopyOEMInf.exe inside .CAB or .7z files (given that source code is available for opening .7z files AND (most important) Pyron is willing to do the job or to make SetupCopyOEMInf Open Source such as somebody else could do it) but I think you cannot make Windows pick the driver files from inside a CAB file without modifying the driver's INF-file and thereby breaking the signature of the driver. Matrox Video drivers use the method with CAB-files for example, most others don't. Is there a way to mount a CAB-file as a new local drive or subdirectory such as it will be transparent file system access for Windows?

I have a little problem though to understand the issue of space on a local harddrive. You unpack it from a CD/DVD (where space is limited) to the local drive where you have plenty of space and then scan it using SetupCopyOEMInf.exe.


There is another thing I'm working on for quite some time already. Since the release of Windows 2003 Server M$ will hand out the software to create signed drivers to OEMs to bring some relief to WHQL. Since I work at a company that is also a M$ partner with plenty of M$ 'Gold Status' certificates I want to test how much those certificates are really worth for a techie, not only for sales . If we would have a software to sign drivers we could rebuild all of them into .CAB-based drivers with a correct signature no problem. This would save space on both CD/DVD and local harddrive.

About the size of the drivers binaries, i recommend to use Driver Compressor Tool by hp38guser. It really saves a lot of space and as inf and cat files are both left uncompressed, you can use schalti method and Pyron tool to scan PnP drivers folders.

@Bilou Gateau: separate files compressing gives a worse result than compressing all files into one big file...

And you're a fairly advanced member, maybe you know how the built-in Windows ability of reading CAB files is organized? I'd like to add the same thing for 7-zip! (would give us MUCH better compression)

CLSID for .CAB files in W2k: {0CD7A5C0-9F37-11CE-AE65-08002B2E1262}
CLSID for .ZIP files in WXP/w2k3: {E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}

Extending the Windows Explorer with Name Space Extensions

With this method and since 7-Zip is Open Source it should be possible to integrate a 7zipview.dll/7zip.dll instead of cabview.dll/cabinet.dll and zipfldr.dll/dzip.dll/dzip32.dll/dunzip.dll/dunzip32.dll ( Enable compressed folder in w2k )

Very good idea

Maybe one of the developers of 7-zip will write the necessary DLLs?
-> Let's put a feature request on Sourceforge Project 7-Zip

Hi

I did another test today and this time my presetup.cmd looks like this (Bashrat's DP method 2 with preserving the drivers) :



Because of the START /WAIT command, SetupCopyOEMInf.exe is finally loaded during presetup

There however still is a problem

When SetupCopyOEMInf.exe start it fails to intergrade the driver :



I get this with 95% of the drivers.

When I run SetupCopyOEMInf.exe in windows again it works flawless

What could be the problem?

The problem is that Windows setup hasn't run AT ALL at this point yet, so there is no directory structure to be found on the hard drive. Try running SetupCopyOEMInf.exe from DetachedProgram and I bet it works for you.

EDIT: You may want to make a simple batch that you call from DetachedProgram to run SetupCopyOEMInf.exe otherwise you'll have to play around with the Arguments entry in the WINNT.SIF.

Okay, thanks

I will give it a try

@RogueSpear: thanks, then I'll do that.

I just tried it, and it didn't work .

This is what I tried:

winnt.sif


presetup.cmd


driver.cmd



The file driver.cmd is in my $OEM$\$1\D folder

I never used DetachedProgram before so maybe I made a mistake.

In never saw the SetupCopyOEMInf.exe during setup.

EDIT:

Don't pay attention to the fact that I use WINXP multiple times. I install from a second harddrive, and the folder WINXP can be seen as the root of my CD.

First, I've never used a directory as my tag file in determining the source CD letter. I don't know if this is causing a problem or not but I would suggest setting the tag file to the file WIN51.

Second, while I am not totally versed in everything Method 2 I think you could and probably shoud keep the WatchDriverSigningPolicy.exe in your presetup.cmd file. I think the way this works is that it will stay resident and running when executed from presetup.cmd, but I'm not so sure it will do that if executed from DetachedProgram.

Third, I don't know if this will make a difference for sure, but I think the BTS DPs are designed so that the various batch files expect to find the DPs as %SYSYEMDRIVE%\D. You've nested D inside another directory. Again, I don't know for sure if this will make a difference or not, but you may as well eliminate any potential problems right off the bat.

Ok and in looking carefully here you are putting driver.cmd in %SYSTEMDRIVE%\D but the DPs themselves decompress to "%SystemRoot%\BtS_DriverPacks.

Suggestion: decompress all DPs to %SYSTEMDRIVE% and put your drivers.cmd file inside $OEM$\$1 in your install media. Make the appropriate changes to your presetup.cmd and drivers.cmd files.

@RogueSpear

Thanks for your reply

This works, I've done it many times now.



Thanks, I will change this!

Bashrat changed this in his pack. (This only works if you make the choice to keep the driver (a special option in his batch).



Yes, I did this on purpose. I can't delete the %SystemRoot%\BtS_DriverPacks folder because I want to preserve the drivers. I can however delete the %systemdrive%\D folder (which also has the control panels batch inside)

I will try to put everything on the %SYSTEMDRIVE%. I don't have any time to test some more today. But I will try it soon.


Thanks for all your help

DOH You guys wanted to 'hide' the DriverPacks folder from the end-user. So far this is only possible with M2. (And of course only enabled when using KtD)

That's why I changed the default folder for M2+KtD from %SystemDrive%\D to %SystemRoot%\BtS_DriverPacks\D. But now you're talking about the control panels, I realize that the CPL batch file will have to be updated as well! DOH

I'll set it to the old default folder for now.

The gui run once section is missing the command to install the control panels now. It worked on the previous base pack.

I know, I'm working on a new version.

Hey,

Well, I can see there are both Pro's and Cons. for both Methods. I will see how the results turn out on this and see if it is worth all the extra work to integrate it. Like I said, simplicity is ALWAYS the best course of action. The More Complicated, the problems can arise.

But I must say everyone is doing some VERY fine work!
I Commend all of you for all the hard work!

It seem there's a problem with unsigned drivers. Anyone having problems with those drivers too?