23 replies to this topic

[pscEx]

Sometimes in the forum the question came up to run a PE from a folder different from 'I386'

I changed nativeEX accordingly. script.Project now contains a variable %nEXWin% which currently is I386.

It can be changed to any other valid folder name.

The internal programs like HoJoPE are changed to use %nExWin% rather than I386. All scripts delivered from the Download center are changed, too.

You may play with this new project.

But: Currently any name different from I386 brings a error message that NTLDR could not be found.

Maybe there are experts in the forum to solve this issue.

For 'normal users': Do not worry about this post. If you do not change the value of the %nExWin% variable, nothing changes for you

Peter

[MedEvil]

NTLDR can't be found?
That means that you havn't adopted the boot sector of your CD, to point to the new location.

Good Luck,
cause i forsee your next question.

[pscEx]

That means that you havn't adopted the boot sector of your CD, to point to the new location.

Seems to be a good hint.
But as you know: I'm a fool.
How to adapt the boot sector?
(I'm a fool, but also a good programmer. If you tell me what do do, I do)

Peter

[was_jaclaz]

NTLDR can't be found?
That means that you havn't adopted the boot sector of your CD, to point to the new location.

Hey wait a minute people.

The "normal" bootsector on CD ( the no-emulation mode bootsector called "Microsoft Corporation.img or "Arnes Boot Record.img")
points to SETUPLDR.BIN in the ROOT of the drive.

psc,
can you detail what bootsector you are using and what file are you using to boot the NT system?

jaclaz

[MedEvil]

Seems to be a good hint.
But as you know: I'm a fool.
How to adapt the boot sector?
(I'm a fool, but also a good programmer. If you tell me what do do, I do)

Peter

Oh that's not hard at all. Just open the bootsector with a hexeditor and change the foldername.
Should read something like i386/ntldr.

Though i think, you might have a problem with a foldername longer than 4 characters.

[was_jaclaz]

Medevil,
please re-read my post just above yours.

jaclaz

[pscEx]

@jaclaz, @medevil: reply for both posts:
First let me say, that I have a very low knowledge about 'how a computer can boot?'

As described in my last post, I just changed every 'i386' (including my programs) to %nExWin%.

I did not change e.g MkISOFs (embedded bootsect.bin from ???)

Now the test:

%nExWin% = I386 runs well as before
%nExWin% = WINX gives the error I posted.

Using a hex editor I changed I386 inside bootsect.bin to WINX, made a new ISO and tried.
It gave me an endless trial of qEmu to start the cd.
(It is so fast that I cannot read any error messages)

Any idea?
Is there something like md5 in bootsedct.bin?

BTW: You can try it on your PC after download of the actual version.

Peter

[MedEvil]

Medevil,
please re-read my post just above yours.

jaclaz

No need to reread! Have not read it before. You posted, while i had the editor open to answer psc.

[MedEvil]

@jaclaz, @medevil: reply for both posts:
First let me say, that I have a very low knowledge about 'how a computer can boot?'

As described in my last post, I just changed every 'i386' (including my programs) to %nExWin%.

I did not change e.g MkISOFs (embedded bootsect.bin from ???)

Now the test:

%nExWin% = I386 runs well as before
%nExWin% = WINX gives the error I posted.

Using a hex editor I changed I386 inside bootsect.bin to WINX, made a new ISO and tried.
It gave me an endless trial of qEmu to start the cd.
(It is so fast that I cannot read any error messages)

Any idea?
Is there something like md5 in bootsedct.bin?

BTW: You can try it on your PC after download of the actual version.

Peter

@jaclaz
Only the ntldr of a installed system is located in the root. Setupldr on a cd is inside the i386 directory.

@psc
The errors you see come from the fact that ntldr was found and now complains that he can't find the files he wants to load.

Maybe it will work if you set the boot sector to look for ntldr in the root? But you will need to put ntldr and ntdetect there.

[pscEx]

@psc
The errors you see come from the fact that ntldr was found and now complains that he can't find the files he wants to load.

Maybe it will work if you set the boot sector to look for ntldr in the root? But you will need to put ntldr and ntdetect there.

Can you try to do it with my latest upload and then post it here?

Peter

[pscEx]

@psc
The errors you see come from the fact that ntldr was found and now complains that he can't find the files he wants to load.

Maybe it will work if you set the boot sector to look for ntldr in the root? But you will need to put ntldr and ntdetect there.

Can you try to do it with my latest upload and then post it here?

Peter

[was_jaclaz]

Basically Windows Install CD's (read PE CD) use the third of the three possible boot standards:
1) el-torito emulation mode (floppy 1.44 or 2.88)
2) el-torito emulation mode (hard disk image)
3) no-emulation boot (special bootrecord)

