70 replies to this topic

[karyonix]

Why don't you just copy the correct WINNT.SIF into floppy image ?
There is no need for dummy file.

[Wonko the Sane]

Why don't you just copy the correct WINNT.SIF into floppy image ?
There is no need for dummy file.

Well it's something ktp originated, I have NO idea WHY it is used:
http://www.msfn.org/...666#entry889666

What provoked this abnormal OT was simply that the OP said "use a 65,536 bytes file full of spaces" without providing a way to create it.

peter or some other Admin may want to move all this "65,536 bytes spaces" related posts to another thread....


Wonko

[Doodoo]

Why don't you just copy the correct WINNT.SIF into floppy image ?
There is no need for dummy file.

The way I understand it, the idea is to be able to use multiple answer files. But given the size of a floppy image, you could just as well have several ones, each with a different WINNT.SIF within them, and just mount the one you want from menu.lst

[Doodoo]

I found that WinVBlock virtual floppy and virtual CD drive only survive in GUI mode when they are defined in RAM or on local harddisk.

And yet it works fine for me..... So it's not a systematic behaviour, but it looks like the method is not universal...
I didn't realise it could be important, but note from my menu.lst that the virtual floppy is defined in RAM indeed. Only the ISO is directly mapped from USB.

[Wonko the Sane]

And yet it works fine for me..... So it's not a systematic behaviour, but it looks like the method is not universal...
I didn't realise it could be important, but note from my menu.lst that the virtual floppy is defined in RAM indeed. Only the ISO is directly mapped from USB.

I strongly suspect that it is connected with BIOS/hardware, compare with this note by cdob:
http://www.911cd.net...pic=22473&st=37

Some strange machines may require changed files, e.g. Dietmar's ntdetect.com.
http://www.911cd.net...ndpost&p=153804
Or USB drivers from XP SP1, SP3, XP Embedded or 2003.
Plain XP SP2 files does work at a friendly machine.

Compare with this also:
http://reboot.pro/13139/
http://reboot.pro/13139/page__st__17

I understand:
some USB drive relating settings are missing at default installation media.
It may be possible to add this settings to a XP installation media.
However this XP installation media would match this USB drive only.
Details are misssing.

Wonko

[wimb]

And yet it works fine for me..... So it's not a systematic behaviour, but it looks like the method is not universal...
I didn't realise it could be important, but note from my menu.lst that the virtual floppy is defined in RAM indeed. Only the ISO is directly mapped from USB.

That makes the difference DooDoo

The WinVBlock virtual floppy drive must be defined in RAM by using --mem option.
In that case the WinVBLock virtual CD drive with XP Setup ISO can be located on USB

This works OK for me for Install of XP from USB using XP Setup ISO file on USB

title 1 Start Windows XP setup - XP3_11_1.iso

map --mem /winvblock.ima (fd0)

map --mem /winvblock.ima (fd1)

map /XP3_11_1.iso (0xff)

checkrange 0x80 read 0x8280 && map (hd0) (hd1)

checkrange 0x80 read 0x8280 && map (hd1) (hd0)

map --hook

chainloader (0xff)



title 2 Continue Windows XP setup

map --mem /winvblock.ima (fd0)

map --mem /winvblock.ima (fd1)

map /XP3_11_1.iso (0xff)

checkrange 0x80 read 0x8280 && map (hd0) (hd1)

checkrange 0x80 read 0x8280 && map (hd1) (hd0)

map --hook

chainloader (hd0)+1

[Doodoo]

That makes the difference DooDoo

That's what they call serendipity. Please don't give me any credit for that, but I'm really glad it now works for you too
It would be nice to have feedback from other people to know if this method can be considered as universal or if it just "happens to work" on a few machines.

Also, to be fair, I noticed that setup is significantly slower compared to direct install from USB, using WinSetupFromUSB (on the same stick). Any ideas why ?
So far I've always used WinSetupFromUSB, but I was keen to try the ISO method because I don't like to have 7000 files on my stick, plus it takes forever to copy them. It's so much faster to just copy the ISO, although the overall amount of data is the same indeed . On the downside, you have to make sure the ISO is contiguous.... Which can be tricky on a nearly full stick.

Slightly out of topic, but could you explain how you run DriverForge directly during setup ?
I'm only familiar with the manual way, i.e. after XP is installed and once you're logged on.

[wimb]

Section 4 in http://www.911cd.net...showtopic=21883

For Auto Use of DriverForge at T-9 you can place uncompressed drivers (or folders) in Drivers of $OEM$
and then Uncomment two rules by removing ; in U_XP_SET\USB_XP_Setup\w_sif\winnt.sif file (see below).
You can also change driverforge.ini to your needs if you want to use drivers on a different location,
or you may even use the compressed DriverPacks.

