[ilko_t]

There are a few entries in txtsetup.sif, allowing Setup to continue loading driver files for the first stage, until the partitioning screen, from alternative location, this is our USB stick/disk.
Location of the rest of the files, needed to continue Text mode (EULA and file copy part) are given as per this topic:
http://www.msfn.org/.../2-t119742.html

1. Create a small ISO containing only \I386\SETUPLDR.BIN, \I386\NTDETECT.COM and \I386\TXTSETUP.SIF for 32-bit setups. In case of 64-bit only TXTSETUP.SIF is in I386 AMD64, the other 2 files are in \AMD64\ I386.
2. Add these lines to your TXTSETUP.SIF in the ISO:

[SetupData]
....
SetupSourcePath ="\WIN_SETUP\2000\"
SetupSourceDevice=\ArcName\multi(0)disk(0)rdisk(1)partition(1)
BootPath="\WIN_SETUP\2000\I386\"
BootDevice="multi(0)disk(0)rdisk(1)partition(1)"
....

After loading the 3 files from the ISO setup continues loading the other from BootDevice\BootPath.

3. Grub4Dos menu.lst:

title First part of 2000 setup
find --set-root /WIN_SETUP/2000.ISO
map --mem /WIN_SETUP/2000.ISO (0xff)
savedefault 1
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
root (0xff)
chainloader /I386/SETUPLDR.BIN

title Second part of 2000 setup/Start from the first internal disk
savedefault
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
rootnoverify (hd0)
chainloader (hd0)+1

4. Put that ISO say in \WIN_SETUP\ on the USB disk.
5. Copy the all 2000 setup files in \WIN_SETUP\2000\
6. At start of GUI mode the value of sourcepath in $winnt$.inf is "translated" to dos path, with a drive letter and is used for the rest of the GUI mode.
Default behavior is to translate this NT path to Dos path, which is used for the GUI mode. If the value is ARC path it gets translated to \device\harddiskX\partitionY\WIN_SETUP\2000\. If the value is \device\harddiskX\PartitionY\WIN_SETUP\2000\ it gets translated to U:\WIN_SETUP\2000\. This is saved as the value of dospath entry in $winnt$.inf.

Instead, use presetup.cmd and Pyron's fake setup to change 'setupsource' value to something more useful- "\??\U:\WIN_SETUP\"
U: is taken by searching in all local drives for a tag file.

Winnt.sif if present in the source folder (\WIN_SETUP\2000\I386\) is applied, migrate.inf too. The ISO file needs just the 3 files mentioned.
If txtsetup.oem is present in the ISO, alongside txtsetup.sif, it's also honored.
No files are deleted from the source folder. Msdosinitiated in sould be 0, NO, or absent in winnt.sif, as in a regular source.
Boot.ini is generated correctly and placed always on the internal disk.
Practically unlimited number of sources can be easily placed on the USB disk.

Tested successfully with USB stick on all possible Windows versions 2000-XP-2003, on virtual machines and real hardware.

The only problems I got were with USB hard disk and 64-bit versions, this could be because of the IDEtoUSB adapter I am using. At start of GUI mode partitions on USB disk do not get drive letters. Diskpart shows the disk, but no volumes are mounted from it, just the internal disk

To do list:
Find out what's going on with USB hard disks and x64 versions.
Test USB stick/disk mapped to say hd21.
Find workaround for USB sticks, seen as floppy by BIOS. Lacking hardware for this part.

Here is a very unfinished, test version of WinSetupFromUSB, which has a lot to be changed and fixed, but does the most of the required changes, if anyone want's to jump in and help testing:
http://www.datafileh...d-48372825.html

Same approach might be used for loading multiple BartPEs in the USB stick/disk, no need of the ISO file, just settings in txtsetup.sif pointing where the files are to be found, not tested.

edit: (18-11-2009) Fixed locations of files in case of 64 bit versions
edit: (20-11-2009) WinSetupFromUSB download link modified
edit: (21-11-2009) WinSetupFromUSB download link modified
edit: (10-12-2009) WinSetupFromUSB download link modified
edit: (19-12-2009) WinSetupFromUSB download link modified

