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.

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

This post has been edited by erik_demon: Apr 22 2005, 03:48 AM

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?

This post has been edited by erik_demon: Apr 23 2005, 05:47 AM

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.