Can this method/tool also be used to install Win XP x64? If not, is there a way to modify to make it work? Has anyone been able to install x64 with a USB?

It should work just fine with x64 as long as you are not installing from USB hard disk, where rdummy.sys is used. That driver is not compiled for x64, if there is any programmer, willing to rewrite the code for us please don't hesitate to do so

I tried x64 but usb usb_multiboot5.cmd would not take the Source directory of my install source. Any ideas?

Oops, sorry for misleading you, it won't work.

The way dosnet.inf is parsed should be changed, so it can get needed files from both I386 and AMD64 folders.
Also the source check should be made for both AMD64/I386 and I386.

Did a few quick changes to USB_multiboot5, would you please test it, if possible until complete install and first logon and report any problems?
Just rewrite usb_multiboot5.cmd with the file enclosed.
Installing from USB stick, right?

edit: a few more changes to the file

edit2: got it working, but part of the files on stick were deleted during TXT mode. No SP2 integrated. Seems write-protecting the removable storage reg. entry is not working with it. Going to test with SP2 integrated, will post results later.
That reg. entry won't work for windows 2000 too, just read it was introduced for first time in XP SP2 32bits.

Seems like StorageDevicePolicies reg. entry works ONLY for XP SP2 32bits.
That means for any other windows version in 2000, XP and 2003 families, many files will be deleted from USB stick during Text Mode phase. Everything else would work as usual.
In order to reuse the stick for another installation, one would need to make a backup of I386 (and AMD64 for x64) folder(s) on his hard drive once the stick is ready, and copy these two folders back to stick in $win_nt$.~ls folder. I am using KillCopy, and tell it to skip all duplicates.

@wimb- you should easily spot the changes made, if haven't done so yet, just search for 'AMD64'. Should be easy to add detection if source is x64 and use the changes needed. Don't have a 2003 x64 to check if structure is the same as XP x64.

ilko

Hi ilko,

I will make the necessary changes for support of XP x64 in the next release.

It is a pitty that StorageDevicePolicies reg. entry works ONLY for XP SP2 32bits,
but repair of the $win_nt$.~ls folder can be a working option.

wimb

I've used the modified version of the program to automate a nlited version of x64 and works great. Does anyone know why the files are deleted during txtmode install. Is this true even if you make the files read-only or better yet write protect the entire stick?

Files are deleted because ~LS and ~BT folders are considered as temporary by design. During Text mode files are actually moved, not copied.
In XP SP2 there is a registry entry, which makes USB storage media read only. Thanks to cdob's idea, this entry is used via migrate.inf. Unfortunately, this seems to works only for XP SP2.
If your stick has a read-only hard switch, you should be good to use it.
There is not other known/published way, to software write- protect entire USB drive during Text Mode, where you have quite limited functionality, or at least I can't find anything usable. I did a few tests with FBWF and EWF to no avail.

Thanks for the feedback.

Will you please give as Attachment your WinXP x64 DOSNET.INF File from AMD64 Folder.
It can help me in designing and testing the USB_MultiBoot program.

Thanks,

wimb

Here you go

Thanks ilko

I tried a new approach to get:
\$WIN_NT$.~BT at RAM loaded image
\$WIN_NT$.~LS at USB drive

s4e loads USB windows without USB BIOS support. A additonal fake RAM loaded image is used.
http://www.911cd.net/forums//index.php?showtopic=21242
Ntldr remember drive by disk signature and mbr checksum.

Similar I created \$WIN_NT$.~BT inside image.
grub4dos loads image. Setupldr.bin does start. Drivers are loaded.

However there is a nice error message next: Error Code "(0x4, 0x1, 0, 0)"

This message lead to: http://www.computing.net/windows2000/wwwbo...orum/23378.html
Well, ntldr is not setupldr.bin.
Setupldr.bin does detect two same drives and stop. Windows installation fails that way.

Just noticed that actually only compressed files are deleted during Text Mode-

txtsetup.sif
[SourceDisksFiles]
binifix4.cmd = 100,,,,,,_x,2,0,0 <------copied not deleted
undoren.cmd = 100,,,,,,_x,2,0,0 <------copied not deleted
ren_fold.cmd = 100,,,,,,_x,2,0,0 <------copied not deleted
_default.pif = 1,,,,,,,1,2,0 <------copied AND deleted

First 3 are not compressed, 4th is. Since write protecting USB does not generate errors while trying to delete nor cause delays, I'd not be surprised if expand functionality in setupdd.sys or wherever it is works the same way as if source is CD, but simply isn't generating errors.

I have also tried to rename both ~BT and ~LS folders to 1WIN_NT1.1BT and 1WIN_NT1.1LS hoping that $ triggers deletion, hex editing setupldr.bin and setupdd.sys (thanks cdob) Text Mode install went fine, but files still got deleted

@wimb- the above part from txtsetup.sif is from 32 bit XP. For x64 make sure you use:

makebt\fedit -f %usb_temp%\txtsetup.sif -add -once -l "ren_fold.cmd = 55,,,,,,_x,2,0,0" -s SourceDisksFiles
makebt\fedit -f %usb_temp%\txtsetup.sif -add -once -l "undoren.cmd = 55,,,,,,_x,2,0,0" -s SourceDisksFiles
makebt\fedit -f %usb_temp%\txtsetup.sif -add -once -l "binifix4.cmd = 55,,,,,,_x,2,0,0" -s SourceDisksFiles

ilko

Oops, that change for x64 in your file was not discovered by me,
so it is not yet implemented in USB_MultiBoot7.cmd
I hope there are no more hidden changes. I focussed on all lines with AMD64 in it.

I will change it in the next version. Thanks for letting me know.

wimb

Fixed in the New Release USB_MultiBoot_8.zip

wimb