schalti

For Windows XP ToggleQL will do the job. ToggleQL toggleql.exe 1 ---> Quick Launch On toggleql.exe 0 ---> Quick Launch Off Regards Urs

Why would you need the source code of setupcopyoeminf.exe? It is straight forward and the reason I asked Pyron to make the binary is that I'm not used to write binaries for Windows and that he already wrote SetDevicePath.exe which at first will also scan a subdirectory structure for INF files. So basically he had to change the second part of SetDevicePath.exe - instead of appending every subdirectory that contains one or several INF files to a Registry Value (and avoid duplicate entries) he calls SetupCopyOEMInf with every single INF file. SetupCopyOEMInf is an API call inside setupapi.dll, which is a normal DLL that ships with Windows. All setupcopyoeminf.exe does is to scan a subdirectory structure for INF files and run this API call with every single INF file. MadBoy also uses this very same API call in his AutoIt-based utility. So: you cannot "fix" any bugs there, all you can do is to use this API call in your own utility or use SetupCopyOEMInf.exe - the results will always be exactly the same.

Google -> devcon.exe A free tool by Microsoft for enabling/disabling/installing/uninstalling etc. devices. The certificate is installed automatically by the inf file. I just wanted to make sure that it is a REAL certificate not a dummy, which obviously is the case. There are quite some drivers out there that have a .cat file but it is an empty file or contains just garbage. Windows will recognize this and setupapi.dll will then again use the 'default monitor' driver.

.cat .inf and .icm is just fine if the .cat file isn't just a dummy (right-click and it should show as a Certificate). If this signed driver won't do the job the only thing you can do is to uninstall the 'default monitor' using devcon.exe.

Just add the signed (!) driver(s) for your monitor(s). Any unsigned monitor driver will be ranked lower by setupapi.dll than the default monitor driver.

There is an issue with the CatalogDB (%windir%\system32\CatRoot / CatRoot2). CatalogDB stores certificates and signatures of drivers and Windows Updates. If you wait long enough it will probably continue (several minutes), however every additional call of SetupCopyOEMInf will take several minutes as well. Hours later..... The CatalogDB seems to have a size limit (5 MB + 8 KB), I opened a call at Microsoft but they didn't want to help me. You can check if it really is this issue by running the following statement once the PC seems to hang: cd /D %windir%\system32\CatRoot2 type dberr.txt | find /I "error" If the output shows errors like CatalogDB: 22:03:45 11.07.2006: File #1 at line #701 encountered error 0xfffffbfe then it is the problem I mentioned. Solution is to eliminate signatures of drivers where XP doesn't have an alternative. So I eliminated signatures of almost all of my HP printer drivers (crosscheck with %windir%\inf\ntprint.inf to find out where XP already has a driver and therefor an alternative).

The registry entry that is set by Setdevicepath.exe has a length limit of 4095 characters. The tool searches recursively, but the resulting registry entry has a length limit.

It's more than a cosmetic makeover because it has additional prohibition in many areas. Digital Rights Management, the WinPE-only (!) imaging process, enforced Driver Signing on the 64Bit version and other things. I'm not sure yet about the success of Vista. Problem #1 will be the support practice of M$. They did it with NT 4.0, they are doing it with W2K and they will do it with XP. One day they will just stop to develop security hotfixes. This will force business customers all over the world to upgrade, for legal reasons! I hope this will finally open the eyes of some important decisionmakers. Home users will be happy about the new user interface and will buy Vista simply because the new PC will ship with Vista. Personally I cannot see a single reason why to upgrade to Vista. The new user interface will not increase user productivity in a business environment, so what's the point with Vista? Even WinFS if supplied later in Vista SP1 would not be a reason to upgrade because it only works on local resources.

Of course . There are several methods to integrate drivers, DevicePath in the Registry is one way to do it, however since I work with a single XP Image for all Systems (Notebooks, Tablets, Desktops, POS etc.) I include all drivers which clearly has its limit when using DevicePath. Simply copying the INF/PNF/CAT will work however if you check %windir%\setupapi.log, it will tell a slightly different story. One thing is for sure, the API call SetupCopyOEMInf exists in Vista and Longhorn server in both 32 and 64 Bit version, so this method will still work while others will fail some day. In 64 Bit Vista for example it will not be possible anymore to just copy INF/PNF/CAT because copying those files breaks the signature and you cannot install unsigned drivers in 64 Bit Vista. Things used to be so easy with NT 4.0.....

No there isn't . Both the AutoIt-Application from MadBoy and SetupCopyOEMInf.exe from Pyron use the very same API call and this API call is the one M$ wants you to use when integrating drivers in 2K/XP/2K3. Simply copying the files by script won't do the job correctly. THANK YOU M$ again for this stupid driver signature stuff . In NT 4.0 you could do whatever you wanted with the setup and the drivers. In Vista 64Bit Version it isn't even possible anymore to install unsigned drivers! The whole setup process (setupapi.dll) is a black box already and it will be even worse in the future. All you can do is to use the API calls and if it is slow you cannot do anything about it.