[SetupParams]
UserExecute = "%SystemDrive%\INSTALL\SetupPar.cmd"

Method 2 can be very fast because you can just use in Drivers your well known set of required drivers.

If you download U_XP_SET then you find everything there ....

[wimb]

To improve speed:
Alternatively you can boot from RAMDISK with 7 PE or LiveXP (RAMDISK loaded from HDD),
or you can boot from USB with our new full XP Image file
and mount your xp3_11_1.iso ISO file in ImDisk and use WinNTSetup2_x86.exe
to prepare Target partition for Install of XP
http://www.msfn.org/...-winntsetup-v2/

[Doodoo]

Alternatively you can boot from RAMDISK with 7 PE or LiveXP (RAMDISK loaded from HDD),
or you can boot from USB with our new full XP Image file
and mount your xp3_11_1.iso ISO file in ImDisk and use WinNTSetup2_x86.exe
to prepare Target partition for Install of XP
http://www.msfn.org/...-winntsetup-v2/

In essence you boot XP from USB, in order to install XP from USB ?

Back to DriverForge again, what is the difference between :

• adding DriverForge to XP setup and pointing to the OEM folder where the compressed drivers are
• leaving DriverPacks do the job, which runs presetup.cmd and also points to the same OEM folder

[MedEvil]

Also, to be fair, I noticed that setup is significantly slower compared to direct install from USB, using WinSetupFromUSB (on the same stick). Any ideas why ?

CD-drives run in PIO mode during setup, while HDD get UDMA support right from the start.
But if that's the reason or if simply the additional needed translation eats up too much performance, is hard to say.

[wimb]

In essence you boot XP from USB, in order to install XP from USB ?

Yes, why not. You boot from full XP HDD Image file and you mount xpsp3.iso XP Setup ISO file
and prepare Target drive for Install of XP.

On the other hand:
Boot with PE from RAMDISK loaded from HDD and then use IMG_XP_Restore.exe to restore Universal full XP Image file
is for speed far superior compared to Install of XP followed by Install of Apps.
You can boot PE in 30 sec and do a Restore in 4 minutes (XP + all Apps) .

The point is that you can use DriverForge at T-9, that is when Install is almost finished.
At that point you can install perfectly and very fast your missing well known audio and video driver.
At reboot everything is working ....
It is better NOT to install audio and video driver in the beginning of XP Setup.

[Doodoo]

The point is that you can use DriverForge at T-9, that is when Install is almost finished.
At that point you can install perfectly and very fast your missing well known audio and video driver.
At reboot everything is working ....
It is better NOT to install audio and video driver in the beginning of XP Setup.

OK, so what you're saying is that because multimedia drivers are very big, DriverForge is useful because it allows you to install ONLY the SPECIFIC drivers for the machine you're working on.
But my question is, when you point DriverForge to compressed DriverPacks, these ones are NOT specific. In this case, is the effect of DriverForge different from that of presetup.cmd created by DP_Base ?

[wimb]

But my question is, when you point DriverForge to compressed DriverPacks, these ones are NOT specific. In this case, is the effect of DriverForge different from that of presetup.cmd created by DP_Base ?

I would prefer to have Chipset + Processor + MassStorage + LAN + WLAN drivers
available in the very early stage of GUI mode of Install of XP as offered by presetup.cmd
DriverForge is launched at T-9, that is too late for proper install of these drivers in XP.

[Wonko the Sane]

DriverForge is launched at T-9, that is too late for proper install of these drivers in XP.

Just to clarify to the less experienced readers, here is a nice timeline:
http://unattended.ms...xp/view/web/13/


Wonko

[Doodoo]

Just to clarify to the less experienced readers

Hehe that's exactly the kinda reader I am

here is a nice timeline:
http://unattended.ms...xp/view/web/13/

Very interesting Wonko ! I've learnt something today again.

OK let me ask a few more questions.... Maybe I'm a bit thick, but there is still something I don't get. I understand the timing is different, presetup.cmd is launched early, which is great for chipset, LAN, WAN drivers. On the other hand, DriverForge is launched later, which is great for multimedia drivers.

But is the fundamental principle of presetup.cmd and DriverForge the same ? To me it sounds like:

• presetup.cmd creates a "library" of drivers and makes all drivers in a compressed DriverPack (potentially) available to Windows
• DriverForge somehow selects, within a compressed DriverPack, ONLY the SPECIFIC driver for the current hardware.

Is this correct ? Another way to ask the same question would be: suppose I install XP, some drivers (chipset, LAN, WAN) installed during setup with presetup.cmd and some others (audio, video) installed during setup by DriverForge; then I create an image with IMG_XP_Create, and patch it with USB_XP_Fix in order to boot it direct from USB on many different machines:

• will the drivers for all devices covered in the DriverPacks processed by presetup.cmd (chipset, LAN, WAN) be automatically installed ?
• will the drivers for all devices covered in the DriverPacks processed by DriverForge (audio, video) be automatically installed ?

Or is this all comple rubbish and I just totally missed the point ?

[wimb]

• will the drivers for all devices covered in the DriverPacks processed by presetup.cmd (chipset, LAN, WAN) be automatically installed ?
• will the drivers for all devices covered in the DriverPacks processed by DriverForge (audio, video) be automatically installed ?

presetup.cmd makes the library of drivers available, but XP will only install the ones that correspond to the hardware.
Also DriverForge will only install the drivers that correspond to the hardware.
It means if you go to other machine, that the complete library is not installed and is NOT used automatically.

Of course you can let DriverForge use such library to install any missing drivers after that XP has adjusted itselves in 2-3 min to the new hardware (a silent and automatic process, so really wait a few minutes).
I prefer then to have 2.6 GB folder D available on USB-harddisk with all extracted XP x86 DriverPacks.
So I point DriverForge for Post Install to folder D and any missing drivers are installed in about 2 minutes.
The process is fast since you don't need to unpack the drivers. There is enough space on USB-harddisk ....

[Doodoo]

Thanks for your time and your patience, Wimb. I really appreciate
But I'm afraid I'm still a bit lost

It means if you go to other machine, that the complete library is not installed and is NOT used automatically.

From this I understand that the library of drivers created by presetup.cmd and DriverForge during the initial XP setup WILL NOT be used if the image is booted on a different hardware. If this is true, then why bother with integration of DriverPacks to XP setup ? Post-install does the same thing.

any missing drivers after that XP has adjusted itselves in 2-3 min to the new hardware (a silent and automatic process, so really wait a few minutes).

From this I understand that the library of drivers created by presetup.cmd and DriverForge during the initial XP setup WILL be used if the image is booted on a different hardware, and it effectively takes a few minutes for all drivers to be found and installed. Or is this "adjustment" only relevant for drivers included in Windows ? (i.e. not for the DriverPacks)

[davlak]

Doodoo! your tutorial is really NICE!
I'm interested into testing if it works with DP's KTD enabled AND more WINSETUP folders each renamed containing different ISOs. i.e. : 2003 - xp home - xp pro etc.
I think it's impossible to use a single WINSETUP folder because of the winnt.sif inside, is it right?

[Doodoo]

Doodoo! your tutorial is really NICE!

Thanks for the feedback !! I would not pretend this is a tutorial, I don't have the knowledge nor the experience to write a tutorial. I just wanted to "share my experience", and as you may have noticed, I am probably asking more questions in this thread than I am giving answers.

I'm interested into testing if it works with DP's KTD enabled

I think you're not learning anything here, but I have learnt a lot in the last hours. Having experimented a bit last night, further to Wimb's very useful inputs, I now understand that neither presetup.cmd nor DriverForge create persistent libraries of drivers, in the sense that when the image is booted on a different hardware, Windows would be able the scan the libraries and install the required drivers. However, you would effectively allow this behaviour with "KTD enabled", right ? Other than it will bloat your image and make it big, there is no reason why it wouldn't work (this is what all ignorants say !)

AND more WINSETUP folders each renamed containing different ISOs. i.e. : 2003 - xp home - xp pro etc.
I think it's impossible to use a single WINSETUP folder because of the winnt.sif inside, is it right?

No I think you can have a single WINSETUP folder, with multiple ISOs inside, i.e. : 2003 - xp home - xp pro etc.
Then, you have two options of what you can put in this folder:

• either you put one virtual floppy image, and multiple answer files, say WINNT.SI1, WINNT.SI2, etc... Then you create seperate entries in your menu.lst, to copy the wanted one (say WINNT.SI3) in the virtual floppy drive (which replaces the dummy file).

Actually I've just realised this requires the file name to be changed as it is being copied (the destination must always be named WINNT.SIF). Is this feasible with grub4dos dd ?

• or you put multiple virtual floppy images, each containing a different answer file (all properly named WINNT.SIF, no need to distinguish them here), and again you create seperate entries in your menu.lst, to load the wanted image.

Presumably, the same answer file cannot be used for all windows flavours (2003, XP, etc...), or can it ?
Therefore, because all combinations are not allowed, you probably need to organise things a bit better. For example within the WINSETUP folder, you can create subfolders to contain flavour-specific versions of the answer files (say, folders SIF.XP, SIF.2003, etc...). Then you can boot an ISO, and select the answer file in the appropriate sub-folder.
But don't take everything I say for granted. This is only conceptual, and I haven't tried it myself. So I wouldn't swear it is all going to work

[Doodoo]

For example within the WINSETUP folder, you can create subfolders to contain flavour-specific versions of the answer files (say, folders SIF.XP, SIF.2003, etc...). Then you can boot an ISO, and select the answer file in the appropriate sub-folder.