[Siginet]

That sounds very cool!

Could you give me an example of your presetup.cmd file?

Now it's got me thinking.

Would something like this be possible...

Could we create our mini ISO's with the needed files and edits you have above. Plus add only the needed files which are different between different versions of XP. Like XP Pro OEM / VLK / Retail.

So that when setup is performed those files are placed into the setup?

This way we could simply have the entire disk from XP Pro OEM on the USB Stick. Plus mini iso's of the others. XPPROVLK.ISO, XPPRORTL.ISO.

During setup all of the XP Pro OEM files would be placed onto the drive through txtmode setup. But the files for VLK or Retail would overwrite the OEM files just before Guimode.

I'm really curious if it would work. As you know. Thats exactly what I have been looking to do for a long time now.

I'll test out your new method sometime later tommorrow if I get a chance.

Thanks!

[ilko_t]

presetup.cmd:

@echo off
SET TAGFILE=\WIN_SETUP
FOR %%h IN (U D M N O P Q R S T V W X Y) DO IF EXIST "%%h:%TAGFILE%" SET USBDRIVE=%%h:
if "%USBDRIVE%" == "" (
FOR %%h IN (C E F G H I J K L) DO IF EXIST "%%h:%TAGFILE%" SET USBDRIVE=%%h:
)

set srcpath=\??\%USBDRIVE%\WIN_SETUP\2003\
%systemroot%\system32\fixsrcpath.exe %srcpath%
EXIT

fixsrcpath.exe is a simple AutoIt code- attached with the compiled fixsrcpath.exe, along with the fake setup.ex_. Works for both 32 and 64 bits versions of setup.

Added entries to TXTSETUP.SIF in the ISO:

...
[SourceDisksFiles]
...
fixsrcpath.exe=1,,,,,,,2,0,0
presetup.cmd=1,,,,,,,2,0,0
setupORG.exe=1,,,,,,,2,0,0
...
[SetupData]
SetupSourcePath ="\WIN_SETUP\2003\"
SetupSourceDevice=\ArcName\multi(0)disk(0)rdisk(1)partition(1)
BootPath="\WIN_SETUP\2003\I386\"
BootDevice="multi(0)disk(0)rdisk(1)partition(1)"
...

Make sure you use similar entries for grub4dos menu.lst as posted above.

Extract the existing original setup.ex_ and rename to setupORG.exe in \I386\. Put setup.ex_ from the archive in \I386\.

As for your idea- should be easily doable- just slightly different txtsetup.sif's in the ISO, pointing to the same source, which has needed files for all versions mentioned. I'd need to get back to your notes for details.

Attached File(s)

•  fixsrcpath.7z (280.32K)
  Number of downloads: 78

[wimb]

Breaking News, this sounds very interesting

[cdob]

Premilary note:
Test version WinSetupFromUSB 0.2.4

XP SP2 64 bit

Quote

fixsrcpath.exe=1,,,,,,,2,0,0
setupORG.exe= 1,,,,,,,2,0,0
presetup.cmd= 1,,,,,,,2,0,0

[SetupData]
SetupSourcePath ="\WIN_SETUP\XP_x64\"
SetupSourceDevice=\ArcName\multi(0)disk(0)rdisk(1)partition(1)
BootPath="\WIN_SETUP\XP_x64\AMD64\"
BootDevice="multi(0)disk(0)rdisk(1)partition(1)"

I'm using -graft-points to create the ISO file. Files are read from USB drive.
\WIN_SETUP\mkiso.cmd

set win_root=%~dp0
set win_files=XP_x64

mkisofs.exe -graft-points -o %win_root%/%win_files%.ISO ^
/I386/SETUPLDR.BIN=%win_root%\%win_files%\I386\SETUPLDR.BIN ^
/I386/NTDETECT.COM=%win_root%\%win_files%\I386\NTDETECT.COM ^
/AMD64/TXTSETUP.SIF=%win_root%\%win_files%\AMD64\TXTSETUP.SIF

