Boot.ini question

[Gerhard Fiedler]

Just you with a problem with basic english.

Now this together with the following is almost funny...

Its obvious what 'it varys' means.

ge

 

[Antoine Leca]

Hi Rod.

I believe you got something wrong, but I cannot find where exactly is the
problem. I guess you are missing a piece of the puzzle. Please take a moment
to check your points about the PC boot process (going through INT 19h, MBR,
active partition, boot record code, then "booting the OS".) OTOH, if you are
trying to make a point based purely on published MS' position, please ignore
my post.


In Rod Speed va escriure:

That few if any current bios can boot a logical drive in
an extended dos partition.

I'll not put "I disagree" since you do not care.
I'll not put "Wrong" (or worse) as you'll, since that is not my conception
of discussion.
Yet I feel this is incorrect.

If you want to do that, you need to use ntldr or another
loader to do that because the bios cannot do that.

It is well known it can be done with plain DOS (with customized bootcode in
the MBR, as I described), which is NOT using a sophisticated boot loader.

Why not when the bios can boot any physical drive it can see.

Because BIOS sees "physical drives", and it sees them as continuum (LBA or
CHS organized) of sectors, without disruption.
It does not know about partitions, slices or anything finely grained (and
much less extended or logical partitions, or filesystems, obviously).

EFI, when considered as BIOS' successor in interest, will. But practice
shows the need/interest for it is low.

Thats just the way ntldr does it. It doesnt have to be done
that way.

That is factually correct (for example, the original code for booting
386*BSD 0.0 did it another way).
Yet it is _also_ the way it is done by every MS operating system to date on
the PC architecture (well, I have doubt about Xenix System III, though.) And
the vast majority of the current OSes on PC.

ntldr allowed booting of physical drives which
could not be specified in the bios as what the user wanted
to boot from too, other than the C: drive, with older bios
where you couldnt specify other than the C: to boot from.

Hmmm. I believe I understand where you are heading. More or less, you see
the Ntldr solution as superior to the MBR+bootrecord way of booting an OS
(while still using these piece). Yes, it makes sense to view it that way.

Yet, it is an architectural (higher level) view of the picture. Below the
scene, there is still a MBR code and so on, and you really can achieve the
same effect using other "tricks", *without* making any assumption about the
BIOS support.

There is no technical reason why the bios could
not allow the user to specify a logical drive in an
extended dos partition to boot from, it just isnt
what is possible with most if any bios.

???
I do not know of ANY bios that allow the user to specify which _partition()_
one wants to boot NT from. As we were speaking about, BIOS stands at the
_rdisk()_ level, that's one level higher.

MBR partition scheme is NOT firmware dependant (only the 55AAh signature
is), it is a purely software concept (introduced with DOS 2 / IBM XT), and
it is a damned good/clever idea: without it, we could only have ONE
operating system on a given box (or perhaps one per bootable drive, assuming
BIOS support to select among the available).

Irrelevant to what the whole point of the ntldr system was.

Yes good to agree with you on this one.

In fact the multi structure can be used for some SCSI
drives, as well as ATA drives.

This requires so-called "BIOS support" to be provided by the SCSI hardware
(adapter usually).

The multi and scsi protocols arent identical, for a reason.

Quite true ;-).

Multi() uses BIOS calls, using protected-to-real mode switches to call Int
13h, something that is impossible to do at a later stage (when the kernel
has been started).

Scsi() OTOH uses (normally) the same driver as will be used in normal
operation. This in turn requires Ntldr to fake the kernel, at least the
storage IRP stack and the most basic resources management, including memory
allocation; plus starting and stoping the driver.

That sentence makes no sense.

The ARC paths are of the form xxx(X)disk(Y)rdisk(Z)partition(N). With
multi(X), no meaning is given to either X or Y, they are always 0. multi(0)
has to be kept for coherency reasons, but why using disk(0)?
My answer, because ARC (the preexisting MIPS standard) specified the general
syntax.

Neither does that.

I mean, Cutler's team chose to use ARC paths at Ntldr/Boot.ini level, when
they could perfectly have used something else, perhaps the same strings used
in the NT kernel (HarddiskZ\PartitionN), it would have been much less
confusion for anybody.

