[threeply]

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?

[ilko_t]

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

[threeply]

ilko_t, on Mar 13 2008, 04:23 PM, said:

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?

[ilko_t]

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.

This post has been edited by ilko_t: 14 March 2008 - 03:54 PM

[ilko_t]

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.

Attached File(s)

•  USB_MultiBoot5.zip (12.41K)
  Number of downloads: 67

This post has been edited by ilko_t: 14 March 2008 - 10:03 PM

[ilko_t]

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

[wimb]

ilko_t, on Mar 16 2008, 04:57 AM, said:

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

This post has been edited by wimb: 17 March 2008 - 03:58 AM

[threeply]

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?

[ilko_t]

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.

[wimb]

threeply, on Mar 18 2008, 10:09 PM, said:

I've used the modified version of the program to automate a nlited version of x64 and works great.

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

[ilko_t]

Here you go

Attached File(s)

•  DOSNET.zip (43.66K)
  Number of downloads: 29

[wimb]

ilko_t, on Mar 22 2008, 09:13 PM, said:

Here you go

Thanks ilko

[cdob]

ilko_t, on Mar 18 2008, 04:21 PM, said:

Files are deleted because ~LS and ~BT folders are considered as temporary by design. During Text mode files are actually moved, not copied.

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...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

Quote

Error Code "(0x4, 0x1, 0, 0)" During Windows 2000 Setup (Q226361)

CAUSE
This behavior can occur if the drives on your computer are damaged
or not operating properly, so that Setup cannot properly or reliably
enumerate all the drives in the computer. This can also be caused by
having two or more disks that contain the same disk signature or two
or more RAW disks whose Master Boot Record (MBR) checksums are
identical.

Well, ntldr is not setupldr.bin.
Setupldr.bin does detect two same drives and stop. Windows installation fails that way.

[ilko_t]

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

[ilko_t]

@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

This post has been edited by ilko_t: 28 March 2008 - 12:37 PM

[wimb]

ilko_t, on Mar 28 2008, 07:36 PM, said:

@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

This post has been edited by wimb: 29 March 2008 - 05:14 AM

[wimb]

wimb, on Mar 29 2008, 01:13 PM, said:

ilko_t, on Mar 28 2008, 07:36 PM, said:

@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

Fixed in the New Release USB_MultiBoot_8.zip

wimb