32 bit fake setup complains:
C:\WINDOWS\system32\presetup.cmd : file not found
C:\WINDOWS\system32\setupORG.exe : file not found
Both file does exit at hard disk.

Fake setup.exe is 28 kb size, that's the BTS one, not Pyron's.
PE booted: setuporg.exe renamed to setup.exe.
The same experience: USB drive is missing.

Next idea add Dietmar's usbboot.inf.
USB drive should be available at first reboot.
To be continued.

ilko_t, on Nov 17 2009, 10:22 AM, said:

As for your idea- should be easily doable- just slightly different txtsetup.sif's in the ISO, pointing to the same source, which has needed files for all versions mentioned. I'd need to get back to your notes for details.

Grub4dos support hex editing in RAM nowadays.
Add one setupldr.bin and different renamed txtsetup.sif.
Patch setupldr.bin on the fly.

[Siginet]

ilko_t, on Nov 17 2009, 10:22 AM, said:

As for your idea- should be easily doable- just slightly different txtsetup.sif's in the ISO, pointing to the same source, which has needed files for all versions mentioned. I'd need to get back to your notes for details.

Quote

Grub4dos support hex editing in RAM nowadays.
Add one setupldr.bin and different renamed txtsetup.sif.
Patch setupldr.bin on the fly.

Now that is a great idea too.

[cdob]

@ilko_t
Wow64FsRedirection did confuse me.

Brute force approach did work using fake setup.exe from WinSetupFromUSB 0.2.4.

Quote

fixsrcpath.exe=1,,,,,,,2,0,0
setupORG.exe= 1,,,,,,,2,0,0
presetup.cmd= 1,,,,,,,2,0,0

fixsrcpath.exe=1,,,,,,,82,0,0
setupORG.exe= 1,,,,,,,82,0,0
presetup.cmd= 1,,,,,,,82,0,0

Can you name a good x64 txtsetup.sif example?

Dietmar's usbboot.inf. and txtsetup.sif [BootBusExtenders.Load] set.
After reboot there is d: USB drive available.
Presetup.cmd and fixsrcpath.exe does adjust $winnt.sif$. Setup does continue.
Next drive d: disappear. Setup holds, missing files.
Try editing usb*.inf or do you have another suggestion?


@Siginet
Different txtsetup.sif is a inter media step.
Use ONE ISO image finally.
Load this to RAM. Use grub4dos to change txtsetup.sif in RAM.
There are dd, write and 'cat --locate --replace' to edit txtsetup.sif.

[ilko_t]

cdob, on Nov 17 2009, 02:43 PM, said:

Can you name a good x64 txtsetup.sif example?

Exactly as you figured it out.

fixsrcpath.exe=1,,,,,,,82,0,0
presetup.cmd=1,,,,,,,82,0,0
setupORG.exe=1,,,,,,,82,0,0

Section is still SourceDisksFiles. Those files are in AMD64 folder in source.
And yes, sorry for confusion, fake setup.exe is taken from BTS DP, auto renames original setup.exe and launches it.

SysWOW redirection was real pain in the rear to figure out, I was trying with batch files, but it was behaving very weird and inconsistent, even using start64.exe to launch 64 bit cmd.exe and execute the batch file.
Next was to compile 64 bit version of the fake setup.exe, but rather than that, I just created AutoIt script, which works on both platforms, disabling SysWow redirection, it was much quicker and safer to do it this way.

I hope I am not forgetting something, I was coding all changes directly in the AutoIt script, but the basics are covered above.

As for the USB start type changes- I was thinking in this direction too, what stopped me was why 2003 SP1 32 bit works just fine, but 64 bit version not, in the very same setup , the USB stick works fine. Did MS introduced more changes compared to 32 bit similar versions?
The other thing is that looking at setuplog.txt reveals that the USB disk is enumerated, I suspected other reason for this behavior.

As for the drive letters- when using grub4dos MBR there is no need of active partition, so partitions on the USB disk will get lower priority in drive letter assignment. Another idea- hide the partitions for the Text mode, unhide them for GUI, not tested, should work, risky though for regular user.