The no emulation bootrecord is a 2,048 bytes file that invokes another loader, in XP Install/PE CD's the file is SETUPLDR.BIN in the ROOT \I386 directory of the drive.
http://www.technipag...Corporation.img

The fact that in this file the string "I386" is present, has nothing to do with the actual booting of the CD. WRONG see post below!


You can use grldr from Grub4dos as a no-emulation bootrecord, if you use mkisofs with a command line like the one found here:
http://www.911cd.net...o...18045&st=25
than you add to it a menu.lst like:

color black/cyan yellow/cyan
timeout 10
default 0

title PE disc
chainloader /SETUPLDR.BIN

It will boot EXACTLY like the original, and there is NO trace of "I386" in it grldr itself.

The path, on the contrary is hard encoded inside SETUPLDR.BIN, you might want to have a look at this:
http://www.msfn.org/...opic=58410&st=0

jaclaz

P.S.: are we talking about a CD right?

[MedEvil]

Can you try to do it with my latest upload and then post it here?

Peter

Would be willing, but the wife called, has something to celebrate.
Doesn't look like i will get the evening off.
Maybe tomorrow.

[MedEvil]

Basically Windows Install CD's (read PE CD) use the third of the three possible boot standards:
3) no-emulation boot (special bootrecord)

Check!

The no emulation bootrecord is a 2,048 bytes file that invokes another loader, in XP Install/PE CD's the file is SETUPLDR.BIN in the ROOT of the drive.

Don't know where you googled,
but have a look at you XP CD, there is no setupldr in the root.

The path, on the contrary is hard encoded inside SETUPLDR.BIN, you might want to have a look at this:
http://www.msfn.org/...opic=58410&st=0

I know, patchy patchy.

P.S.: are we talking about a CD right?

Why, have your heard something else?

[was_jaclaz]

Don't know where you googled,
but have a look at you XP CD, there is no setupldr in the root.

Yes, you are perfectly right, I had a complete and utter "brain fart" , making confusion with a non-CD bootrecord..

Correcting my previus post.....


The bootsector contains the string:

SETULDR.BINBOOTFIX.BINI386

you can change the last "I386" to any four letter string ALL CAPITAL and EXACTLY 4 letters long and put SETUPLDR.BIN and all the other files in a similarly named directory.

Then you need hexediting SETUPLDR.BIN in which you need to change the same values for all the occurrences of "I386" inside. (there should be 4 of them).

I guess that the value in the bootrecord can be changed even to something longer, but there is no space in SETUPLDR.BIN to do the same....

NTLDR is not involved in any stage of CD booting a PE, though in the same bootrecord, there are these error messages:

CDBOOT: Cannot boot from CD - Code: 0
CDBOOT: Couldn't find NTLDR

jaclaz

[pscEx]

Yes, you are perfectly right, I had a complete and utter "brain fart" , making confusion with a non-CD bootrecord..

Correcting my previus post.....


The bootsector contains the string:
you can change the last "I386" to any four letter string ALL CAPITAL and EXACTLY 4 letters long and put SETUPLDR.BIN and all the other files in a similarly named directory.