To take the concept further, you can probably create a submenu.lst in each folder SIF.XP, SIF.2003, etc...
This submenu.lst would contain a number of entries, each corresponding to an answer file of the current sub-folder.
At the top, the main menu.lst would only allow you to select between flavours XP, 2003, etc... and the sub-menu would in a second step allow you to select the answer file.

[wimb]

I'm interested into testing if it works with DP's KTD enabled

Yes, that can be quite useful.
You can select to Keep The Drivers for Chipset + Processor + MassStorage ( + LAN )
That will only use about 70 MB (or 135 MB) which is acceptable and provides a lot of extra useful driver support.

In that case the DevicePath is set accordingly in key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

so that XP can automatically make use of these drivers for adjusting to New Hardware.

[Doodoo]

Just a few questions for my general culture

You can select to Keep The Drivers for Chipset + Processor + MassStorage ( + LAN )

Has KTD for MassStorage the same effect as "Add text mode drivers" ? For an ignorant like me, it sounds like the same thing, in the sense that it creates a persistent library of drivers, but I might be missing a few subtleties....

Also, it has previously been said that :

I would prefer to have Chipset + Processor + MassStorage + LAN + WLAN drivers
available in the very early stage of GUI mode of Install of XP as offered by presetup.cmd
DriverForge is launched at T-9, that is too late for proper install of these drivers in XP.

It is better NOT to install audio and video driver in the beginning of XP Setup.

If i'm not mistaken, I now understand that neither presetup.cmd nor DriverForge create persistent libraries of drivers. So from this point of view, it's the same thing. But I would like to understand:

• why it is a bad idea to use presetup.cmd to install audio and video at the beginning of XP setup ? To me it seems that Driverforge will do exactly the same job, except at a later stage of XP setup.

• why is it a bad idea to use DriverForge to install Chipset + Processor + MassStorage at the end of XP setup ? To me it seems that presetup.cmd will do exactly the same job, except at an earlier stage of XP setup.

All drivers can always be installed post-setup anyway, so why is timing important ? How can it be "too early" or "too late" during setup for proper install of some drivers ?

[wimb]

Yes, that can be quite useful.
You can select to Keep The Drivers for Chipset + Processor + MassStorage ( + LAN )
That will only use about 70 MB (or 135 MB) which is acceptable and provides a lot of extra useful driver support.

In that case the DevicePath is set accordingly in key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

so that XP can automatically make use of these drivers for adjusting to New Hardware.

I can confirm that this approach is extremely useful
for booting Universal XP Image file from USB-harddisk and using WinVBlock driver.
Having all Chipset and Processor and MassStorage drivers available
makes it for XP very easy to adapt to new and very different hardware.

http://www.911cd.net...showtopic=23553
http://reboot.pro/13731/

Any missing Video + Audio + WLAN drivers are subsequently easily installed in 2 minutes
by using DriverForge and pointing to the 2.6 GB folder D on USB-harddisk with all extracted DriverPacks.

[wimb]

Has KTD for MassStorage the same effect as "Add text mode drivers" ? For an ignorant like me, it sounds like the same thing, in the sense that it creates a persistent library of drivers, but I might be missing a few subtleties....

Totally different.
MassStorage TXT-mode drivers are needed in early mode of TXT-mode of XP Setup to allow you to detect your MassStorage device,
so that you can select where to install and let XP setup copy the files (otherwise harddisk would be invisible).
So this mechanism only loads more boot drivers that allow XP Setup to see your harddisk.

In GUI mode there is initially Install of devices which is made possible
because presetup.cmd has first unpacked the ChipSet and MassStorage DriverPacks to folder C:\D and has updated DevicePath in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
so that XP Setup can make use of it and install the ones that correspond to your hardware (other drivers are not installed).

Now with KTD you can decide to let DPsFnshr after Reboot to keep some of the unpacked DriverPacks and move them to C:\WINDOWS\DriverPacks
At the same time DevicePath is updated accordingly.
NOW you have your desired DriverStore in XP that will be used to install drivers for new hardware found,
like what occurs when you boot with XP Image file on new hardware.

For the timing of Install I can say that offering the Chipset and MassStorage drivers too late would mean
that XP Setup has in GUI-mode no access to your harddisk.
Offering Audio and Video drivers too early would mean a lot of fixing as being done by DPsFnshr.exe on Reboot for Desktop
See the DriverPack_*. ini files.
It is better to wait a bit and let DriverForge install your specific Audio and Video driver at T-9 when XP Setup has almost finished.

Any missing Audio and Video or WLAN driver can then be installed from XP Desktop
by letting DriverForge search in 2.6 GB folder D on USB-harddisk with all unpacked DriverPacks.