[Pyron]

Ok, here it is. I have to admit that I am using compressed drivers from CD for a while now and I thought it was obvious how to do it (one additional line in presetup.cmd). But there is so much talk about that lately that I think I have to update the guide someday.
But for those of you who don't want to wait, here is how my own unattended setup looks like:

presetup.cmd

set tagfile=\WIN51

IF EXIST C:%tagfile% SET CDDRIVE=C:
...
IF EXIST Z:%tagfile% SET CDDRIVE=Z:

%systemdrive%
cd %systemroot%\system32
if exist setup.exe ren setup.exe setupold.exe
if exist setupORG.exe ren setupORG.exe setup.exe

call %CDDRIVE%\OEM\bin\cmdlines.cmd

Not much work is done here, I just start another script from CD. This makes testing much easier in vmware, because I can do a snapshot after textmode and start from there whenever I change something, because presetup.cmd is copied to disk (so it is in the snapshot) and cmdlines.cmd comes fresh from (virtual) CD after (virtual) reboot.

So here is the real work:
cmdlines.cmd

set tagfile=\WIN51

IF EXIST C:%tagfile% SET CDDRIVE=C:
...
IF EXIST Z:%tagfile% SET CDDRIVE=Z:

REM uncompressing drivers
%SystemDrive%
cd \
%CDDRIVE%\OEM\bin\7za.exe x -y -aoa %CDDRIVE%\OEM\drivers.7z

REM Adjusting DevicePath
%CDDRIVE%\OEM\bin\SetDevicePath.exe %SystemDrive%\drivers

REM Uncompressing additional stuff (OEMLogo, some reskit tools, etc.)
cd %SystemRoot%\system32
%CDDRIVE%\OEM\bin\7za.exe x -y -aoa %CDDRIVE%\OEM\data\System32.7z

REM Automating GUIMode Setup
start %CDDRIVE%\OEM\bin\AutoIt.exe %CDDRIVE%\OEM\bin\guiinstall.aut

REM Preparing t-13 install
SET KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx
REG ADD %KEY%\998 /V 1 /D "%CDDRIVE%\OEM\bin\quietex.exe %CDDRIVE%\OEM\bin\t-13_install.cmd" /f

REM Preparing postinstall
REG ADD %KEY%\999 /V 1 /D "REG ADD %KEY%\zzz999 /V 1 /D %CDDRIVE%\OEM\bin\postinstall.cmd /f" /f

REM Starting regular Setup
start /WAIT setup.exe -newsetup

So you see it is not that different from my original work, just some adjustments.

Hope it helps!

--
Pyron

[big_gie]

@Pyron

As I understand, you are running SetDevicePath.exe at t-39. Do you remove the OemDriverPath from winnt.sif?

I want to remove OemDriverPath from winnt.sif and call SetDevicePath.exe at t-39 but I and Bilou_Gateux weren't able to do so!!!

I hope it could be made possible...

Thanx

[edmoncu]

@Pyron: here's how my presetup.cmd looks like:

%systemdrive%

cd %systemdrive%\drivers
start /wait drivers.exe -y /q /r:n

cd %windir%\system32

REM Scanning for driverdirectories
%systemdrive%\SetDevicePath.exe %systemdrive%\drivers

REM Enable installation of unsigned drivers
start %systemdrive%\WatchDriverSigningPolicy.exe

REM Workaround to work with XPSP2
cd %systemroot%\system32
if exist setup.exe ren setup.exe setupold.exe
if exist setupORG.exe ren setupORG.exe setup.exe
start /WAIT setup.exe -newsetup

im just being overly cautious here, but it seems to show that in your code

if exist setup.exe ren setup.exe setupold.exe
if exist setupORG.exe ren setupORG.exe setup.exe

call %CDDRIVE%\OEM\bin\cmdlines.cmd

you're doing the rename prior to running the decompression of drivers and running the rest of the driver tweaks (SetDevicePath.exe, WatchDriverSigningPolicy.exe).

i was wondering if it will have an adverse effect when i did it quite the other way on my presetup.cmd file?

[Pyron]

I don't think so, since none of my other scripts depends on setup.exe (or its name). I am doing it in this order just for simplicity of testing in vmware. Only commands that won't change are in presetup.cmd. Everything else is in cmdlines.cmd.
I think the order of commands has no bad effect as long as the logical order is preserved (calling SetDevicePath.exe after uncompressing drivers ).

--
Pyron

[turbomcp]

does detachedprogram support cmd/bat files?

i run these commands but it doesnt even start:
[GuiUnattended]
DetachedProgram="%SystemRoot%\system32\presetup.bat"
i made sure the file is in this destination(shift+f10)
and if i run it from there it runs ok

