[bilemke]

@ovilla2001

ah-ha
No harm intended.. Rename command worked.... weird... After sp2 is release for xp in the coming days (i hope) I will finish digging into this. I am currently trying to get setup to see a product key using Pyron's little gift by tracking down where the key gets stored (if anyware beyond winnt.sif/$winnt$.sif). My primary goal is to get away from using a unnattended .sif file all together but still have drivers and such. The prodcut key is the only one I can see being a problem without putting it in a unattended setup file. Everything else can be accomplished using the other key moments int he setup time line.

[Alanoll]

ovilla2001, on Aug 4 2004, 05:26 PM, said:

That is what I was trying to suggest with my poor english Bilemke.
But, for awhile, I could to implement the following solution:

1-Run the new setup.exe
2- Setup. exe starts presetup.cmd
3- I run what I need (in fact, I am running an app asking for a 2nd. CD where I have lots of drivers)
4- in the CMD I run:

ren setup.exe setup1.exe (I can´t delete the file but I can rename... very weird)
ren setuporg.exe setup.exe
start /wait setup.exe (that is the original setup)
exit

After that, everything is working fine!

But I am not using the final release version.......
Who knows what more the Microsoft guys will change.

O. Villa 

just curious why you didn't just copy setuporg.exe instead of copying and then calling?

[ovilla2001]

Alanoll

Well, how I worte before, in T-8 (or sometime close), my OPK build 2163 seems be checking for Windows XP signatures (maybe trying to avoid hacks). If Windows XP doens´t find the original SETUP.EXE in the HD, it takes almost 20 minutes trying to recover the original SETUP.EXE. After that, I have lots of events in the event log regarding the bad signature and sigverif also indicate a bad signature.

Renaming the file before, Windows will think that everything is right....

Is it clear? Maybe the final release will have another behavior.



OVILLA

[Alanoll]

no no, I understand the renaming (i believe I'm running into that problem as well) but I didn't understand why you then executed the new SETUP.EXE?

You rename setuporg.exe to setup.exe, and then execute. It kinda of redundant as teh original setup.exe (from this thread, no fromCD) will call setuporg.exe after presetup.cmd has finished. So wouldn't just copying over setup.exe be enough?

[Pyron]

After renaming setupORG.exe to setup.exe it cannot be started anymore, as its name is not setupORG.exe anymore...yes it is confusing...
Maybe he is using the code I posted a page ago.
I think I will update the guide when I get home. (EDIT: Probably later. A nice little box just arrived for me. It is labeled "DOOM3"... )

--
Pyron

[Alanoll]

it may be neccesary. Atleast for me....
I still haven't gotten it working.

When i try the renaming thing, and then calling start /wait setup.exe, I get error saying "Go to Control Panel to add/remove components". When I make a copy of it, setup still hangs.

[Pyron]

BTW: It has to be started like this:

setup.exe -newsetup

Maybe you missed the parameter?

--
Pyron

[Alanoll]

I shall add that.....
And yes I did miss that. Atleast, untill I read it this morning at 10am here. I was just reading the previous renaming thing, and didn't think to look back at the first post I did see it (-newsetup) in the logs this morning and was going to try it. Thanks Pyron.

[Pyron]

I attach the exetutable I am currently using.
It is still called setup.exe, it still runs presetup.cmd, you just have to include the call to the original setupORG.exe yourself.

It would work like this:
presetup.cmd

%systemdrive%
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

--
Pyron

Attached File(s)

•  setup.zip (2.62K)
  Number of downloads: 390

[sezz]

does it work with sp2 (final) now?

[Pyron]

Yes.

--
Pyron

[bilemke]

Sweet, thanks for the minor, but very usefull changes Pyron!!

Now that it is possible to resolve the little issue with setup.exe not being original, I am going to finish finding where the info in unnattend.sif gets called in to play during setup.. Then try to get that same info there without having the .sif file in txtsetup mode.

My goal is still to have a unnattended wtihout the use of a unnattended config file.

[arnonh]

very nice job done here
i am using this method but at the end of the setup after the last reset
when windows installs drivers and codecs it asks me if i wont to continu installing unsignd drivers
thenks in advance arnon

[Pyron]

*After* the last reset? At that point all drivers should be installed already (well, most of them).
I assume you are installing exe-only drivers like from ATI or Creative, so you can tune Windows' behaviour by changing these registry keys:

REGEDIT4

[HKEY_CURRENT_USER\Software\Microsoft\Driver Signing]
"Policy"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Driver Signing]
"Policy"=hex:00

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows NT\Driver Signing]
"BehaviorOnFailedVerify"=dword:00000000