The idea with editing TXTSETUP in RAM is great, didn't know it's already implemented in grub4dos, thanks.

[class101]

ilko_t, on Nov 16 2009, 09:37 PM, said:

In case of 64-bit only TXTSETUP.SIF stays in I386, the other 2 files go in \AMD64\.

cdob, on Nov 17 2009, 01:40 PM, said:

I'm using -graft-points to create the ISO file. Files are read from USB drive.
\WIN_SETUP\mkiso.cmd

set win_root=%~dp0
set win_files=XP_x64

mkisofs.exe -graft-points -o %win_root%/%win_files%.ISO ^
/I386/SETUPLDR.BIN=%win_root%\%win_files%\I386\SETUPLDR.BIN ^
/I386/NTDETECT.COM=%win_root%\%win_files%\I386\NTDETECT.COM ^
/AMD64/TXTSETUP.SIF=%win_root%\%win_files%\AMD64\TXTSETUP.SIF

me confused so who is right about the file locations?

I think ilko is wrong saying TXTSETUP staying in I386 because the default location of this files in an official iso are where wrote cdob

[ilko_t]

class101, on Nov 18 2009, 10:05 AM, said:

...me confused so who is right about the file locations?

I think ilko is wrong saying TXTSETUP staying in I386 because the default location of this files in an official iso are where wrote cdob

You are correct, it's the opposite of what I posted, editing the post above.

I'd recommend you to stick with the test version of WinSetupFromUSB, most of the changes were coded directly and I am posting the procedure here by actually reading the AutoIt code and looking at already made USB disk.

[cdob]

ilko_t, on Nov 18 2009, 01:01 AM, said:

SysWOW redirection was real pain in the rear to figure out, I was trying with batch files, but it was behaving very weird and inconsistent, even using start64.exe to launch 64 bit cmd.exe and execute the batch file.
Next was to compile 64 bit version of the fake setup.exe

I've compiled a 64 bit version of Pyron's fake setup.exe. Don't you remember from ISO RAM load?
As long as you use 64 bit only applications, setup behave consistent.

Quote

I just created AutoIt script, which works on both platforms, disabling SysWow redirection, it was much quicker and safer to do it this way.

As you like.

Quote

As for the USB start type changes- I was thinking in this direction too, what stopped me was why 2003 SP1 32 bit works just fine, but 64 bit version not, in the very same setup , the USB stick works fine. Did MS introduced more changes compared to 32 bit similar versions?

No explanation. Contrary missing USB is reported at 32 bit ISO RAM load too: some strange BIOS.
Missing USB seems to be more common.

Quote

The other thing is that looking at setuplog.txt reveals that the USB disk is enumerated, I suspected other reason for this behavior.

PNP works up to USB Root Hub device, installation does fails. Driver not found anymore.

Add a work around to presetup.cmd, open drive U:

 
[BootBusExtenders.Load]
usbehci = usbehci.sys
usbohci = usbohci.sys
usbuhci = usbuhci.sys
usbhub = usbhub.sys
usbstor = usbstor.sys 

[InputDevicesSupport.Load]
;usbohci  = usbohci.sys
;usbuhci  = usbuhci.sys
;usbehci  = usbehci.sys
;usbhub   = usbhub.sys
;usbstor  = usbstor.sys

[BootBusExtenders]
usbehci  = "Enhanced Host Controller",files.usbehci,usbehci
usbohci  = "Open Host Controller",files.usbohci,usbohci
usbuhci  = "Universal Host Controller",files.usbuhci,usbuhci
usbhub   = "Generic USB Hub Driver",files.usbhub,usbhub
usbstor  = "USB Storage Class Driver",files.usbstor,usbstor 

USB drives are available at first reboot.


Next USB hardware did break, hardware not detected anymore.
New hardware prepared: dosn't boot anymore: biosinfo.inf not found.
Reason: FAT16 formated, directory WIN_SETUP not found.
WIN_SETUP renamed to WINSETUP (8.3 name) and config adjusted.
XP installation does work again.