Then you need hexediting SETUPLDR.BIN in which you need to change the same values for all the occurrences of "I386" inside. (there should be 4 of them).

I guess that the value in the bootrecord can be changed even to something longer, but there is no space in SETUPLDR.BIN to do the same....

NTLDR is not involved in any stage of CD booting a PE, though in the same bootrecord, there are these error messages:


jaclaz

Thanks, Jaclaz! I'll try that.
But does it mean that e.g. 'MyWindows' is not possible?

Peter

[MedEvil]

Thanks, Jaclaz! I'll try that.
But does it mean that e.g. 'MyWindows' is not possible?

Peter

Not unless you find a way to write such a long name into setupldr.bin or replace it completely by another loader who can.

Googled a little this morning. :

Instead of reading the system registry hive (which will not be present
when no system has been installed) to locate device driver files to load,
SETUPLDR.BIN is hardwired to use TXTSETUP.SIF

In order to use minint switch, windows needs to be in folder minint.


Startup process (Wikipedia)
---------------------------
When booting, the loader proper portion of NTLDR does the following in order:

1. Accesses the file system on the boot drive (either FAT or NTFS).
2. If hiberfil.sys is found, and it finds a hibernation image, its contents are loaded into memory and the system resumes where it left off.
3. Otherwise, reads boot.ini and prompts the user with the boot menu accordingly.
4. If a non NT-based OS is selected, then NTLDR loads the associated file listed in boot.ini (bootsect.dos if no file is specified) and gives it control.
5. If an NT-based OS is selected, then NTLDR runs ntdetect.com, which gathers information about the computer's hardware. (If ntdetect hangs during hardware detection there is a debug version called ntdetect.chk which can be found on Microsoft support[1].)
6. Starts Ntoskrnl.exe, passing to it the information returned by ntdetect.com. [2]


Startup
--------
ntldr(root) - boot.ini(boot options) - ntdetect.com - ntoskrnl.exe -->
setupldr(/i386) - txtsetup.sif(bootoptions) - ntdetect.com - ntoskrnl.exe -->

txtsetup.sif
-------------
OsLoadOptions ="/fastdetect /minint"

- only setupldr can boot from a CD
? has ntldr a /minint switch or not, looks like not but sources vary


Will post the same facts on the PEit thread.

[was_jaclaz]

But does it mean that e.g. 'MyWindows' is not possible?

As said a workaround for the bootsector is easily achieved (just use another bootsector) but the problem within SETIPLDR.BIN still remains.

The 4 points where the string is present don't seem to allow anything more.

That means that most probably, disassembling SETUPLDR.BIN (which is a NO-NO) one could change some pointers and allow for more characters...

...but besides legal problems it is not easy at all.

jaclaz

[MedEvil]

Our own loader?
Let's see, what would it have to do?
It would have to be able to read at least CDFS. Maybe FAT for USB-Sticks too.
It would need to kick off ntdetect and recieve the answer. Though i'm not really sure if that would be needed in our case.
Feed all the right options to ntoskrnl.exe start it and transfer command to it. (This seems like the easiest part, unles M$ did something nasty. )

That's all! Any volunteers?

Does anyone know what ntdetect exactly detects that would be needed for our uses? I mean, we basicly throw all the default drivers in the system at start and use our own hardware detection later, don't we?

[smiley]

What about using reactos's freeldr or winldr?

It would be wiser to use one of them than creating a new one

[MedEvil]

What about using reactos's freeldr or winldr?

It would be wiser to use one of them than creating a new one

Doubt they will work, but has anyone ever tryed?

From what project is winldr?

[smiley]

From what project is winldr?

From reactos

[MedEvil]

From reactos

They have two loader? What for?

btw. How went your attemp to change the folder names in the registry?

[smiley]

They have two loader? What for?

The original is freldr but winldr is develped separated to support better windows booting.