presetup.bat:

rem find cdrom
IF EXIST D:\CD.txt set CDROM=D:
IF EXIST E:\CD.txt set CDROM=E:
IF EXIST F:\CD.txt set CDROM=F:
IF EXIST G:\CD.txt set CDROM=G:
IF EXIST H:\CD.txt set CDROM=H:
IF EXIST I:\CD.txt set CDROM=I:
IF EXIST J:\CD.txt set CDROM=J:

start /wait %cdrom%\$oem$\Driverz\driverz.exe

REM Scanning for driverdirectories
%cdrom%\$oem$\DRIVERZ\DevPath.exe %systemdrive%\DRIVERZ

DRIVERZ.exe is self extracting winrar archieve that works fine

in txtsetup.sif i have this:

dmload.sys = 1,,,,,,4_,4,0,0,,1,4
ftdisk.sys = 1,,,,,,3_,4,0,0,,1,4
intelide.sys = 100,,,,,,3_,4,1,,,1,4
pciidex.sys = 100,,,,,,3_,4,0,0,,1,4
isapnp.sys = 1,,,,,,3_,4,1,,,1,4
presetup.bat = 1,,,,,,,2,0,0

anyone have an idea why its not working/starting at t-39??????????
again if i start it manually it works fine

[big_gie]

I think bat doesnt work but cmd works, or vice versa

I created mt39 to make it easier to execute multiple programs at that setup's stage (it does support variables like %SourceDrive%, can hide windows, etc).

[ovilla2001]

Hi guys.

Anyone already tried to use the system restore feature on on TXT mode Setup (using the final Windows XP SP2)????

It was working for me on last RC build but now, when I try to use it the first boot on GUI mode is the Windows desktop (with another screen resolution, the original wallpaper and lots of things not working fine) and not the GUI mode setup screen....

Just now, when everything else was working very fine in my solution (drivers, WMP10, silently installing utilities, etc), I am afraid that they changed something between the RC and the final version.


O. Villa

[ovilla2001]

First I mean repair option when I say system restore.

I did a couple of tests and I think that I am figuring out whta is happening.
My tests:

1- I burned another CD using the last Pyron´s SETUP. EXE and I got the same error.
2- I booted using the WINPE and I deleted Pyron´s SETUP.EXE and I renamed the SETUPORG.EXE to SETUP.EXE. After the restart I got the correct GUI mode setup screen.

I think that using the repair option Windows is trying to use a special feature of SETUP.EXE. I will try to put some debug what is really happening.

O.Villa
PS: Of course I may be messing up something else.......


BTW the error messaging that I am receiving is:
Windows cannot find ´/Idlist,:224:760,c:\windows\system32\´. Make sure you typed the name correctly and try again. To search for a file, click the start button and then click search.

[ovilla2001]

ok.... sorry.... it was my fault (I guess...)

I entered a wrong string in my presetup.cmd.
The weird thing is that installing a new Windows XP the wrong command didn´t provoque anything wrong....
But..... at a repair instllation.... the presetup.cmd was aborted.

Sorry again.

O.Villa

PS:
1- at least my setup.exe version has some cool features now
- pressing "-", I can see presetup.cmd running
- if anything else than -newsetup is passed to the new setup.exe, I will run just the original setup.exe

2- HEY... where is everybody today?

[evilvoice]

ok, I think I have one question for pyron, but maybe more...Ive noticed the compressed guide has been unstickied, and Bashrat replied in that one:

Quote

