schalti

Correct. This is an error that happens with the original unmodified driver from Intel, too. Intel really does a very bad job with their video drivers. Sometimes they support all chipsets, sometimes only some of them, sometimes they have errors in the INF-files.

ATI tweaking tool AND most important Catalyst 5.6 has been released today with built-in support for some Notebooks already. I hope this will be the new "race" between ATI and NVIDIA to implement support for as many notebooks as possible in the standard driver.

No, mate. As I wrote in my first post, there's no link for Schalti's scripts. So far I got only Pyron's SetupCopyOEMInf.exe. <{POST_SNAPBACK}> Correct. The scripts are useless now since there is SetupCopyOEMInf.exe which is based on my scripts and Pyron's SetDevicePath.exe. If you want to create your own utility it's a matter of scanning a directory structure for INF-Files and use the API call SetupCopyOEMInf (which is inside setupapi.dll) on every INF-File. Maybe Pyron will even give you his C++-Sourcecode.

Driver Signing is a quite complicated process. As a manufacturer you have to sign the driver with your signature and then upload it with FTP to WHQL (M$ Windows Hardware Quality Labs). Then it will get its second signature from M$. Since the release of Windows 2003 Server M$ will give its signing tool out to OEMs because WHQL is constantly under stress. For normal developers and Administrators it is not possible though to get the necessary tools and signatures to be able to sign drivers. Which really sucks biiiig time .

The problem is probably the lack of a signature file (.cat). Windows will probably install the Standard Monitor if you do not have a signed driver for your Monitor. OR Make sure you have your monitor connected using the 15-pin VGA-Connector. If you use a cable with 15-pin VGA on one side and 5*BNC on the other side Windows cannot detect your monitor.

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

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.

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?

Actually ANY driver that has an INF file can be integrated this way. I just checked a few ZYXEL Modems, a TV card from Hauppauge, a special interface card from Siemens for their HICOM telephony solution, a few video, LAN and sound drivers, every driver integration seems to work.

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

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.

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.

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

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

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?

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

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.

is it secure?? Verified at two customers with XP Volume Licence Edition english and german.

HKEY_USERS contains a list of the HKEY_CURRENT_USER registry part of all users that have an account in the local SAM and have logged in at some point. Additionally it contains .DEFAULT which is the Template for every new user that logs in and gets his profile created. However, .DEFAULT has lost a bit of its usefulness with Windows XP since many default settings, specially for the explorer, are taken from other sources now. HKEY_CURRENT_USER is the user-specific registry part of the user that is currently logged in.

I had the exact same problem when slipstreaming SP2 directly over an XP Volume Licence Edition (without SP1). Then I first slipstreamed SP1a and then SP2 on top of it and I got rid of the problem. There are also 15 (!) files that are older if you slipstream SP2 directly over XP (without SP1). So there are issues with slipstreaming and I have an open call at M$ Germany. Hopefully there will be answers soon. In the meantime: - Slipstream SP1a first and then SP2 on top of it - delete i386\sp1.* to save some space, it is not used anyway

You can use CD Image with ANY data files you want to put on a CD. CD Image does not 'pack the files together', it just stores files that are binary identical (independent of the filename) only once in the ISO Image and creates pointers from each directory entry that points to the file. I have been using it for all kinds of software from Novell, Netscape, Sun, Oracle, Microsoft etc. etc. For example it is possible to store Windows XP Servicepack 1 and 1a in German, English, French an Italian on one CD. There are so many common files that CD Image can reduce around 1.3 GB to ~600 Megs.

There is no Q article yet. I made a high priority support call two weeks ago at M$ Germany, they confirmed the issue and proposed the workaround. M$ development is currently investigating if they will release new versions of SYSPREP.exe (deploy.cab).

Actually it is a language independent problem. It happens also with english XP SP2 and the latest english SYSPREP.

The problem is solved, at least kind of. M$ confirmed the following issue: The new version of SYSPREP can be used with both Windows Server 2003 and Windows XP SP2. So the utility has to find out somehow if it is running on Windows Server 2003 or on Windows XP SP2. NOW M$ chose to ask the Server-Service (lanmanserver) what OS-Version is running. UPDATE August 30, 2004 M$ also asks the Server-Service if it is a domain controller or not. Well, why not check first what OS it is in registry (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion) and then ask the Server-Service only if it is a Server.... /UPDATE If you happen not to have 'File and Printer Sharing for Microsoft Networks' installed (which is pretty normal in many environments) on XP SP2, SYSPREP will bring up an error message 'There is an incompatibility between this tool and the current operating system. Unable to continue.'. Workaround: Make sure that in the moment when you start SYSPREP 'File and Printer Sharing for Microsoft Networks' is installed. While SYSPREP is running and busy installing MassStorageDrivers you remove manually 'File and Printer Sharing for Microsoft Networks' and 'QoS Packet Scheduler' and now you have your image the way you want it. I verified this behaviour with both english and german Windows XP SP2 and SYSPREP.