Re: Boot.ini question

Antoine Leca <root@xxxxxxxxxxxxxxxxx> wrote
Rod Speed wrote
Antoine Leca <root@xxxxxxxxxxxxxxxxx> wrote
Gerhard Fiedler wrote

ntldr may be able to load Windows from drives the BIOS can't boot from

What you seem to miss is that Tim's BIOS does not have such a concept.

Irrelevant to the whole point of the rdisk() parameter.

Problably yes. Like the most part of this thread...

Nope, the whole point of this thread is what the
rdisk() param means, and Timmy's original claim
that its the ordinal in the 'hard drive boot order'
list, even with bios which dont even have one.

All that proves is that Tim's BIOS is a complete abortion
that utterly flouts the whole point of the rdisk() parameter.

I disagree.

Your problem. The whole point of boot.ini is that it allows
NT/2K/XP to be booted from drives and partitions that the
bios cannot boot and to provide a decent menu at boot time
so the user can select what he wants to boot at boot time.

Having the rdisk() param the ordinal in the hard drive
boot order list is a complete abortion for two reasons.

One problem is that if the order in the hard drive boot order list
is changed, the boot.ini needs to be edited if it involves those
drives which have been moved in the list. That is not required
if the rdisk() param is the drive on the controller instead.

AND there isnt any point in having the rdisk()
param as the ordinal in the hard drive boot order
list. That achieves absolutely nothing useful at all.

AND the other big downside with having the rdisk() param
as the ordinal in the hard drive boot order list is that you
cant boot from a drive which isnt actually in the hard drive
boot order list. With the MS approach you can.

There isnt even any evidence that Dell or whoever perpetrated
that abortion even intended it, its much more likely that
someone fucked up completely and it was unintended.

Sure, one of my BIOS, and an awful large number of other BIOSes
out there as well, do have such drives; yet, there are other BIOSes
which allow to boot easily from any drive recognized by the BIOS
(BAID),

Not when its a logical drive in an extended dos partition.

Now *I* ask what is the relevance of this remark
with the whole point of the rdisk() parameter.

The whole point of the boot.ini was to allow booting of what the bios
could not boot. That is STILL true of a logical drive in an extended
dos partition, almost no current bios allows those to be booted by
the bios. I'm not aware of any that allows that.

For what it is worth, I think it is possible to succesfully
boot Ntldr in a logical partition, using bootstrap code
in EPBR and changing the HiddenSectors parameters.

I wasnt talking about that, I was talking
about where the OS comes from, not ntldr.

That was always one reason for the ntldr approach,

Sure, but again I do not see the point w.r.t. rdisk().

See above.

to allow booting of what the bios could not boot.

The very purpose of Ntldr+Boot.ini, like any
boot loader, is to enhance flexibility, yes.

And to allow booting that the bios cannot do, like
booting an install of the NT/2K/XP family from a
logical drive within an extended dos partition.

It makes a hell of a lot more sense for the rdisk() param to
be the physical order of the drives on the controller instead

I disagree:

Your problem.

I routinely boot an array (on a different controller)
using rdisk(N), with N being beyond the number of
drives on the first controller (where Boot.ini stands).

And I perfectly know that when I add or remove a
disk in the first controller (usually because it is down),
I have to adjust the rdisk() parameter accordingly.

That isnt using the ordinal in the hard drive boot order list.

so that the boot.ini doesnt need to be changed when
the hard drive boot order is changed, particularly
when the order of the drives below the entry at
the top of the hard drive boot order list are moved.

Sorry, I cannot make a sense of this.
Particularly, on a AMI bios I am using regularly, there
is no such thing as a "hard drive boot order list";

That clearly isnt the case when the hard drive boot order
list is the ordinal which is the rdisk() param, by definition.

as I am saying since the first post after Tim's...

As I also said a number of times in this thread. If there
aint even a hard drive boot order list, the rdisk() param
cant possibly be the ordinal in the hard drive boot order
list because there isnt one in some bios.

(that is, it can't load ntldr from them).

That's two different things. Being able to boot from
a harddisk is ordinarily reserved to the 80h drive;

No it isnt with modern bios.

I know this is not required. In fact, it might
have worked back in 1990 or even earlier...

However, you have to assume this unless you want to
play dangerously: far too much code out there assume
blindly _or_ studbornly the booting harddisk is 80h.

Irrelevant to what ntldr and what loads it does.

Tim claimed that the rdisk() parameter is
ALWAYS the entry in the hard drive boot list.

Did not read the word "always" in his post: it just proposed a way
to think the rdisk() parameter as a "relative" position in this list.

The word 'think' was never used.

And before you elaborate: if you find a quote of him
saying "always", I would claim he was wrong on this one.

Thats what he said without using that particular word.

Thats the way english works.

As I said since the beginning.

That its just plain wrong, and all he has proved is that it
is with that complete abortion of a bios he is using and

Nothing for me to comment here.

there are damned good reasons for not doing it like that.

Yes, I agree, you can find good reasons to
keep the order as stable, that's a good point.

And no good reason at all to use the ordinal in the hard drive
boot order list for the rdisk() param. Not even a poor reason.

And its certainly not what MS intended because none of the
ARC path documention even mentions the boot order list at all.

Here I disagree, for two reasons.

One is that the ARC path rdisk(N) mechanism was designed around
1990 to make a gateway between the RISC world (where NT originally
was born) and the Intel/IBM/Compaq "i386" architecture; that's long
before BBS. I very much doubt if MS had the choice, they will still
use it in 2006 (NT on MIPS anyone?) As such, it is much of a
legacy of the history, like for example the Int13 interface itself.

Thats just plain wrong with the most basic functionality of boot.ini,
to provide a way to specify where the various OSs etc are on the
hard drives. That has to do be done somehow with any boot manager.

The second is that MS had become the "official" source for the
ARC path mechanism, failling any alternative. Whatever they
publish as documentation will instantly becomes the Standard.
So it is normal practice for themselves to keep gray areas
("undocumented", as Andrew Schulman &alii tagged it)
in order to allow paths for future expansions, as long
as doing so does not hamper interoperability.

Nothing grey about the MS statement that the rdisk()
param is the ordinal of the drive on the controller.





.