And there are downsides with that approach,
most obviously they arent as obvious to the user.

Very good point, and very probably the reason behind the text published by
MS.

However, the other formulations also have downside. For example, "the
ordinal number of the drive" may appear faulty if the drive is not properly
declared in the BIOS setup.

Because it isnt.

Funny. The actual code DOES that computation (of course one may worry which
other it could ever do.)

"It isn't" because MS does not say it is: that's what I called "grey", or
the usual "undocumented": it is this way, but since MS did not document it,
they are allowed to change this in the future, without backfire about
possible incompatibilities.


Antoine

 

[Rod Speed]

Rod Speed wrote

Now this together with the following is almost funny...

Pathetic, really.

 

[Rod Speed]

Rod Speed wrote

I believe you got something wrong, but I
cannot find where exactly is the problem.

Then you dont have any basis for your belief.

I guess you are missing a piece of the puzzle.

Or you are wrong. You certainly about
whether ntldr is a 'reduced' OS or not.

Please take a moment to check your points about the
PC boot process (going through INT 19h, MBR, active
partition, boot record code, then "booting the OS".)

No thanks, already did that in response to ****nert's response.

OTOH, if you are trying to make a point
based purely on published MS' position,

No I'm not. I havent seen any evidence that there is any problem
with what MS has published except that the wording is a bit too
vague in spots, but thats typical of MS. I've seen no evidence that
the rdisk() parameter is other than the ordinal of the drive on the
controller in the sense of the master/slave relationship of the drives
on a particular controller except with Timmy's completely ****ed bios.

please ignore my post.

I'll not put "I disagree" since you do not care.
I'll not put "Wrong" (or worse) as you'll, since
that is not my conception of discussion.
Yet I feel this is incorrect.

Then nominate a bios that can do that without
modified MBR boot code or some form of loader.

Its no news that it can be done with
a loader, ntldr manages that fine.

It is well known it can be done with plain DOS (with
customized bootcode in the MBR, as I described),

That is a customised MBR boot code, NOT the bios.

which is NOT using a sophisticated boot loader.

Never said that doing THAT requires a sophisticated loader.

Booting a member of the NT/2K/XP family does tho.

Because BIOS sees "physical drives", and it sees them as
continuum (LBA or CHS organized) of sectors, without disruption.

Thats just the way its currently done. In the past it could only
boot from the first physical drive, or the floppy, and later the
cdrom drive was added to the list of possibilitys.

It does not know about partitions, slices or anything
finely grained (and much less extended or logical
partitions, or filesystems, obviously).

There's no technical reason why the bios cant understand
partitions and allow the user to select a partition to boot.

And the big advantage of giving the bios that capability is
that you can boot any partition on any drive if a drive dies etc.

EFI, when considered as BIOS' successor in interest,
will. But practice shows the need/interest for it is low.

Irrelevant to whether its possible for a bios to do that.

That is factually correct (for example, the original
code for booting 386*BSD 0.0 did it another way).
Yet it is _also_ the way it is done by every MS operating system to
date on the PC architecture (well, I have doubt about Xenix System
III, though.) And the vast majority of the current OSes on PC.

Irrelevant to what can be done.

Hmmm. I believe I understand where you are heading. More or
less, you see the Ntldr solution as superior to the MBR+bootrecord
way of booting an OS (while still using these piece).

I do however also see it as a rather crude boot manager which
has a number of significant deficiencys, particularly having to
manually edit the boot.ini or use one of the utes that MS provides
to modify the boot.ini, none of which are that elegant to use.

And one obvious downside with the ntldr approach is that
it doesnt handle drive failure that well either. Booting by
the bios can be much more robust on physical drive failure.

Yes, it makes sense to view it that way.

Yet, it is an architectural (higher level) view of the picture.

No it isnt.

Below the scene, there is still a MBR code and so on, and
you really can achieve the same effect using other "tricks",
*without* making any assumption about the BIOS support.

You dont have to use ntldr as the primary
boot manager if you dont like it.

???
I do not know of ANY bios that allow the user to
specify which _partition()_ one wants to boot NT from.