Dosdev.exe from resource kit list device names.
Did you tried USB SourcePath "Device\Harddisk1\DP(1)0-0+2\WIN_SETUP\XP_x64\AMD64\" at $winnt$.sif?
USB stick keeps available, but PNP freeze.

Be aware, testings are done at one machine only. Different BIOS may get different results.

Attached File(s)

•  PyronSetup.7z (14.43K)
  Number of downloads: 31

[ilko_t]

cdob, on Nov 18 2009, 02:29 PM, said:

I've compiled a 64 bit version of Pyron's fake setup.exe. Don't you remember from ISO RAM load?

You mentioned that it's compiling in 64 bit env., I must have missed a compiled exe if you posted such. The other reason is that prefer BTS version, one thing less to worry about, renaming setup.exe and launching it.

Quote

Contrary missing USB is reported at 32 bit ISO RAM load too: some strange BIOS.

Wasn't that happening with fixed type media and when mapping was not performed?
I think this has something to do with Windows detecting the boot device and something strange around it, so it doesn't give it drive letter, or something along those lines. Remember, USB sticks work just fine with 64 bit versions.

Quote

Add a work around to presetup.cmd, open drive U:

start /min "USB keep mounted - work around" pushd %CDDRIVE%

USB drive keeps available. Setup does work.

Hmm, in my tests with hard disk and 64 bit vers. %CDDRIVE% did not get value, tag file was not found in presetup.cmd. USB disk partition did not have any drive letter assigned when fake setup.exe was launched. Did you test with 64 bit and USB hard disk?

Quote

As for txtsetup.sif:
No need for a usbboot.inf, but change drive load priority.
BootBusExtenders.Load are set to boot drivers at registry: start=0

I'd try that, want to get away for a bit from this matter, had too much testing last weeks and need to clear up my head a bit

Quote

Did you tried USB SourcePath "Device\Harddisk1\DP(1)0-0+2\WIN_SETUP\XP_x64\AMD64\" at $winnt$.sif?

Nope. Does harddisk1 represent ARC path to disk(1), or it's internal numeration, as drivers return it?

Next week if time allows will go and get the cheapest CPU, supporting virtualization, so I can test 64 bit versions in VMWare. Good excuse for a little upgrade
On real hardware this takes way too much time.

[cdob]

ilko_t, on Nov 18 2009, 09:16 PM, said:

Hmm, in my tests with hard disk and 64 bit vers. %CDDRIVE% did not get value, tag file was not found in presetup.cmd. USB disk partition did not have any drive letter assigned when fake setup.exe was launched.

USB drivers was set at txtsetup.sif [BootBusExtenders.Load] section.
USB drive got a letter.

Quote

Did you test with 64 bit and USB hard disk?

That's a very good question. It turned out:
I used previously a micro SC card and a USB micro SD card reader.
PNP did disable USB drive. This can be avoided with "pushd %CDDRIVE%".

Next i used the same micro SC card, but another USB SD card reader.
presetup.cmd edited: "pushd %CDDRIVE%" was NOT launched.
PNP does keep the USB drive.
Installation does complete without a error.

To crosscheck I used the old broken USB micro SD card reader.
Once again the same micro SD card, no editing at all now.
PNP does disable the USB drive.

The USB SD card reader makes the difference.
Strange, I'm surprised and confused. No explanation.

Quote

Does harddisk1 represent ARC path to disk(1), or it's internal numeration, as drivers return it?

No idea. Ignore this part so far.
Idea was to use dosdev.exe and use this to set sourcepath.
That's note necessary, your solution works fine.

Quote

Next week if time allows will go and get the cheapest CPU, supporting virtualization, so I can test 64 bit versions in VMWare.

My testing hardware use a 32 bit CPU. No 64 bit testing possible.
The good 64 bit hardware is used for importand work, not to be used for testings. Used for testings currently.

[class101]

ilko, there is something wrong with WinSetupFromUSB_0-2-4 which seems the source of my problem with the past version < 0.2.4 which I had explained here in the actual latest post

bug:

2009/11/20 13:02:07- Creating boot ISO
2009/11/20 13:02:07- Launching MkMigrateInf4.cmd
2009/11/20 13:02:07- ERROR!!!--- Could not create migrate.inf
2009/11/20 13:02:08- Ensuring presetup is launched

in your TEMP folder stands the files ready to be packed as .iso + migrate.inf
Result in: no iso created and the job is not 100% done.

I attach the 0.2.4 log file to this post, I can also add Im trying with a XP64 SP2 sleapstreamed, nothing ripped, on an Active FAT32 partition from USB HDD eSATA only connected in USB mode, and in WinSetupFromUSB im forced to use "Force Target Disk Type" => removable because there is no rdummy.sys for x64.

USE 7-zip to unpack the attached log file

Attached File(s)

•  WinSetupFromUSB.7z (42.94K)
  Number of downloads: 38

This post has been edited by class101: 20 November 2009 - 06:18 AM

[ilko_t]

@class101
Can you try renaming WinSetupFromUSB directory to something simple, like WinSetup for example.
Ignore the message about migrate.inf missing, fixed/removable type does not matter as well, rdummy is not used at all and the radio buttons do nothing now, they are to be removed in the final release.
If you want to use migrate.inf manually copy it from the ISO to the AMD64 folder on the USB disk.

[class101]

how stupid Im, I should have tested to run mkisofs.exe before writing

This is just cygwin1.dll missing

"This application has failed to start because cygwin1.dll was not found"

Else I have shortened paths and exe name but the log didnt changed, I think that is just about the missing cygwin lib I dont have it Im much with mingw liter

so a workaround would be to find a mkisofs not cygwin-ed nor to include the lib.

This post has been edited by class101: 20 November 2009 - 01:42 PM

[ilko_t]

Nice catch, I should have included it...

edit: I've uploaded a new version, link is in the first post.

[class101]

I confirm the .iso is created with new version now I will do further test later I should go out to see a friend but as far I can see yet in logs it looks all good, the ERROR message is removed aswell

2009/11/20 21:18:05- Copying completed. Took: 411.64418913577 seconds
2009/11/20 21:18:05- Creating boot ISO
2009/11/20 21:18:05- Launching MkMigrateInf4.cmd
2009/11/20 21:18:06- Ensuring presetup is launched
2009/11/20 21:18:06- setupORG.exe not found, replacing the original file
2009/11/20 21:18:06- mkisofs.exe -iso-level 4 -volid ""WIN_SETUP"" -R -o C:\WinSetup\temp\XP_x64 C:\WinSetup\temp\
2009/11/20 21:18:09- Checking sizes...
2009/11/20 21:18:09- Total source size- 0 MB
2009/11/20 21:18:09- Target space available- 27488 MB
2009/11/20 21:18:09- Getting USB drives information

Keep it up that very helpful script , saves DVD and thats faster, good for the planet

[class101]

yet testing a XP SP3 32bit in Qemu 0.11.x and virtual 10GB hdd, NTFS Primary Active partition for WinSetup files on hd0 and C: destination partition on the hd1 (been able to get C: that way good job )

All seems fine until the Setup GUI is reached, is returned an unknown path

GLOBALROOT\Device\Harddisk0\Partition1\WIN_SETUP\XP\I386

which is fixed just by adding \\?\ in front of the path, that way

\\?\GLOBALROOT\Device\Harddisk0\Partition1\WIN_SETUP\XP\I386

I have to repeat that ~30 times and the next parts of the install goes fine

At least I'm sure you should add \\?\ somewhere ilko because I have noted this small problem since the beginning of your project when it was called USB_MultiBoot_10

This post has been edited by class101: 21 November 2009 - 10:39 AM

[ilko_t]

Uploaded a new version. Fixsrcpath.exe does not work that early in XP 32 bit, fixsrcpath.cmd is used instead. For 64-bit the exe is used.

@class101
The reason it didn't work is above, please use the new version.

Adding \\?\ at front is a nice idea, I'll play with that a bit.

As for USB-multiboot- it does not use any of this stuff, modifying boot and source paths, so no idea what exactly you have in mind.