So why did I prefer this one: because it's UNIFORM (again: if it was working). With Pyron's method you still have to point to EACH compressed file to extract it. On the other side this is an advantage, because you can choose your own folder structure (you're not stuck with a fixed folder).

Now couldnt cmdlines.cmd be rewriteen like so to allow uncompressing of multiple files?

REM uncompressing drivers
%SystemDrive%
cd \
%CDDRIVE%\$OEM$\bin\7za.exe x -y -aoa %CDDRIVE%\OEM\*.7z

Now, here is the thing when doing this...within each 7z folder, you must compress the main folder you want it to go to....so if you want this in %systemdrive%\drivers, you must compress the drivers folder with whatever driverpack youre using...so if its sound, I believe within the paths section of your archive, it should be "drivers\sounds\x\*" (where x is a number and * is the name of the driver)...I believe pyrons method will work with that...

Im also gonna change some things to more represent what serialzs had with compressed guide...like 7za being in the i386 source and compressed, along with much more of pyrons items....unless, pyron, youve tested this and it cant be done?

[idle.newbie]

Pyron's method needs a driver root for SetDevicePath, you can add 7zip's output dir switch -o to anywhere, then give it to SetDevicePath.

Quote

path\to\7za.exe x -y -aoa -o"%SystemDrive%\path\to\anywhere" "path\to\archive.7z"
path\to\SetDevicePath.exe "%SystemDrive%\path\to\anywhere"

can't sure if long-path will casue any problem for OemPnPDriverPath 4096Bytes limitation, but i prefer some shorter path eg:\DRV.

[evilvoice]

@idle.newbie, i think you misunderstood what I was saying...now, I have no idea where the archives will extract, but i assume since pyron is using this method, it extracts to %systemdrive% per the code before the actual 7zip command...the way most archives work is this...lets say you are in %systemdrive% (herenow referred to as c:), so we are sitting at the root of c: and we run 7za.exe [command] [options] *.7z...it will expand in c:, so technically, there is no need for a "-o path"...now, as I understand it, setdevicepath needs the main folder, in this case, drivers...so why couldnt what I posted work

%systemdrive% (sends us to drive windows was installed on)
cd \ (puts us at the root of the drive)
7za.exe x -y -aoa *.7z (extract command - I didnt include folders as this is only an example)
setdevicepath.exe %systemdrive%\drivers

doesnt setdevicepath recurse subdirs? (or for those who want it in real terms, doesnt it look through EVERY folder in drivers?)

PS...do not talk about the path of *.7z or stuff like that...because for my usage im gonna have it all point to %systemdrive%\Install\Drivers...but I wanted to make this post general so everyone could see what im talking about...my drivers WILL NOT stay on the cd...and if you wanna know why, its mainly cuz i want them on my hard drive...my personal preference, and I dont wanna create yet another folder in my cdroot.

PPS the only reason I am talking about this is for those who were really hoping for the compressed guide to work...Bashrat gave a reason as to why compressed guide was better, now im trying to make pyrons method do the same thing that was supposed to do.

[idle.newbie]

if you didn't give 7za a -o switch, it will extract everything under current directory, so the resulting drivers directory will depend on how you compress your archive.
given a -o will extract everything under C:\DRV, no matter how you compress your driver archive, and SetDevicePath will recurse into C:\DRV and find every driver's inf.

eg: i have 2 driver sfx, one from BtS Drivers_MassStorage.7z, another for IntelINF.7z.
archive content:
7za l Drivers_MassStorage.7z
Drivers\006_MassStorage\via\ideraid\viaraid.sys
7za l IntelINF.7z
INTELINF\p64h2.inf

when i omitting -o, the resulting driver will be:
C:\Drivers\006_MassStorage\via\ideraid\viaraid.sys
C:\INTELINF\p64h2.inf

with -oC:\DRV:
C:\DRV\Drivers\006_MassStorage\via\ideraid\viaraid.sys
C:\DRV\INTELINF\p64h2.inf

that they will have the same driver root, so i dont need to worry about where i compress my driver, all i need is give that driver root(C:\DRV) to SetDevicePath, and SetDevicePath will find them all(recursively).

CompressGuide fixed where to put your driver archive & where it will be extracted. PyronGuide's far more flexible than CompressGuide, it's batch scripting, edit with notepad for your needs. you can put your archives anywhere(CD/HD/RamDrive), using 7za -o to uniform the driver root.
when BtS's any driver pack updates, grab his new driverpack.7z into your cd source, it's done, you don't need to uncompress and repack.

another way to uniform driver root for my case:
7za x -y -aoa Drivers_MassStorage.7z(omitting -o)
7za x -y -aoa IntelINF.7z -o%SystemRoot%\Drivers(with -o)
after extracting:
C:\Drivers\006_MassStorage\via\ideraid\viaraid.sys
C:\Drivers\INTELINF\p64h2.inf
then give C:\Drivers(driver root) to SetDevicePath.

put drives archive in cd saves a dime copying time @textmode.

[Bâshrat the Sneaky]

idle.newbie, on Sep 10 2004, 04:20 PM, said:

when BtS's any driver pack updates, grab his new driverpack.7z into your cd source, it's done, you don't need to uncompress and repack.

That was my purpose!

Also, if everyone would like another folder structure, I'll change it... But I made it like this:

When extracting (not extracting TO a specific folder) from %systemdrive%, these folders will be created:

%systemdrive%\Drivers\name of driverpack\...

[evilvoice]

I dont think idle.newbie is understanding what im trying to say, but its cool, I understand what im doing and ill do it my way...everyone else can do it his way, and mine will be the only one that no matter how many driverpacks I have, ill never have to reupdate the command script...but its cool.

[bitmonster]

I have a small issue when trying this method. First my presetup.cmd looks like this:

Quote

rem find cdrom
set tagfile=\WIN51

IF EXIST C:%tagfile% SET CDDRIVE=C:
...
IF EXIST Z:%tagfile% SET CDDRIVE=Z:

%systemdrive%
cd %windir%\system32
if exist setup.exe ren setup.exe setupold.exe
if exist setuporg.exe ren setuporg.exe setup.exe

REM Scanning for driverdirectories
%CDDRIVE%\$OEM$\SetDevicePath.exe %SystemDrive%\Drivers

REM Enable installation of unsigned drivers
start %CDDRIVE%\$OEM$\WatchDriverSigningPolicy.exe

REM Starting regular Setup
start /WAIT setup.exe -newsetup

So there is nothing special and no compression till now. Drivers install fine. The problem is that I get an error message at the end of the installation, just before windows tries it first real logon (t+0). It says it can't find "setupORG.exe" and waits till I press the OK-Button. Why is Windows looking for this file again? The rename seemed to work, because "setupold.exe" is in system32 and the original as "setup.exe" also.

[edmoncu]

pyron, i just want to clarify something...

at the first page of this thread, you mentioned something about...

Now comes the tricky part. The installation of unsigned drivers will trigger the usual warning messages.
So you may think: "No problem. I just change the 'HKLM\Software\Microsoft\Driver Signing' value in HIVESFT.INF!"
Should work, but does not. Windows Setup resets the "Driver Signing" entries when it starts.
The following line in presetup.cmd will take care of this issue.

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

It installs a notification hook on the "Driver Signing" regkey and changes it back whenever necessary.
It changes another key as well:
The geniuses at Microsoft implemented a mechanism to disallow the change of the "Driver Signing" keys through regkeys,
which is a good thing™ but at the same time they build a backdoor for circumventing this mechanism.
HKCU\Software\Policies\Microsoft\Windows NT\Driver Signing\BehaviorOnFailedVerify (=0)
This essentially means that when Windows finds out that the policies have been tampered with, it just doesn't care...

i was wondering, does this part disables WHQL checking? i mean, can i install non-WHQL device drivers -- like the catalyst perhaps? or this just disables warning messages? i was hoping if there would be a possibility on installing non-WHQL drivers.

[idle.newbie]

i'm such a dumb a** to do this.

CD /D "%SystemDrive%\" (don't need this line)
FOR %%I IN (%CDDRIVE%\Driverz\*.7z) DO 7za x "%%I" -y -aoa -o"%SystemDrive%\DRV"
FOR %%I IN (%CDDRIVE%\Driverz\*.cab) DO EXTRAC32 /Y /E /L "%SystemDrive%\DRV" "%%I"
UnRar x -y -o+ *.rar "%SystemDrive%\DRV\"
SetDevicePath.exe "%SystemDrive%\DRV"

7za/EXTRAC32(for .cab) didn't accept *.7z/*.cab, so i wrap it with a FOR.

The code above does the same thing as Serialzs' CompressGuide and evilvoice's code: it extracts every *.7z/*.cab/*.rar to C:\DRV. So that's UNIFORM.
Of course you can change the directoryName/fileName to whatever you like, and you can do more, that's what I meant by 'flexible'.
You don't need to change anything after that, put every drivers archive you need to specified directory, and it will be extracted to a common driver root. and Pyron's lovely SetDevicePath will dig them out.

driver root, you can do it by restricting how/where you compress your drivers, or do that with 7za -o or EXTRAC32 /L, I personally prefer the second one, and I prefer the 7z sfx way, never change any batch script after it's working.

I'm comfortable with BtS's directory structure, or anybody else's driver pack (who's structure may like anywhere\345_anyDev\anyCorp\andModel), grab it and go.

This post has been edited by Bâshrat the Sneaky: 12 September 2004 - 10:29 AM

[Pyron]

@bitmonster
You are probably using the setup.exe from the front page. Look here for the "new" one. The original tries to run setupORG.exe after presetup.cmd.

@edmoncu:
Yes, the installation of non-WHQL-drivers should be possible through this, but I had some cases (especially in vmware) where it just didn't work.

--
Pyron

[evilvoice]

@idle.newbie, so you DID understand what I was trying to say...PRAISE GOD!!! LOL (I would have said halle....whatever that word is, but I forgot how to spell it lol)...well, thanks for the code...to me, it just seemed like we were on completely different pages...After I had actually tested it, I was gonna post what I was doing later so you could see...but saying it and doing it are 2 different things...