Boot.ini question

[Rod Speed]

Fine with me, but doesn't matter. Just translate my terminology to
yours (I call a disk a disk and a partition a partition, but that's
just me

Since at this point neither Windows nor any kind of DOS has been
loaded, there are not yet any logical disks or drives; they only
exist within the context of an OS, otherwise they are simple
partitions. That's why it doesn't make a lot of sense talking about
them in the context of this thread. (You can't tell whether a
partition will be a logical drive within an OS or not without running
the OS or analyzing its configuration -- if it's not being mounted,
it stays just that, a partition, without becoming a logical drive.)



The words by themselves don't have a clear meaning. That's why I gave
above the meaning I am using. This should make it clear what I am
talking about. Rather than just whining about my terminology,
substitute it for your own (mentally) and read the /meaning/ of the
text. It in fact doesn't matter whether you use boot, start, load or
whatever -- as long as you define what you mean and use it
consistently. Which I did -- but you didn't, and that's in part your
problem. You didn't say what you use for the two completely different
processes: the one that gets ntldr into memory and run, and the other
that gets Windows into memory and run.

Since we were talking about the boot process as related to ntldr and
boot.ini, I found it appropriate to use Microsoft's terminology. But
you can use your own, too -- just make sure it is consistent.



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). This would be the drives in the
BIOS's "hard drive boot order" list.

ntldr then loads Windows into memory and starts it. Since you seem to
object to the common term "starting Windows" for this, let's call
this for the rest of the discussion "loading Windows". ntldr may be
able to load Windows from drives the BIOS can't boot from (that is,
it can't load ntldr from them). Whether ntldr can load Windows from a
drive has nothing to do with whether the BIOS can load ntldr from
that drive. This are two different processes -- one is controlled by
the BIOS, the other is controlled by ntldr.

According to you, these drives wouldn't have an rdisk number (because
they don't appear in the BIOS "hard drive boot order" list, because
the BIOS can't boot -- excuse me! -- load ntldr from them). Yet they
do have an rdisk number, because ntldr can load Windows from them.

Is this so difficult to understand? What's your problem?

He's extremely stupid.

 

[Folkert Rienstra]

Correct in that rdisk in boot.ini has meaning only to ntldr. Wrong in the
use of "booting":

it's meaning is the selection of a hard drive for starting Windows.

Which is usually referred to as booting the OS.

Windowses prior to NT (in number) could be started (from DOS).
Whether you can start Windows NT and up is debatable.
That depends on what you can do with it without it running.

You don't understand the difference between "booting" and "starting Windows".

And you do?

"Booting" is when the BIOS loads ntldr into memory and starts it.

Uh, no. Booting is loading and executing the MBR code (Int19).
The rest is simply follow-up stages in the total Boot process.

"Starting Windows" is after ntldr reads boot.ini, optionally displays the
selection menu and starts Windows from the controller, drive, partition
and directory indicated by the chosen entry.

This controller, drive and partition does not have to be bootable

by the BIOS.

But needs to be supported by it.

 

[Folkert Rienstra]

Which was introduced to allow the booting of NT
from drives which arent even in the bios boot order
list, before bios even HAD a boot order list at all.


Plenty of reasons for wanting an rdisk() value
for a drive that isnt even in the bios boot list,
and when there isnt even a bios boot list at all.

That was the WHOLE POINT of ntldr, stupid.


He didnt say that.


rdisk() was always the drive enumeration on the controller.

Which is controlled by BIOS.

[snip].

 

[Folkert Rienstra]

Fine with me, but doesn't matter. Just translate my terminology to yours (I
call a disk a disk and a partition a partition, but that's just me

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

Wrong. NTLDR is filesystem aware.

there are not yet any logical disks or drives;

Then how can it recognize the files to load.

they only exist within the context of an OS,

as drive letters, yes.

otherwise they are simple partitions.

With filesystems on them that NTLDR can access.

That's why it doesn't make a lot of sense talking about them in the
context of this thread.

It actually lies at the heart of it.

(You can't tell whether a partition will be a logical drive within
an OS or not without running the OS or analyzing its configuration --

Like NTLDR, you mean?

if it's not being mounted, it stays just that, a partition, without becoming
a logical drive.)