Thats why I said that there is no TECHNICAL reason why it cant be done.

As we were speaking about, BIOS stands at the _rdisk()_ level,

No it doesnt. All the bios can do is boot at the level of the
physical drive and the active primary partition on that drive.

that's one level higher.

No it isnt.

MBR partition scheme is NOT firmware dependant (only the 55AAh
signature is), it is a purely software concept (introduced with DOS 2
/ IBM XT), and it is a damned good/clever idea: without it, we could
only have ONE operating system on a given box (or perhaps one per
bootable drive, assuming BIOS support to select among the available).

But is limited in the sense that it cant boot from a logical drive
in an extended dos partition without new code in the MBR etc.

<Big snip; now we were about Boot.ini>

This requires so-called "BIOS support" to be
provided by the SCSI hardware (adapter usually).
Sure.

Quite true ;-).

Multi() uses BIOS calls, using protected-to-real mode
switches to call Int 13h, something that is impossible to
do at a later stage (when the kernel has been started).

Scsi() OTOH uses (normally) the same driver as will be used in
normal operation. This in turn requires Ntldr to fake the kernel, at
least
the storage IRP stack and the most basic resources management,
including memory allocation; plus starting and stoping the driver.

The ARC paths are of the form xxx(X)disk(Y)rdisk(Z)partition(N). With
multi(X), no meaning is given to either X or Y, they are always 0.
multi(0) has to be kept for coherency reasons, but why using disk(0)?
My answer, because ARC (the preexisting MIPS standard) specified the
general syntax.

I mean, Cutler's team chose to use ARC paths at Ntldr/Boot.ini level,
when they could perfectly have used something else, perhaps the
same strings used in the NT kernel (HarddiskZ\PartitionN), it would
have been much less confusion for anybody.
Sure.

Very good point, and very probably the
reason behind the text published by MS.

However, the other formulations also have downside. For
example, "the ordinal number of the drive" may appear
faulty if the drive is not properly declared in the BIOS setup.
Sure.

Funny. The actual code DOES that computation
(of course one may worry which other it could ever do.)

"It isn't" because MS does not say it is: that's what I called
"grey", or the usual "undocumented": it is this way, but since
MS did not document it, they are allowed to change this in
the future, without backfire about possible incompatibilities.

I doubt they did it for that reason.

 

[craigm]

Thats just the way its currently done. In the past it could only
boot from the first physical drive, or the floppy, and later the
cdrom drive was added to the list of possibilitys.




There's no technical reason why the bios cant understand
partitions and allow the user to select a partition to boot.

And the big advantage of giving the bios that capability is
that you can boot any partition on any drive if a drive dies etc.

Architecturally, what you propose would be a problem. For a BIOS to be
able to boot from any partition would require the BIOS to understand
file systems. Not just any file system, but every file system that one
may use, now and in the future, for the feature to work universally.

The BIOS should provide services to the OS and start the boot process.
Knowing a files system belongs in the loader and OS.

 

[Rod Speed]

Rod Speed wrote

Architecturally, what you propose would be a problem.

No it wouldnt. The bios would just be doing what you agree
can be done by modified code in the MBR and a loader.
No reason why that cant be done by the bios instead.

Note that I am NOT talking about the full complexity of loading a
member of the NT/2K/XP family by the bios, I am JUST talking about
allowing the user to specify a logical drive within an extended dos
partition as what to boot from in the bios instead of in a boot manager.

For a BIOS to be able to boot from any partition would require the BIOS
to understand file systems.

ALL that is required is what is already
done in modified MBR code and loaders.

Not just any file system, but every file system that one may use, now and
in the future, for the feature to work universally.

It doesnt to work universally, just do what is currently done by a loader.

The BIOS should provide services to the OS and start the boot process.
Knowing a files system belongs in the loader and OS.

Doesnt have to be when doing something as basic as booting a partition.

 

[Folkert Rienstra]

Then you dont have any basis for your belief.

Or 'maybe' you are just all over the place and can't be caught.

I guess you are missing a piece of the puzzle. [SNIP]

Please take a moment to check your points about the
PC boot process (going through INT 19h, MBR, active
partition, boot record code, then "booting the OS".)