Just import a regfile before installation, that should help. Windows won't bother anymore when you install unsigned drivers. But I would recommend setting these keys back to their original values after you are finished.

--
Pyron

[arnonh]

thenks for the quick repliy
windows had some driver signing problem with the codecs thet ware installd

[big_gie]

@Pyron:
Great tool that SetDevicePath.exe!!

I'm using a tool of mine, mt39, to execute multiple programs from winnt.sif's DetachedProgram. With this, I extract each of 7zip compressed (not sfx) archive containing my drivers. That way its easier to maintain drivers (one archive for each driver):

mt39's config file said:

<?xml version="1.0" encoding="ISO-8859-2" standalone="no"?>
<mt39 version="0.8.1" testingmode="0" logging="1">
<item>
  <!-- nVidia video card's driver -->
  <program>%SourceDrive%\Programmes\7zip\7z.exe</program>
  <arguments>x -y -o"%systemdrive%\setup\drivers\nvidia" "%SourceDrive%\Programmes\drivers\nvidia.7z"</arguments>
  <hide>1</hide>
  <wait>300</wait>
</item>
  <!-- Scanner's driver -->
  <program>%SourceDrive%\Programmes\7zip\7z.exe</program>
  <arguments>x -y -o"%systemdrive%\setup\drivers\scanner" "%SourceDrive%\Programmes\drivers\scanner.7z"</arguments>
  <hide>1</hide>
  <wait>300</wait>
</item>
<item>
  <!-- dbmsmbus's driver -->
  <program>%SourceDrive%\Programmes\7zip\7z.exe</program>
  <arguments>x -y -o"%systemdrive%\setup\drivers\dd4550\dbmsmbus" "%SourceDrive%\Programmes\drivers\dd4550\dbmsmbus.7z"</arguments>
  <hide>1</hide>
  <wait>300</wait>
</item>
...

Right now, I need to include the OemPnPDriversPath in my winnt.sif to point to each of the folder:

   OemPnPDriversPath="setup\drivers\nvidia;setup\drivers\dd4550\dbmsmbus;setup\drivers\dd4550\ecran;setup\drivers\dd4550\gameport;setup\drivers\dd4550\hp845c;setup\drivers\dd4550\lan;setup\drivers\dd4550\sound"

As suggested by Bilou_Gateux on this thread, running SetDevicePath.exe from this could prevent from using the winnt.sif's OemPnPDriversPath section.

What I did was to add this:

<item>
  <program>%SourceDrive%\Programmes\drivers\devpath.exe</program>
  <arguments>%systemdrive%\setup\drivers</arguments>
  <hide>1</hide>
  <wait>300</wait>
	</item>

to mt39's config file and commented the OemPnPDriversPath section. But it didn't worked

There is surely no registry @ t-39 so its surely impossible to edit it... So using this tool from there can't be done...

Does anyone think that editing $winnt$.inf could do it? Or maybe any other way to tell windows to go find its drivers to a certain path (@ t-39, not latter...), without specifiying them in winnt.sif?

thanx

[edmoncu]

hey pyron, just wanna say congratulations!

everything worked well now with xpsp2 with your updated setup.exe! cool!!!

[Pyron]

@edmoncu:
Thanks!

@big_gie:
Well, there definitely is a rudimentary registry at t-39, because I usually add my RunOnceEx Keys before starting the setup and also use SetServicePath.exe at that point. Technically it is even before t-39, since the countdown starts with the setup. Although I cannot tell where your problem exactly lies, I don't think it has anything to do with the registry.
EDIT: I assume you renamed the program, so that
<program>%SourceDrive%\Programmes\drivers\devpath.exe</program>
is not a typo?
--
Pyron

[big_gie]

No its not a typo, I renamed the program

Thanx for the clarification on the registry...

[big_gie]

Does anyone used SetDevicePath.exe @ t-39 succesfully? I'm still looking for a correct way of using it...