Boot.ini question

Timothy Daniels wrote
Rod Speed wrote

Irrelevant to what MS intended the rdisk() param to refer to.

Even someone as stupid as you should be able to grasp that
it cant have been intended to refer to the entry in the hard drive
boot order list when it was introduced at a time when NO PCS
ACTUALLY HAD A HARD DRIVE BOOT ORDER LIST.

I'm only reporting the reality of Today.

No you arent. ALL you are doing is mindlessly rabbitting on
about WHAT A PARTICULAR ****ED DELL BIOS DOES
ABOUT THE RDISK() PARAM. You arent even stating
what all current Dell bios do according to Antoine.

Your reality belongs to the Past.

No it doesnt. There is NO MENTION WHAT SO EVER BY
MS OR ANYONE ELSE THAT THE RDISK() PARAM REFERS
TO THE ORDINAL IN THE HARD DRIVE BOOT ORDER LIST.

There's a reason for that, stupid.

"Rod Speed" wrote in message
Antoine Leca wrote
Rod Speed wrote
Antoine Leca wrote
Rod Speed wrote
Antoine Leca wrote

Correct, assuming the generally used meaning for
"boot order sequence" ("order inside the IPL table",
also known as "IPL Priority", according to the standard.)

Where exactly are you getting that from ?

Compaq-Phoenix-Intel, BIOS Boot Specification Version 1.01, 1996, 46 p.

http://www.phoenix.com/NR/rdonlyres/...pecsbbs101.pdf
Would you have read/meant anything else?

It wasnt at all clear if you were claiming that it
was general to all bios or just to the Phoenix.

[snip]

