Acheron

Great to see the time-stamp stuff fixed in latest version.

Why not call this future SP 2.2? I don't see any reason to make such a big jump in version numbering like: nforce4 support >128GB support >512MB RAM support New installer / uninstaller Any new software I also would like that image conversion plug-ins for Windows Paint mdgx told about. Meaby there is also the possibility to include drivers for mainboard chipsets, cpu drivers, ide / scsi controllers which can be problematic to install manually. A better USB Mass Storage Device Driver would also be nice. Meaby we can use the current XP driver. I don't care about legal issues.

Thanks for this info petr. I'll look up the currently translated Dutch files in order for preparation for SP 2.1. Meaby some errors are caused by bad translation ( I remember Dutch strings in vmm.vxd did not fit correctly. Meaby I overwrote some bytecode )

Lot of Free time Petr ? Jesus, it would be better if you could just write a tutorial about hacking those vxd-files. Also a tutorial to quickly copy all language resource strings from one dll to oneother would be great. I'm now doing this manually through exescope.

Oh, please add a shortcut to your site. So people can look for updates, support, etc.

I don't want to have this compiled yet. You may compile it for yourself if you want

New updates, so it would be fine to call it 2.1

Lemonzest, I'll have not yet implement STRING variables. It's on schedule for next update

Dutch Addon can be found here. Thanks booogy for help

Hmm, I'll do some tests using Process Explorer to find out the problem. EDIT Meaby we cause an deadlock between SetupCopyOEMInf.exe and the suspended Setup.exe thread. Setup.exe has already opened a handle to the SetupCopyOEMINF API Call before it get's suspended. However I found some useful information: http://www.codeproject.com/threads/RmThread.asp: rmthread -pSetupCopyOEMINf.exe -dSetupApi.dll -a" Drivers" might just work for this specific situation. (Best option would be suspending all except the Setupapi.dll threads of Setup.exe so SetupCopyOEMINf coud process the inf's) Very complicated stuff. Too bad I know almost nothing about handles, dll's, api calls etc.

This method is still a big workaround. Does Pyron has any idea about what's happening?

So at least we know why setup cannot be paused totally... Not correct. I think that Windows launches Setup.exe as one process. Using some function from a dll to install a driver is still possible. Reason for Setup to freeze is because of some internal timer-function to detect if Setup fails or not. It has nothing to do with SetupCopyOEMInf.exe

That's another good reason to remove Windows Management Instrumentation

drivers.cmd @echo off FOR /F "tokens=2 delims= " %%A IN ('pausep.exe ^| findstr /I /L "setup.exe"') DO SET Setup_PID=%%A pausep.exe %Setup_PID% start watchdriversigningpolicy.exe setupcopyoeminf.exe drivers pskill.exe -t watchdriversigningpolicy.exe pausep.exe %Setup_PID% /r exit I recommend using PsKill in stead of TaskKill. Taskkill won't work without Windows Management Instrumentation. Some people remove that component with nLite.

Meaby it's PsSuspend related. Try using PauseP as described here please.

I have WatchDriverSigningPolicy only run while SetupCopyOEMInf.exe is processing the drivers. Meaby it's completely unnecessary. I don't know However thanks for PsSuspend! They release so much I overlooked this Tested PsSuspend a bit and it seems to work better than PauseP. Try VirtualDub for example, suspending while playing a video will no longer crash the program drivers.cmd @echo off pssuspend.exe setup.exe start watchdriversigningpolicy.exe setupcopyoeminf.exe Drivers pskill.exe -t watchdriversigningpolicy.exe pssuspend.exe -r setup.exe exit Or if you prefer AutoIT: drivers.au3 Run(@ScriptDir&"\pssuspend.exe setup") Run(@ScriptDir&"\WatchDriverSigningPolicy.exe") RunWait(@ScriptDir&"\SetupCopyOEMInf.exe "&@ScriptDir&"\Drivers") ProcessClose("WatchDriverSigningPolicy.exe") Run(@ScriptDir&"\pssuspend.exe -r setup")

*BUMP Installing goes fine using pausep.exe Anyone else tested this???