No thanks, already did that in response to ****nert's response.

Mindless repetition was never a problem for you so it more than
likely wasn't worth repeating.

OTOH, if you are trying to make a point
based purely on published MS' position,

[SNIP]
... I've seen no evidence that the rdisk() parameter is other than the
ordinal of the drive on the controller in the sense of the master/slave
relationship of the drives on a particular controller except with Timmy's
completely ****ed bios.

Any bios that allows just the bootdrive to be changed (interchange
the device that is ordinarily device 81h, 82h or 83h with device 80h)
is '****ed' in that regard which is every current bios.

Either NTLDR checks the ordinal that it translated the rdisk()
parameter into against the Master/Slave info supplied by the
BIOS s.a. Int 13/AH=48h for that ordinal and it works correctly
or it doesn't check it and it ****s up accordingly.

That is not any BIOS's fault. That's MS's fault.

Fat chance.

I'll not put "I disagree" since you do not care.
I'll not put "Wrong" (or worse) as you'll, since
that is not my conception of discussion.
Yet I feel this is incorrect. [SNIP]

If you want to do that, you need to use ntldr or another
loader to do that because the bios cannot do that.

It is well known it can be done with plain DOS (with
customized bootcode in the MBR, as I described), [SNIP]

which is NOT using a sophisticated boot loader. [SNIP]

almost no current bios allows those to be booted by the bios.
Because that is not BIOS' job,
Why not when the bios can boot any physical drive it can see.

Because BIOS sees "physical drives", and it sees them as
continuum (LBA or CHS organized) of sectors, without disruption.

Thats just the way its currently done. In the past it could only
boot from the first physical drive, or the floppy, and later the
cdrom drive was added to the list of possibilitys.

It does not know about partitions, slices or anything
finely grained (and much less extended or logical
partitions, or filesystems, obviously). [SNIP]

EFI, when considered as BIOS' successor in interest,
will. But practice shows the need/interest for it is low. [SNIP]

rather the one for the code inside the boot records
(MBR and the one for the active partition);
Thats just the way ntldr does it. It doesnt have to be done that way.

That is factually correct (for example, the original
code for booting 386*BSD 0.0 did it another way).
Yet it is _also_ the way it is done by every MS operating system to
date on the PC architecture (well, I have doubt about Xenix System
III, though.) And the vast majority of the current OSes on PC. [SNIP]

ntldr allowed booting of physical drives which could not
be specified in the bios as what the user wanted to boot
from too, other than the C: drive, with older bios where
you couldnt specify other than the C: to boot from.

Hmmm. I believe I understand where you are heading. More or
less, you see the Ntldr solution as superior to the MBR+bootrecord
way of booting an OS (while still using these piece). [SNIP]

Yes, it makes sense to view it that way.

Yet, it is an architectural (higher level) view of the picture. [SNIP]

Below the scene, there is still a MBR code and so on, and
you really can achieve the same effect using other "tricks",
*without* making any assumption about the BIOS support.

You dont have to use ntldr as the primary
boot manager if you dont like it.

As if there is any other way to get NT in the air.

???
I do not know of ANY bios that allow the user to
specify which _partition()_ one wants to boot NT from. [SNIP]

As we were speaking about, BIOS stands at the _rdisk()_ level,

No it doesnt. All the bios can do is boot at the level of the
physical drive and the active primary partition on that drive.

Nonsense. Still as clueless as ever.

that's one level higher. [SNIP]

MBR partition scheme is NOT firmware dependant (only the 55AAh
signature is), it is a purely software concept (introduced with DOS 2
/ IBM XT), and it is a damned good/clever idea:
without it, we could only have ONE operating system on a given box

Nonsense. It's fine to have several OSes on a single partition.

And that too.

[SNIP]

<Big snip; now we were about Boot.ini>

This requires so-called "BIOS support" to be
provided by the SCSI hardware (adapter usually). [SNIP]

The multi and scsi protocols arent identical, for a reason.

Quite true ;-).

Multi() uses BIOS calls, using protected-to-real mode
switches to call Int 13h, something that is impossible to
do at a later stage (when the kernel has been started).