???
Compaq, Intel and Phoenix are the 3 "copyright holders" or "authors"
(can't nor want find which is correct here) of this document which is
generally seen as "an industry standard" on the matter.

[snip]

There is considerable variation on how it is implemented among
the various BIOS vendors/providers. But the mandatory part is
implemented by all the BIOS I have seen since about 7 years.

[snip]

Also there is variation on how the various things
are named, which is why I used the standard term.

[snip]

Its much better to test it in the simple config of a motherboard
with just two IDE ports and no RAID controller etc to simplify things.

The problem I have with this idea is that by _any_
mean the BIOS allows you to boot the "other"
IDE disk, the BIOS will just switch 0x80 and 0x81,

That is just plain wrong.

Only on the part of "IDE".

In spades when the bios allows you to specify a boot
order with more than just one hard drive in the list.

And the boot drive will have device 0x80 regardless
nomatter how many there are in the list, clueless.


and you cannot make any clear and
ambiguous conclusion about its internal lists.

[snip]

Which is the underlying problem. I very much
prefer experimenting a bit with slightly longer lists.

[snip]

That's said, since I wrote this, I did some experiment with BIOSes
of two breeds, and they behave _widely_ differently at the respect.

And since Tim, using BIOS of the same maker (Phoenix+Dell)
but a different submodel, got results quite different from mine,
I am standing on my original point: it varies!

[snip].

"Rod Speed" wrote in message
Antoine Leca wrote
Rod Speed wrote
Folkert Rienstra wrote
Gerhard Fiedler wrote

Since at this point neither Windows nor any kind of DOS has been
loaded,

NTLDR is filesystem aware.

Irrelevant to whether Windows or any kind of DOS has been loaded.

Exactly. I'm so glad you agree with me.


Well, if DOS means "Disk Operating System",
NTLDR qualifies as a reduced one:

No it doesnt. Its always possible for any app to be file system
aware without being anything like an OS. That is seen with
some of the early imagers for example where they were
NTFS aware when running on DOS which isnt NTFS aware.

it certainly lacks many features you can expect (such as user
programability, just as most embeeded OS), but the basic ones
such as disk/FS support and resource management are.

Just being file system aware doesnt make it an OS.

Apps have always been able to operate directly on
a file system without there even being any OS at all,
tho you dont see that done very much anymore.

Even a modern DOS boot is file system aware in the sense
that the most basic files used for booting DOS dont need to
be in a fixed location on the drive. They are found using the
file system aware loader, by file name, not physical location.

And with BootMgr, you even will get
some limited form of programability.

Doesnt make it an OS either. Most boot managers have
some form of programability but they arent an OS either.

Thanks Roddles, for helping debunk Fiddlers 'point' with us.


Look at SysLinux, its open source equivalent, to get my idea.

Not relevant to the story with ntldr.

"Antoine Leca" wrote in message
En , Rod Speed va escriu
Antoine Leca wrote
Rod Speed wrote
Antoine Leca wrote
Correct, assuming the generally used meaning for
"boot order sequence" ("order inside the IPL table",
also known as "IPL Priority", according to the standard.)

Where exactly are you getting that from ?

Compaq-Phoenix-Intel, BIOS Boot Specification Version 1.01, 1996, 46 p.
http://www.phoenix.com/NR/rdonlyres/...pecsbbs101.pdf
Would you have read/meant anything else?

It wasnt at all clear if you were claiming that it
was general to all bios or just to the Phoenix.

And since the bios are considerably modified by the motherboard
manufacturer, it isnt at all relevant what Compaq has chosen to do.


???

It was just the usual sorry excuse to mask that he had never heard of it.

[snip]

"Rod Speed" wrote in message
Antoine Leca wrote
Gerhard Fiedler wrote

ntldr gets read from disk, loaded into memory and then run by the
BIOS. Since you seem to object to the common term "booting" for
this, I'll call this for the rest of the discussion "loading ntldr".
Since ntldr gets loaded by the BIOS, it only can be loaded by the
BIOS from drives the BIOS can boot from (sorry for this confusing
term g, but that's the one you were using).

Admitting this lemma...

What's a lemma ?

This would be the drives in the BIOS's "hard drive boot order" list.

... it does not match with what Tim was saying initially.

Yes it does.

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.

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

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.

Huh?


That was always one reason for the ntldr approach,
to allow booting of what the bios could not boot.

and furthermore it seems reasonable to envision this.

[snip]

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

Utterly clueless, as always.


being able to load Ntldr (into memory) is not so restricted.


Not clear what this is about,

So obviously any further comment can be ignored.

[snip]

"Rod Speed" wrote:
Timothy Daniels wrote:
In the Microsoft document "How to Determine the ARC Path"
(http://support.microsoft.com/default...b;en-us;155222)
it is stated:

"A typical ARC path might be:

multi(0)disk(0)rdisk(0)partition(2)\WINNT="My Server 4.0"

"The rdisk parameter is defined as HarddiskX on the
TargetDevice line, where X is a variable that represents
the drive ordinal. Note that the rdisk parameter is not used
when SCSI replaces multi in the ARC path."

Clearly, "rdisk()" refers to the position of the physical hard,
but it does NOT state how that position (i.e. the "drive ordinal")
is derived.

Yes, but the boot order list doesnt even get a mention, and when the
ARC path naming convention originated at a time when there wasnt
even a hard drive boot order list in most if any bios, it should be
obvious to even someone as stupid as you that it was never intended
to be the ordinal in the hard drive boot order list that didnt even exist.



Exactly why you shouldn't have quoted Microsoft's ARC path
documents - it's OBSOLETE!


That is left open to interpretation by manufacturers such as Dell, to BIOS producers such as Phoenix Technologies, and to ROM
chip producers such as Intel.

Wrong again. The detail just isnt spelt out explicitly in THAT
particular KB article which has a VERY limited purpose. It
aint anything like the definitive statement of the ARC path
naming convention used in boot.ini, let alone saying anything
about who gets to determine how the ordinal is determined.

http://support.microsoft.com/kb/102873/EN-US/
has a much clearer statement about the rdisk() parameter and it says

[...........]

Z is the ordinal for the disk on the adapter and is usually a number between 0 and 3.

---------------my comment
This is the rdisk parameter and that clearly says DISK ON THE ADAPTER
and says nothing about any hard drive boot order list what so ever.
---------------my comment


And the Microsoft document clearly states that the document
applies to:

• Microsoft Windows NT Advanced Server 3.1
• Microsoft Windows NT Server 3.5
• Microsoft Windows NT Server 3.51
• Microsoft Windows NT Server 4.0 Standard Edition
• Microsoft Windows NT Workstation 3.1
• Microsoft Windows NT Workstation 3.5
• Microsoft Windows NT Workstation 3.51
• Microsoft Windows NT Workstation 4.0 Developer Edition
• Microsoft Windows NT Advanced Server 3.1


The document is as obsolete as you are, sock puppet.

*TimDaniels*

"Rod Speed" wrote:
Timothy Daniels wrote
Rod Speed wrote

Irrelevant to what MS intended the rdisk() param to refer to.


What MS intended in the misty past is that "rdisk()" specify
a hard drive and that it's related to some "adapter ordinal".
It doesn't say how that ordinal is to be determined. Since then,
Phoenix and/or Dell decided that the ordinal would be the
hard drive boot order - which in the *default* case is derived
from the IDE channel no. and the Master/Slave settings of
the hard drives. It makes no sense to bind one's thinking and
expectations to vague and obsolete documents. Time and
technology move on, sock puppet.

*TimDaniels*

Timothy Daniels wrote:
"Rod Speed" wrote:

Timothy Daniels wrote:

In the Microsoft document "How to Determine the ARC Path"
(http://support.microsoft.com/default...b;en-us;155222)
it is stated:


"A typical ARC path might be:


multi(0)disk(0)rdisk(0)partition(2)\WINNT="My Server 4.0"


"The rdisk parameter is defined as HarddiskX on the
TargetDevice line, where X is a variable that represents
the drive ordinal. Note that the rdisk parameter is not used
when SCSI replaces multi in the ARC path."


Clearly, "rdisk()" refers to the position of the physical hard,
but it does NOT state how that position (i.e. the "drive ordinal")
is derived.


Yes, but the boot order list doesnt even get a mention, and when the
ARC path naming convention originated at a time when there wasnt
even a hard drive boot order list in most if any bios, it should be
obvious to even someone as stupid as you that it was never intended
to be the ordinal in the hard drive boot order list that didnt even
exist.




Exactly why you shouldn't have quoted Microsoft's ARC path
documents - it's OBSOLETE!


That is left open to interpretation by manufacturers such as Dell,
to BIOS producers such as Phoenix Technologies, and to ROM chip
producers such as Intel.


Wrong again. The detail just isnt spelt out explicitly in THAT
particular KB article which has a VERY limited purpose. It
aint anything like the definitive statement of the ARC path
naming convention used in boot.ini, let alone saying anything
about who gets to determine how the ordinal is determined.

http://support.microsoft.com/kb/102873/EN-US/
has a much clearer statement about the rdisk() parameter and it says

[...........]

Z is the ordinal for the disk on the adapter and is usually a number
between 0 and 3.

---------------my comment
This is the rdisk parameter and that clearly says DISK ON THE ADAPTER
and says nothing about any hard drive boot order list what so ever.
---------------my comment



And the Microsoft document clearly states that the document
applies to:

• Microsoft Windows NT Advanced Server 3.1
• Microsoft Windows NT Server 3.5
• Microsoft Windows NT Server 3.51
• Microsoft Windows NT Server 4.0 Standard Edition
• Microsoft Windows NT Workstation 3.1
• Microsoft Windows NT Workstation 3.5
• Microsoft Windows NT Workstation 3.51
• Microsoft Windows NT Workstation 4.0 Developer Edition
• Microsoft Windows NT Advanced Server 3.1


The document is as obsolete as you are, sock puppet.

*TimDaniels*








Try this one.
http://www.microsoft.com/resources/d...c_str_masc.asp

"Rod Speed" wrote:
Antoine Leca wrote
That's said, since I wrote this, I did some experiment with BIOSes
of two breeds, and they behave _widely_ differently at the respect.

And since Tim, using BIOS of the same maker (Phoenix+Dell)
but a different submodel, got results quite different from mine,
I am standing on my original point: it varies!

Which supports the proposition that Tim's is a complete
abortion perpetrated by Dell with that PARTICULAR bios,
not even universal to Dell or Phoenix as he claimed, let
alone across all bios on all systems as he originally
claimed. Just another bios that someone has
comprehensively stuffed up the rdisk() parameter with.


The only sensible way to test THAT claim is with
the simplest config of 3 hard drives, with the only
boot.ini on the drive at the top of the boot order list
and swapping the order of the two other drives
which are below that in the boot order list and
see which drive gets booted when the user selects
a particular entry with a particular rdisk() value in
the ntldr boot menu.


Well you've described the minimal test.
What does "Antoine Leca" have to say about the results
of such a test?
So far, we don't even know what model of Dell he tested
or what his methodology or results were.
How about system specs, a full test and the results, Antoine?

*TimDaniels*

Antoine Leca wrote:

This would be the drives in the BIOS's "hard drive boot order" list.

... it does not match with what Tim was saying initially.

Well, yes, it does. If you don't have a newsreader with the history of this
thread, I would gladly provide you with quotes.


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

No, I don't miss this -- Tim is missing that this is a special case of his
BIOS.

Tim didn't say "on /my/ machine, the rdisk number seems to be equivalent to
the position in the hard disk boot order list" -- he claims this to be the
case on /all/ machines. Which I seriously doubt, and it seems I'm not alone
with this.

I don't claim to be a specialist in the boot process, but if something
doesn't match, it doesn't.

Whether ntldr can load Windows from a drive has nothing to do
with whether the BIOS can load ntldr from that drive.

(Of course, due to entertraining confusion, one has to mentally change "to
load" to the more generally used "to boot" above).

Right... not my idea, though; just trying to accommodate Tim


This are two different processes -- one is controlled by the BIOS,
the other is controlled by ntldr.

Well, here you mean "to control" to designate the binary code which is
executing initially.

Yes.

I would reserve "to control" to designate the small, configurable, part
of the process; in the first case, we'll find the "boot order" (whatever
that means), and also the actual MBR and secondary boot code; in the
second case, Boot.ini.

Also makes sense, but doesn't affect the issue: the rdisk number can point
to a drive that doesn't appear in a "hard disk boot order list" (as it is
called by Tim).

What is important here is that both are not completely independant;
particularly, if you change the "boot order" (and hence the placement of the
Boot.ini file, Rod's main point, very true indeed), you could also affect
the interpretation of Boot.ini.

How does the placement of the boot.ini file get changed with the boot
order? The file is there, right with the ntldr, on the active partition. It
doesn't run... Of course, changing drives around (or, in some BIOSes
changing some configurations) can affect the interpretation of the
boot.ini, because the rdisk numbers can change.


Which, ultimately, was Tim's point.

Not quite. You got me there... I need to quote

First post by Tim in this thread:

You can also think of "rdisk()" as meaning the "relative disk position",
that is, relative to the head of the BIOS's hard drive boot order.

Sounds clear as water. A drive not in the hard drive boot order does not
have an rdisk number, according to this description (and his follow-up
clarifications).

Gerhard