Unlimited number of drivers + keeping the drivers.

[erik_demon]

I that case:

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

And use

SetupCopyOEMInf.exe %Systemroot%\D

I think this should work

[X-Savior]

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?

[RogueSpear]

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?

[erik_demon]

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

[mydriver]
a.sys

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

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.

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)

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?

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

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.

This method solves this problem

@schalti

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

Edited April 23, 2005 by erik_demon

[schalti]

@schalti

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

<{POST_SNAPBACK}>

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.

[Bilou_Gateux]

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.

[Bâshrat the Sneaky]

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

[schalti]

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

<{POST_SNAPBACK}>

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

[erik_demon]

Hi

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

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:

CD /D %SystemRoot%\system32

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

START /WAIT %CDDRIVE%\OEM\bin\SetupCopyOEMInf.exe %SystemRoot%\BtS_DriverPacks\D

START %CDDRIVE%\OEM\bin\WatchDriverSigningPolicy.exe

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 :

Found C:\Windows\BtS_DriverPacks\D\W\L\blabla.inf Trying to intergrade ... failed

I get this with 95% of the drivers.

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

What could be the problem?

[RogueSpear]

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.

[erik_demon]

Okay, thanks

I will give it a try

[Bâshrat the Sneaky]

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

[erik_demon]

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

This is what I tried:

winnt.sif

[GuiUnattended]
      DetachedProgram = "%SYSTEMDRIVE%\D\drivers.cmd"

presetup.cmd

SET tagfile=\WINXP\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:

CD /D %SystemRoot%\system32

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

EXIT

driver.cmd

SET tagfile=\WINXP\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:

START /WAIT %CDDRIVE%\WINXP\OEM\bin\SetupCopyOEMInf.exe %SystemRoot%\BtS_DriverPacks\D

START %CDDRIVE%\WINXP\OEM\bin\WatchDriverSigningPolicy.exe

EXIT

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.

Edited April 24, 2005 by erik_demon

[RogueSpear]

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.

[erik_demon]

@RogueSpear

Thanks for your reply

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.

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

I think you could and probably shoud keep the WatchDriverSigningPolicy.exe in your presetup.cmd

Thanks, I will change this!

but I think the BTS DPs are designed so that the various batch files expect to find the DPs as %SYSYEMDRIVE%\D

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

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

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