Jump to content

Multiboot WinXP 64-Bits & 2003 Server SP1


Recommended Posts

Next thing I'm going to try come Tuesday (soonest I can do it) is to copy the ntldr to the boot directory (1OPX in my case) and hex-edit it to rename the I386 directory to 1OPX. If anyone else wants to try before then, please do and let us know. Otherwise, I'll try when I get back to work.

Link to comment
Share on other sites


  • 2 weeks later...

Well, I finally got a chance to try modifying the ntldr. No go. Anyone else have any luck with this? I'm about to switch my setup over to a WinPE based method with CD installation. I'm sure that will work. But I really would like to continue using the current method instead.

Link to comment
Share on other sites

I hope we'll find a way to make this work...

Anyway, can we use WinPE in a similar way as multiboot? I mean, I pop my CD in, I browse in my custom menu, I select the installation I want (4 different boot folder with 4 different winnt.sif file) ?

Link to comment
Share on other sites

well i tried to initiate the setup with some other option than booting from cd, but after reading http://support.microsoft.com/kb/896334 i dont think there're many possibilities except network based setups :(

Windows Startup floppy disks cannot be used to install x64 Edition-based version of Windows Server 2003 and Windows XP Professional. This is because the kernel that is supplied with x64 Edition-based operating systems is now over 2 MB and does not fit on a standard floppy disk.
and
The installation process for x64 Edition operating systems does not support MS-DOS based mechanisms. For example, you cannot install Windows XP Professional x64 Edition from a command prompt.

which means pe based wont work

so i guess the only multiboot solution is to hack/use another ntldr

Link to comment
Share on other sites

The installation process for x64 Edition operating systems does not support MS-DOS based mechanisms. For example, you cannot install Windows XP Professional x64 Edition from a command prompt.

which means pe based wont work

using winnt.exe in Dos won't work, correct. But you can use winnt32.exe in a command line on winpe. I've done it, i know it can be done.

Link to comment
Share on other sites

Sorry Alanoll, but you're wrong. The GUI setup can still be run from PE, as long as you have an x64 version of PE. I've been playing with shrinking the source (gosh's way) as I always used to do with 32 bit, using winnt32 /noreboot etc, and you can do this withing x64 windows, so it would also work with x64 PE. (Which I don't have to test...)

What I've been thinking about though is because the winnt32 still works and creates the $WIN_NT$.~BT and $WIN_NT$.~LS folders as normal on your boot drive, maybe we could hack that somehow. ntldr has these folders in it if you search, but they only work if they're on the boot drive. Maybe we can hack it so that it looks on the CD instead, and hack those names instead of I386/AMD64 folders?

Not really sure. Just a thought...

Link to comment
Share on other sites

The installation process for x64 Edition operating systems does not support MS-DOS based mechanisms. For example, you cannot install Windows XP Professional x64 Edition from a command prompt.

which means pe based wont work

using winnt.exe in Dos won't work, correct. But you can use winnt32.exe in a command line on winpe. I've done it, i know it can be done.

oh ok, sounds good. at least one way to do it

Link to comment
Share on other sites

Fortunately, I do have a x64 copy of WinPE. I'll play around with it a bit this weekend and see what I come up with. I love working for an OEM. I get such cool toys to play with. :)

Edited by Jito463
Link to comment
Share on other sites

good to hear, please report back whatever comes out of 64bit pe ;)

on the other side, i cant get erd2005 and xp64 (unmodified!) to work on multiboot. there're some instances of "\amd64" etc in txtsetup.inf of erd. i tried to modify it in some ways but couldnt get it to work if xp64 \amd64 is on the dvd too :(

so a hacked setupldr is most welcome ;)

regards

Link to comment
Share on other sites

Something new I got to thinking about. In the setupldr.bin near the first listings of i386, there is a listing for $WIN_NT$.~BT (which is created when you run winnt32 /noreboot). I wonder if it's possible to use that to our advantage. Rename that listing instead of i386. Just thinking out loud.

*EDIT*

Just realized, I think that's what Viking was talking about above.

Edited by Jito463
Link to comment
Share on other sites

That's the one Jito463! :D

I'm thinking that if we could get it to work, we could have a similar system to what we currently use for multiboots. That is have a "BOOT" folder and a "SOURCE" folder instead of having to worry about AMD64 and I386 at the same time...

Link to comment
Share on other sites

Ok, I've been taking a few notes about the new (post-2003 SP1) setupldr.bin format versus the old (pre-2003 SP1) one. So far, I've only found a few points of interest, which may or may not already be known:

  • setupldr.bin is actually two parts. The first is the "boot image" (the correct term escapes me at the moment), and the second being a PE (exe) file.
  • setupldr.bin and ntldr are identical up until a little ways into the PE header.
  • If you strip off the first part, you can disassemble the remaining EXE portion with any disassembler.
  • The checksum portion of the PE header isn't used, much less used to verify that the file has been modified.
  • You can edit the first part without it throwing a "NTLDR is corrupt" message. Tested by editing only the three occurances of "NTLDR is corrupt".
  • The third occurance of "NTLDR is corrupt" is the one that is actually printed when editing an occurance of "I386". I haven't tested editing each occurance of "i386", "I386", and "amd64", one at a time, to see if the other messages are used anywhere.

I think the most important thing here is the separation of the two parts: the boot image that calls the setup loader, and the setup loader .exe itself. It's only logical that the checksum exists in the boot image portion, which is under 20kB in size, and is only a couple kB larger than the pre-2003 SP1's boot image portion. This is good, because it almost entirely rules out any "complex" integrity checking, which leaves the only viable option that comes to mind being CRC/CRC32.

I've been known to get bored of projects and put them off indefinitely, so I figured I should dump my notes/thoughts here before that happens. I still have a few more ideas though, and I'll let you know if they turn up anything interesting.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...