Ah, so if Windows doesn't run, you can't start it. Nice one, Fiedler.

The words by themselves don't have a clear meaning. That's why I gave above
the meaning I am using. This should make it clear what I am talking about.
Rather than just whining about my terminology, substitute it for your own
(mentally) and read the /meaning/ of the text. It in fact doesn't matter
whether you use boot, start, load or whatever -- as long as you define what
you mean and use it consistently.

Which I did -- but you didn't,

Pot, kettle, especially on the whining part.

and that's in part your problem. You didn't say what you use for the two
completely different processes: the one that gets ntldr into memory and
run, and the other that gets Windows into memory and run.

And how does that matter.

Since we were talking about the boot process as related to ntldr and
boot.ini, I found it appropriate to use Microsoft's terminology.
But you can use your own, too -- just make sure it is consistent.



ntldr gets read from disk, loaded into memory and then run by the BIOS.
Bollocks.

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,

Nope. Read what Timmy said.

it only can be loaded by the BIOS from drives the BIOS can boot from

Nope.
It can be loaded from any drive the MBR bootcode chooses
from provided that that drive is supported through BIOS.
Whether it does this depends on the code itself, not the BIOS.
MBR bootcode conventions say it can't. That's one of the reasons
for having NTLDR.

(sorry for this confusing term <g>, but that's the one you were using).
Nope.

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

So no.

ntldr then loads Windows into memory and starts it.

It's a lot more complex than that.

Since you seem to object to the common term "starting Windows" for
this, let's call this for the rest of the discussion "loading Windows".

Stop whining.

ntldr may be able to load Windows

from drives the BIOS can't boot from (that is, it can't load ntldr from them).

Using standard/conventional MBR bootcode.

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

Nope, same problem. MBR bootcode conventions prohibits that.

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

Nope. Controlled by MBR bootcode (using BIOS).

the other is controlled by ntldr.

Using that same BIOS but not hampered by the MBR bootcode conventions.

According to you, these drives wouldn't have an rdisk number (because they
don't appear in the BIOS "hard drive boot order" list, because the BIOS
can't boot -- excuse me! -- load ntldr from them). Yet they do have an
rdisk number, because ntldr can load Windows from them.

Is this so difficult to understand?
Apparently.

What's your problem?

Probably the same one that I'm having with you.
(Which is not to say that I don't have the same problem with Timmy).

 

[Rod Speed]

Which is controlled by BIOS.

Irrelevant to whether it makes any sense at all to have the bios
use the boot order list as the source of the number, ****wit.

 

[Rod Speed]

Right.

NTLDR is filesystem aware.

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

 

[Gerhard Fiedler]

Folkert Rienstra wrote a lot of gibberish...

You seem to not be able to write three sentences in a row that make sense.
The only thing you seem to be able is to take other's sentences out of
context (the very concept of a context seems to be foreign to you). Doesn't
make much sense to discuss on that level, so I leave that up to Rod...

Gerhard

 

[Gerhard Fiedler]

Which is usually referred to as booting the OS.

Not by the Microsoft documentation of the process. If we're talking about
the meaning of a configuration file for a Microsoft OS, I think it makes
sense to use the terminology Microsoft uses in its documentation of the
process. You use whatever you like...

Gerhard

 

[Gerhard Fiedler]

I believe that the 'dunno' is very relevant in determining whether
you have a point (or not).

And /your/ point is?

 

[Antoine Leca]

En news:[email protected], craigm va escriure:

Does changing the boot order in the BIOS renumber/reorder the disks on
the controller, or just change the order in which they are scanned to
look for a bootable system?

I suspect the latter.

In one experiment I did with a AMI BIOS, neither. It actually did reordered
the various controllers among themselves (w.r.t. the boot process), without
reordering the disks attached to a given controller (I oversimplify the
actual results.)
In another experiment, the latter you described.
So my idea is the correct answer is, it varies.

And the very purpose of "changing the boot order" is to designate a "new"
80h drive to be booted from, so there is a little bit further away than just
change the scan order for the 55AAh signature.


Antoine

 

[Antoine Leca]

En news:[email protected], Rod Speed va escriure:

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

Well, if DOS means "Disk Operating System", NTLDR qualifies as a reduced
one: 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.

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


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


Antoine

 

[Folkert Rienstra]

And /your/ point is?

You want me to spell it out for you?

 

[Antoine Leca]

En news:[email protected], Rod Speed va escriure:

http://www.phoenix.com/NR/rdonlyres/56E38DE2-3E6F-4743-835F-B4A53726ABED/0/specsbbs101.pdf

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.

???
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.
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.
Also there is variation on how the various things are named, which is why I
used the standard term.

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, and
you cannot make any clear and ambiguous conclusion about its internal lists.
Which is the underlying problem.
I very much prefer experimenting a bit with slightly longer lists.

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!


Antoine

 

[Folkert Rienstra]

Folkert Rienstra wrote a lot of gibberish...

You seem to not be able to write three sentences in a row that make sense.

And you have displayed several falsehoods which would explain
why it doesn't make sense to you but you alone (or your handler).

The only thing you seem to be able is to take other's sentences out of
context

Have a good look in the mirror, sockpuppet.

(the very concept of a context seems to be foreign to you). Doesn't
make much sense to discuss on that level, so I leave that up to Rod...

Yes, leave it up to your handler, sockpuppet.

 

[Antoine Leca]

In Gerhard Fiedler va escriure:

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

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

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

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.

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), and furthermore it
seems reasonable to envision this.

