Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

Unlimited number of drivers + keeping the drivers.

- - - - -

  • This topic is locked This topic is locked
94 replies to this topic

#1
schalti

schalti

    Junior

  • Members
  • Pip
  • 65 posts
:hello:

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. :thumbup


How to remove advertisement from MSFN

#2
B‚shrat the Sneaky

B‚shrat the Sneaky

    aka Wim Leers

  • Members
  • PipPipPipPipPipPipPipPip
  • 2,214 posts
  • OS:none specified
  • Country: Country Flag
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!

#3
schalti

schalti

    Junior

  • Members
  • Pip
  • 65 posts

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!

<{POST_SNAPBACK}>


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

:thumbup

Documentation by M$ on this subject:
Copying INFs

INF CopyINF Directive

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

#4
Pyron

Pyron

    Junior

  • Members
  • Pip
  • 84 posts
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:
SetupCopyOEMInf.exe <dir with drivers in subdirectories>
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

Attached Files



#5
schalti

schalti

    Junior

  • Members
  • Pip
  • 65 posts

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:

SetupCopyOEMInf.exe <dir with drivers in subdirectories>
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

<{POST_SNAPBACK}>


:thumbup 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? ;)

:)

#6
B‚shrat the Sneaky

B‚shrat the Sneaky

    aka Wim Leers

  • Members
  • PipPipPipPipPipPipPipPip
  • 2,214 posts
  • OS:none specified
  • Country: Country Flag
In V5.04.10 I'll put a beta implementation of this! At least, I'll try to...

#7
BAM

BAM

    Just me!

  • Members
  • PipPip
  • 203 posts
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)

#8
schalti

schalti

    Junior

  • Members
  • Pip
  • 65 posts

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)

<{POST_SNAPBACK}>


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

:blushing:

#9
B‚shrat the Sneaky

B‚shrat the Sneaky

    aka Wim Leers

  • Members
  • PipPipPipPipPipPipPipPip
  • 2,214 posts
  • OS:none specified
  • Country: Country Flag
How do you get all those printer drivers installed in a PnP way?

#10
schalti

schalti

    Junior

  • Members
  • Pip
  • 65 posts

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

<{POST_SNAPBACK}>


:huh:

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.
:blushing:

#11
B‚shrat the Sneaky

B‚shrat the Sneaky

    aka Wim Leers

  • Members
  • PipPipPipPipPipPipPipPip
  • 2,214 posts
  • OS:none specified
  • Country: Country Flag
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.

#12
schalti

schalti

    Junior

  • Members
  • Pip
  • 65 posts

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.

<{POST_SNAPBACK}>


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.

:thumbup

#13
B‚shrat the Sneaky

B‚shrat the Sneaky

    aka Wim Leers

  • Members
  • PipPipPipPipPipPipPipPip
  • 2,214 posts
  • OS:none specified
  • Country: Country Flag
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 :P ): I added the option to let Windows keep the drivers or not to the DriverPacks BASE! ;)

Edited by B‚shrat the Sneaky, 17 April 2005 - 01:14 PM.


#14
erik_demon

erik_demon

    Master Chief

  • Members
  • PipPip
  • 253 posts

I added the option to let Windows keep the drivers or not to the DriverPacks BASE!


Yeah!! Awesome :w00t:

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

@schalti & Pyron

GREAT job guys :thumbup :thumbup

#15
S0mE0nesMiNd1

S0mE0nesMiNd1

    Member

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

#16
RogueSpear

RogueSpear

    OS: SimplyMEPIS

  • MSFN Sponsor
  • 1,529 posts
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 :wacko:

#17
schalti

schalti

    Junior

  • Members
  • Pip
  • 65 posts

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.
:realmad:

#18
RogueSpear

RogueSpear

    OS: SimplyMEPIS

  • MSFN Sponsor
  • 1,529 posts
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).

#19
Astalavista

Astalavista

    MSFN loyalist

  • Members
  • PipPipPipPipPipPipPipPipPip
  • 3,338 posts
And there was light!

#20
Bilou_Gateux

Bilou_Gateux

    Powered by Windows Embedded

  • Members
  • PipPipPipPipPip
  • 766 posts
@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.

#21
schalti

schalti

    Junior

  • Members
  • Pip
  • 65 posts

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

:thumbup

#22
schalti

schalti

    Junior

  • Members
  • Pip
  • 65 posts

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

#23
Bilou_Gateux

Bilou_Gateux

    Powered by Windows Embedded

  • Members
  • PipPipPipPipPip
  • 766 posts
:thumbup 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.

#24
B‚shrat the Sneaky

B‚shrat the Sneaky

    aka Wim Leers

  • Members
  • PipPipPipPipPipPipPipPip
  • 2,214 posts
  • OS:none specified
  • Country: Country Flag
@Bilou_Gateaux: I agree with your last sentence :)

#25
erik_demon

erik_demon

    Master Chief

  • Members
  • PipPip
  • 253 posts
Today I finally had the time to test this new method and I must say: It works SUPERB :thumbup

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?




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users



How to remove advertisement from MSFN