Scsi() OTOH uses (normally) the same driver as will be used in
normal operation. This in turn requires Ntldr to fake the kernel, at
least
the storage IRP stack and the most basic resources management,
including memory allocation; plus starting and stoping the driver.

The ARC paths are of the form xxx(X)disk(Y)rdisk(Z)partition(N).
With multi(X), no meaning is given to either X or Y, they are always 0.
multi(0) has to be kept for coherency reasons, but why using disk(0)?
My answer, because ARC (the preexisting MIPS standard) specified the
general syntax.

Using ARC paths including for i386 also was.

[SNIP]

I mean, Cutler's team chose to use ARC paths at Ntldr/Boot.ini level,
when they could perfectly have used something else, perhaps the
same strings used in the NT kernel (HarddiskZ\PartitionN), it would
have been much less confusion for anybody. [SNIP]

N could also have been defined clearly as the BIOS drive number,
And there are downsides with that approach,
most obviously they arent as obvious to the user.

Very good point, and very probably the
reason behind the text published by MS.

However, the other formulations also have downside. For
example, "the ordinal number of the drive" may appear
faulty if the drive is not properly declared in the BIOS setup. [SNIP]

<snip>
Nothing grey about the MS statement that the rdisk()
param is the ordinal of the drive on the controller.
I did not find a clear statement from them that the
rdisk() parameter is the BIOS drive number - 80h.

[SNIP]

Funny. The actual code DOES that computation
(of course one may worry which other it could ever do.)

"It isn't" because MS does not say it is: that's what I called
"grey", or the usual "undocumented": it is this way, but since
MS did not document it, they are allowed to change this in
the future, without backfire about possible incompatibilities.

[SNIP]

 

[Rod Speed]

Or 'maybe' you are just all over the place and can't be caught.

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

No wonder you end up having your mouth frothing rages.

Mindless repetition was never a problem for you
so it more than likely wasn't worth repeating.

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

No wonder you end up having your mouth frothing rages.

Any bios that allows just the bootdrive to be changed (interchange
the device that is ordinarily device 81h, 82h or 83h with device 80h)
is '****ed' in that regard which is every current bios.

Not a ****ing clue, as always. Not a shred of evidence
that ANY bios uses the ordinal of the drive in the hard drive boot
order list as the rdisk() param with the exception of Timmy's
completely ****ed bios, if he isnt actually lying about it.

Either NTLDR checks the ordinal that it translated the rdisk()
parameter into against the Master/Slave info supplied by the
BIOS s.a. Int 13/AH=48h for that ordinal and it works
correctly or it doesn't check it and it ****s up accordingly.

That is not any BIOS's fault. That's MS's fault.

See above.

Fat chance.

I mostly ignore you pathetic excuses for trolls.

What is true?
That few if any current bios can boot a
logical drive in an extended dos partition.
I'll not put "I disagree" since you do not care.
I'll not put "Wrong" (or worse) as you'll, since
that is not my conception of discussion.
Yet I feel this is incorrect. [SNIP]

If you want to do that, you need to use ntldr or another
loader to do that because the bios cannot do that.

It is well known it can be done with plain DOS (with
customized bootcode in the MBR, as I described), [SNIP]

which is NOT using a sophisticated boot loader. [SNIP]

almost no current bios allows those to be booted by the bios.

Because that is not BIOS' job,

Why not when the bios can boot any physical drive it can see.

Because BIOS sees "physical drives", and it sees them as
continuum (LBA or CHS organized) of sectors, without disruption.

Thats just the way its currently done. In the past it could only
boot from the first physical drive, or the floppy, and later the
cdrom drive was added to the list of possibilitys.

It does not know about partitions, slices or anything
finely grained (and much less extended or logical
partitions, or filesystems, obviously). [SNIP]

EFI, when considered as BIOS' successor in interest,
will. But practice shows the need/interest for it is low. [SNIP]

rather the one for the code inside the boot records
(MBR and the one for the active partition);

Thats just the way ntldr does it. It doesnt have to be done that
way.

That is factually correct (for example, the original
code for booting 386*BSD 0.0 did it another way).
Yet it is _also_ the way it is done by every MS operating system to
date on the PC architecture (well, I have doubt about Xenix System
III, though.) And the vast majority of the current OSes on PC. [SNIP]

