Re: Boot.ini question

Antoine Leca <root@xxxxxxxxxxxxxxxxx> wrote

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 Fucknert'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 fucked bios.

please ignore my post.

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.

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.

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

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.

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

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.

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.

Irrelevant to what can be done.

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

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.

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.

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>

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

Sure.

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.

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.

Sure.

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.

Sure.

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

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.

I doubt they did it for that reason.



.

Quantcast