(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; being able to load Ntldr (into memory)
is not so restricted.

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

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

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.
Which, ultimately, was Tim's point.


Antoine

 

[Rod Speed]

Rod Speed wrote

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.

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

Not relevant to the story with ntldr.

 

[Rod Speed]

Gerhard Fiedler wrote

Admitting this lemma...

What's a lemma ?

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

Yes it does.

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.

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.

Irrelevant to whether it makes any sense at all for the rdisk()
parameter to be the entry in the hard drive boot order list.

That makes absolutely no sense whatever, if only because
the boot.ini needs to be edited when the order of the hard
drives in the hard drive boot order list is changed. 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 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.

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.

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

Not clear what this is about, thats part of the boot.

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

Well, here you mean "to control" to designate the binary code
which is executing initially. 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.

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.
Which, ultimately, was Tim's point.

No it isnt. Tim claimed that the rdisk() parameter is ALWAYS
the entry in the hard drive boot list. 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 there are damned good reasons for
not doing it like that. And its certainly not what MS intended
because none of the ARC path documention even mentions
the boot order list at all.

 

[Rod Speed]

Rod Speed wrote

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

No it isnt generally seen as an industry standard at all on the
question being discussed. There have been a variety of ways
the boot order list have been implemented in bios, ranging from
no user configurable boot order specifyable at all, thru to just
being able to select from a small set of alternatives, C: or floppy
drive, then adding cdrom to that list and now with most modern
bios allowing the boot order to be specified by drive model ID etc.

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.

There is no mandatory part that applys to anyone except Phoenix.

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

That isnt even the standard term either.

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. In spades when the bios allows you to
specify a boot order with more than just one hard drive in the list.

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

Corse you can with the claim being tested, that its the entry
in the hard drive boot order list that determines the rdisk()
parameter for that particular drive. Completely trivial to test.

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

Thats a lousy way to test the claim that the rdisk()
parameter refers to the entry in the boot order list.

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.

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.

 

[Timothy Daniels]

"Rod Speed"

Timothy Daniels wrote

Your problem. That isnt universally used terminology.


None of that has any relevance what so ever to what
isbeing discussed, the need for a rdisk() number FOR
DRIVES WHICH ARENT IN THE BOOT ORDER LIST.


He clearly said it can.

Read again sock puppet. *I* said it - that an operating system can
be loaded from a logical drive within an Extended partition.. That isn't
generally known, even by sock puppets.

*TimDaniels*

 

[Timothy Daniels]

Timothy Daniels wrote

And when that particular abortion of a bios makes a
complete hash of the rdisk() param, it doesnt really
matter what it does with the partition() param, what
matters is what the MS documentation says it should mean.

Please post what the "MS documentation says it should mean".

*TimDaniels*