ntldr allowed booting of physical drives which could not
be specified in the bios as what the user wanted to boot
from too, other than the C: drive, with older bios where
you couldnt specify other than the C: to boot from.

Hmmm. I believe I understand where you are heading. More or
less, you see the Ntldr solution as superior to the MBR+bootrecord
way of booting an OS (while still using these piece). [SNIP]

Yes, it makes sense to view it that way.

Yet, it is an architectural (higher level) view of the picture. [SNIP]

Below the scene, there is still a MBR code and so on, and
you really can achieve the same effect using other "tricks",
*without* making any assumption about the BIOS support.

You dont have to use ntldr as the primary
boot manager if you dont like it.

As if there is any other way to get NT in the air.

That isnt necessarily the PRIMARY boot manager, ****wit.

Even someone as stupid as you should be able to work
out that its perfectly possible to use a different PRIMARY
boot manager and still boot a member of the NT/2K/XP
family, if for example you dont like some detail of how
ntldr does the boot managing.

There is no technical reason why the bios could
not allow the user to specify a logical drive in an
extended dos partition to boot from, it just isnt
what is possible with most if any bios.

???
I do not know of ANY bios that allow the user to
specify which _partition()_ one wants to boot NT from. [SNIP]

As we were speaking about, BIOS stands at the _rdisk()_ level,

No it doesnt. All the bios can do is boot at the level of the
physical drive and the active primary partition on that drive.

Nonsense. Still as clueless as ever.

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

No wonder you end up having your mouth frothing rages.

that's one level higher. [SNIP]

MBR partition scheme is NOT firmware dependant (only the 55AAh
signature is), it is a purely software concept (introduced with DOS
2 / IBM XT), and it is a damned good/clever idea:
without it, we could only have ONE operating system on a given box

Nonsense. It's fine to have several OSes on a single partition.
And that too.

[SNIP]

<Big snip; now we were about Boot.ini>

In fact the multi structure can be used for
some SCSI drives, as well as ATA drives.

This requires so-called "BIOS support" to be
provided by the SCSI hardware (adapter usually). [SNIP]

The multi and scsi protocols arent identical, for a reason.

Quite true ;-).

Multi() uses BIOS calls, using protected-to-real mode
switches to call Int 13h, something that is impossible to
do at a later stage (when the kernel has been started).

Scsi() OTOH uses (normally) the same driver as will be used in
normal operation. This in turn requires Ntldr to fake the kernel, at
least
the storage IRP stack and the most basic resources management,
including memory allocation; plus starting and stoping the driver.

The fact there are two indices is a
given input, not a decision of the team.

That sentence makes no sense.

The ARC paths are of the form xxx(X)disk(Y)rdisk(Z)partition(N).
With multi(X), no meaning is given to either X or Y, they are
always 0. multi(0) has to be kept for coherency reasons, but why
using disk(0)? My answer, because ARC (the preexisting MIPS
standard) specified the general syntax.

Using ARC paths including for i386 also was. [SNIP]

I mean, Cutler's team chose to use ARC paths at Ntldr/Boot.ini
level, when they could perfectly have used something else, perhaps
the
same strings used in the NT kernel (HarddiskZ\PartitionN), it would
have been much less confusion for anybody. [SNIP]

N could also have been defined clearly as the BIOS drive number,

And there are downsides with that approach,
most obviously they arent as obvious to the user.

Very good point, and very probably the
reason behind the text published by MS.

However, the other formulations also have downside. For
example, "the ordinal number of the drive" may appear
faulty if the drive is not properly declared in the BIOS setup. [SNIP]

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

I did not find a clear statement from them that the
rdisk() parameter is the BIOS drive number - 80h. [SNIP]

Funny. The actual code DOES that computation
(of course one may worry which other it could ever do.)

"It isn't" because MS does not say it is: that's what I called
"grey", or the usual "undocumented": it is this way, but since
MS did not document it, they are allowed to change this in
the future, without backfire about possible incompatibilities.

[SNIP]

 

[Gerhard Fiedler]

Pathetic, really.

I didn't mean to say that, but if you say so