Here some regtweaks: Windows Registry Editor Version 5.00 ;Removes stupid Shell Extension [-HKEY_CLASSES_ROOT\Folder\shell\Browse with Paint Shop Pro X] [-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Drive\shell\Browse with Paint Shop Pro X] [-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\Browse with Paint Shop Pro X] [-HKEY_CLASSES_ROOT\Drive\shell\Browse with Paint Shop Pro X] ;Don't show Eula [HKEY_LOCAL_MACHINE\SOFTWARE\Corel\Paint Shop Pro\10] "ShowEula"=dword:00000000 "NeverRegister"=dword:00000001 ;Don't show splash-screen [HKEY_CURRENT_USER\Software\Corel\Paint Shop Pro\10\General\Miscellaneous] "Splash"=dword:00000000 ;Interface [HKEY_CURRENT_USER\Software\Corel\Paint Shop Pro\10\UI Customization\BCGToolbarParameters] "Tooltips"=dword:00000000 "ShortcutKeys"=dword:00000001 "LargeIcons"=dword:00000000 "MenuAnimation"=dword:00000000 "RecentlyUsedMenus"=dword:00000000 "MenuShadows"=dword:00000000 "MenuIcons"=dword:00000001 "UseSystemColors"=dword:00000001 "ShowAllMenusAfterDelay"=dword:00000000 "Look2000"=dword:00000001 I like the menuicons very much

I think it's not the bug itself which causes this delay. The developers need to avoid at all costs insight in their mechanism Daemon Tools uses, that access the CD/DVD-drive. I wish them the best

To save some time copying you could compress your drivers using the Driver Compressor Tool. However I may have found the solution EDIT: Drivers.au3 $list = ProcessList("setup.exe") $setuppid = $list[1][1] Run(@ScriptDir&"\pausep.exe "&$setuppid) Run(@ScriptDir & "\WatchDriverSigningPolicy.exe") RunWait(@ScriptDir & "\SetupCopyOEMInf.exe Drivers") ProcessClose("WatchDriverSigningPolicy.exe") Run(@ScriptDir&"\pausep.exe "&$setuppid&" /r") You need pausep.exe. Place this file also in the $oem$ directory Now the only thing we need to do is combine: pausep.exe SetupCopyOEMInf.exe WatchDriverSigningPolicy.exe into a single application pausep_demo.zip

Last update for now. Sorry for the inconvience, but testing is a bit hard with all kinds of drivers. @Oleg_II: All output is copied to a new subdirectory called %Class%\%Drivername% to avoid overwriting existing files.

I uploaded a new build. Please test to see if it works on all driver infs. New is the added long file name support and the subdir-reference support (ATI Drivers for example). Last update 25 october 2005 [bETA]: -Added Long File Name support -Added Subdir-reference support -Improved dependant files check (minor) -Fixed truncated extension on decompress (minor) -End of line detection added to tagscanner (minor) For the fast please download it again. I found some glitches Here is an example of new code added to detect Subdirs in the SourceDisksNames section: :FindSourceDir SET id.nr=%id.nr: =% SET id.path=%id.path:,=:#% SET id.path=%id.path:*:=% FOR /F "tokens=3 delims=:" %%i IN ('ECHO "%id.path:~1,-1%"') DO ( SET id.path=%%i ) SET id.path=%id.path:#=% SET id.path=%id.path:"=% IF DEFINED id.path ( IF /I EXIST "%id.path%" ( SET id.dir.%id.nr%=%id.path% ) ELSE ( SET id.dir.%id.nr%=. ) ) ELSE ( SET id.dir.%id.nr%=. ) GOTO :EOF

I would like to help testing, however I need something to test. Have you a link to a "malformed" image or so that should be blocked by this new patch?

Here's the original modified bootlogo. Unpack it into the root of your system LOGO9x.zip

You can use this driver method only for PNP-devices. However it's possible to use WinNT.sif and keep the Repair functionality by not specifying a [unattended] section in WinNT.sif. This will make the TEXTSETUP attended, but keep the GUI part of the setup unattended