Boot.ini question

Folkert Rienstra wrote:

And /your/ point is?

You want me to spell it out for you?

If that would be possible... ?!?

Antoine Leca wrote:

I am standing on my original point: it varies!

And I'm with you 100% on this

Gerhard

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!

No it isnt. AND NO ONE ELSE'S DOCUMENTIONATION OF
THE ARC PATH NAMING CONVENTION EVEN MENTIONS
ANY HARD DRIVE BOOT ORDER LIST EITHER.

There might just be a damned good reason for that, child.

AND you havent even established that getting the ordinal for
the rdisk() param from the hard drive boot order list is seen
with ANYTHING except that steaming turd of a bios in that
particular Dell system you are using yourself. And in fact
Antoine has rubbed your nose in the FACT that it isnt with
the Dell system he tried it with as well.

AND its a terminally stupid way to determine the ordinal
for the rdisk() param ANYWAY, because that means that
the rdisk() param in boot.ini cant be used WHEN THE DRIVE
DOESNT APPEAR IN THE HARD DRIVE BOOT ORDER LIST
AND YOU WANT TO BE ABLE TO BOOT AN OS FROM THAT.

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

Pity about
http://www.microsoft.com/resources/d...d_std_ccef.asp
which even someone as stupid as you should be able to work
out actually applys to 2K server, you silly little ****wit child.

Pity about
http://www.microsoft.com/resources/d...c_str_masc.asp
which even someone as stupid as you should be able to
work out actually applys to XP, you silly little ****wit child.

The document is as obsolete as you are

Pity you cant cite even a single document from MS or anyone else
that even mentions anything about the rdisk() parameter and any
hard drive boot list ordinal, and that you havent even established
that that is the way its done in anything but that particular steaming
turd of a bios in that particular Dell system you are using yourself.

Antoine has rubbed your silly little nose in the
FACT that it isnt even universal with Dells.

Keep desperately digging, child, you'll be out in china any day now, again.

"craigm" wrote:
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


Exactly! The document *still* says nothing about how the "rdisk()"
ordinal is to be determined. Here is what it says:

"Y Specifies a physical hard disk attached to drive controller W.
For ATA controllers, this number is typically between 0 and 3.
For SCSI controllers, this number is typically between 0 and 7,
or 0 and 15, depending on the adapter type. The first valid
number is 0."

So, given that and previous vacuums, Phoenix and Dell gave
it a meaning that made sense, met Microsoft's vague requirements,
and which was useable and convenient.

*TimDaniels*

Timothy Daniels wrote
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.

Lying, again. MS actually uses the description
'Z is the ordinal for the disk on the adapter'

Even someone as stupid as you should be able to
work out that there is no mention what so ever of
any hard drive boot order list or any ordinal IN THAT.

Since then, Phoenix and/or Dell decided that the ordinal would be
thehard drive boot order

You aint even established that when Antoine has rubbed
your nose in the fact that it isnt in a different Dell system.

- which in the *default* case is derived from the IDE channel no. and
the Master/Slave settings of the hard drives.

Pity that the default is completely irrelevant when the user
can change the order in the boot order list. That is the
WHOLE POINT OF HAVING A BOOT ORDER LIST.

AND that determining the ordinal from the boot order list
requires that the boot.ini be edited when any change is
made to the location of a particular drive in that list.

AND that when the ordinal is determined from the hard
drive boot order list, you cant even have a reference to
a drive WHICH ISNT IN THE BOOT ORDER LIST, so
you cant boot from it using boot.ini

It makes no sense to bind one's thinking and
expectations to vague and obsolete documents.

Nothing obsolete about the XP documentation
of the ARC path naming convention, liar.

Time and technology move on,

And only a terminal ****wit determines the ordinal for the
rdisk() param from the hard drive boot order list for the
reasons listed above, you silly little pig ignorant clown.

Folkert Rienstra wrote
Rod Speed wrote
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?

Village eejut mode baits no hooks, ****wit.

Reams of puerile attempts at a troll that fools
absolutely no one at all, flushed where they belong.

Folkert Rienstra wrote
Rod Speed wrote
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,

Wrong.

Right.

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.

Never ever could bull**** its way out of a wet paper bag.

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.

Never ever could bull**** its way out of a wet paper bag.

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

Not relevant to the story with ntldr.

"Gerhard Fiedler" faked it:
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.


On Feb 1, in the thread "Boot.ini question", I posted:

"ABSTRACT

"This experiment shows that the Phoenix Technologies BIOS
exposes the hard drive boot order to ntldr such that the para-
meter "rdisk(x)" in the boot.ini file corresponds to the hard
drive having a displacement "x" from the head of the hard
drive boot order, where "x" is a positive integer starting with 0.

"HARDWARE

"Dell Dimension XPS-R450 with a Phoenix Tech BIOS,"


On Feb 2, in the thread "meaning of 'rdisk()' in boot.ini file",
I posted:

"ABSTRACT

"This investigation shows that the "rdisk()" parameter
in the boot.ini file represents a hard drive in terms of
its displacement from the head of the hard drive boot order
in the BIOS. The value of n in "rdisk(n)" expresses this
displacement, where n is an integer value starting with 0,
and where "rdisk(0)" represents the hard drive which is at
the head of the hard drive boot order, i.e. the hard drive
at zero displacement from the head of the hard drive boot
order. The BIOS used in the investigation was the Phoenix
Technologies BIOS as supplied in Dell Dimension desktop
PCs.

"HARDWARE

"Dell Dimension XPS-R450 with a Phoenix Tech BIOS,"


Those are very clear statements of my position, having far
more clarity than those of anyone else in the history of this
newsgroup. No one has yet matched them in thoroughness
or clarity of methodology. If they don't apply to all Dell
desktop PCs in the last 5 years, let someone show it with
equal clarity.

*TimDaniels*

"Rod Speed" strained:
AND NO ONE ELSE'S DOCUMENTIONATION OF
THE ARC PATH NAMING CONVENTION EVEN MENTIONS
ANY HARD DRIVE BOOT ORDER LIST EITHER.

There might just be a damned good reason for that, child.



Yes, of course. Microsoft left it up to the BIOS producers
to define how the "adapter ordinal" is determined.



AND its a terminally stupid way to determine the ordinal
for the rdisk() param ANYWAY, because that means that
the rdisk() param in boot.ini cant be used WHEN THE DRIVE
DOESNT APPEAR IN THE HARD DRIVE BOOT ORDER LIST
AND YOU WANT TO BE ABLE TO BOOT AN OS FROM THAT.



Stupid is as stupid does. Since you don't *know* enough
to use the method, you don't use it. But Dell and Phoenix
Technologies figured that there existed a smarter brand of
user who would like the added flexibility and convenience.
I've reported my findings for *them*, not worn out sock
puppets.

*TimDaniels*

"Rod Speed" wrote:
Timothy Daniels wrote
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.

Lying, again. MS actually uses the description
'Z is the ordinal for the disk on the adapter'



You're funny. Now define "ordinal for the disk on the adapter".

*TimDaniels*