Re: Boot.ini question

In news:44pl7uF3d1ahU1@xxxxxxxxxxxxxx,
Rod Speed va escriure:
Antoine Leca <root@xxxxxxxxxxxxxxxxx> wrote
Gerhard Fiedler wrote

Admitting this lemma...

What's a lemma ?

Sorry for my bad command of English.
I should have explained that there were details in the above part I did not
completely agree with, but it was not worth detailling, so I assumed this
starting position is agreed with.


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


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

I disagree.


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.

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.


That was always one reason for the ntldr approach,

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

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.


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


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"; as I am saying since the first post after
Tim's...


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


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.

And before you elaborate: if you find a quote of him saying "always", I
would claim he was wrong on this one. 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 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.

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.


Antoine

.

Relevant Pages

  • Re: Boot.ini question
    ... opposed to all entrys in that list including optical drives etc. ... that the rdiskparameter refers to the boot order list entry number. ... Irrelevant when testing for what the rdisk() parameter actually refers to. ...
    (comp.sys.ibm.pc.hardware.storage)
  • Re: XP Home and XP Pro on two separate drives
    ... , while the CD and DVD drives are on the other ... slave and boot from my old XP configuration (with the old drive as ... :> In the case of SATA HDs, the default HD boot order is just ... :> During installation of WinXP, ...
    (microsoft.public.windowsxp.setup_deployment)
  • Re: Boot.ini question
    ... Irrelevant to the whole point of the rdisk() parameter. ... out there as well, do have such drives; ... which allow to boot easily from any drive recognized by the BIOS ... The whole point of the boot.ini was to allow booting of what the bios ...
    (comp.sys.ibm.pc.hardware.storage)
  • Re: Boot.ini question
    ... 1- You claimed that the rdisk number is related to the boot order. ... 2- One consequence of this is that if a controller can't boot from a disk, ... 3- I can use boot.ini entries to start Windows on drives the controller ...
    (comp.sys.ibm.pc.hardware.storage)
  • Re: Boot.ini question
    ... 1- You claimed that the rdisk number is related to the boot order. ... 3- I can use boot.ini entries to start Windows on drives the controller ...
    (comp.sys.ibm.pc.hardware.storage)