Oops i just checked the syntax of DllCall again, it seems you have to pass the datatype with each parameter also. Try the following: DllCall($dll_exe, "int", "SetupCopyOEMInf", "str", $full_path_to_inf, "str", "", "int", 1, "int", 8, "str", "", "int", 0, "int", 0, "str", "") If it doesn't work try to play with the datatype, the first "int" might be "none", "str" might be "wstr" if you are using Unicode.

SetDevicePath.exe is a different story because you have to create a Registry Entry (REG_EXPAND_SZ) there and you have to avoid double entries if there are subdirectories with more than one INF file. SetupCopyOEMInf is an API call in the Windows DLL setupapi.dll. Shell script / pseudo code like this: for /F "usebackq delims=" %%i in (`dir /S /B "%~dp0*.inf"`) do call setupapi.dll->SetupCopyOEMInf(%%i) So you run the API call SetupCopyOEMInf from setupapi.dll with each INF file you find in the subdirectory structure. That's how Pyron's SetupCopyOEMInf.exe works. It is possible to do an API call to a windows DLL from inside an AutoIt Script (DllOpen, DllCall, DllClose), so you can integrate SetupCopyOEMInf in your tool. I can hardly wait to see if it will be faster but I doubt it. Like this: $dll = DllOpen("setupapi.dll") <loop through all INF files> $result = DllCall($dll, "int","SetupCopyOEMInf", "<INF-Filename including path>", "", 1, 8, "", 0, 0, "") <loop next> DllClose($dll) Please follow the "MSDN on SetupCopyOEMInf"-Link in the other post to find out about the parameters for the API call. BOOL WINAPI SetupCopyOEMInf( PCTSTR SourceInfFileName, <--- important PCTSTR OEMSourceMediaLocation, <--- NULL DWORD OEMSourceMediaType, <--- important, set flag SPOST_PATH (1) DWORD CopyStyle, <--- important, set at least flag SP_COPY_NOOVERWRITE (8) PTSTR DestinationInfFileName, <--- NULL DWORD DestinationInfFileNameSize, <--- NULL PDWORD RequiredSize, <--- NULL PTSTR DestinationInfFileNameComponent <--- NULL ); See also here: pinvoke on SetupCopyOEMInf Hope this helps and you will get the idea

I don't think it is possible to rewrite SetupCopyOEMInf because it is an API call of setupapi.dll. You would have to disassemble setupapi.dll and write your own optimized DLL/EXE which is almost impossible. The reason why I asked Pyron to write the tool was because he already had written the tool SetDevicePath.exe which also crawls through a subdirectory structure looking for INF files. So he could use most of his existing source code. What he does in SetupCopyOEMInf.exe is to call SetupCopyOEMInf with every INF file instead of writing the path of every INF file in a list and put the list in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath as REG_EXPAND_SZ. This whole setupapi.dll is like a black box and all we can do is to use the documented API call SetupCopyOEMInf (MSDN on SetupCopyOEMInf). The batch files that were online for a while are useless because they call the very same API in the end but in an even slower manner. They build an INF file and in the [DefaultInstall] Section use the INF-command CopyINF (WHDC on CopyINF) which as you can see in the documentation uses the very same API call SetupCopyOEMInf in the end. So it is even slower to use this method, and you cannot speed it up. Bad news, I know, maybe M$ will speed up the SetupCopyOEMInf API call in XP SP3 or Vista/Longhorn Server, although I hear that there are new methods for driver integration in Vista.

The API call SetupCopyOEMInf (part of setupapi.dll) will do the following things: - copy the INF file to %windir%\inf\oem<sequencenumber>.inf - create %windir%\inf\oem<sequencenumber>.PNF PNF files are very important because they contain the path to the original location of the INF file. That's the way Windows finds the driver files when it wants to install the driver. - update the %windir%\inf\INFCACHE.1 INFCACHE.1 is an Index file that will allow Windows PnP to find a driver very quickly PLUS if it is a signed driver: - copy the CAT file to %windir%\system32\CatRoot\<GUID>\oem<sequencenumber>.CAT - update the Signature Catalogs %windir%\system32\CatRoot2\....... This is the official way how Microsoft wants OEMs to integrate their device drivers in Windows 2K/XP/2K3. Not all OEMs do it this way, though . To recover from SetupCopyOEMInf.exe means to: - delete the correct %windir%\inf\oem<sequencenumber>.inf - delete the corresponding %windir%\inf\oem<sequencenumber>.PNF - delete the corresponding %windir%\system32\CatRoot\<GUID>\oem<sequencenumber>.CAT (if it is a signed driver) I'm not sure about a mechanism that will clean %windir%\inf\INFCACHE.1 and the Signature Catalogs. Maybe when Windows will install a driver it will clean up those.

It might work, however you will not have the .cat files (driver signature) in your %windir%\system32\CatRoot\{GUID} directory and there will be errors in %windir%\setupapi.log, because the API call SetupCopyOEMInf (that's why this tool has its strange name ) in setupapi.dll is one of the few official and supported ways to properly integrate a driver in Windows 2K/XP/2K3. Simply copying oem<number>.INF/oem<number>.PNF/oem<number>.CAT files is not a supported way to do it. Hopefully we will see an improved version of setupapi.dll that will handle the API call SetupCopyOEMInf faster in XP SP3.