Boot.ini question

[Rod Speed]

Rod Speed wrote

Ntldr enumerates memory (and passes the memory map to the
kernel), enumerates PnP devices (that's NtDetect.com main job,
because it has to be a 16-bit mode program), enumerates disks,
loads the System registry, provides console emulation including
kanji, provides serial support etc. for debugging. Etc.

Thats not MANAGING those resources.

And not everything that manages resources is a 'reduced OS'
anyway, plenty of executables do that. enumerating in spades.

ALL it does is work out what should be booted [...]

Well, loading NT Executive + its drivers is a somewhat complex task.

Plenty of executables do complex tasks.
Doesnt make them a 'reduced' OS.

Furthermore, Ntldr's mission is to make the ball rolling, so it
includes providing numerous informations at determined places.

That doesnt make it a 'reduced' OS either, just a boot
manager and part of a relatively complex boot process.

One could relatively easily write a
loader for DOS; with documentation,

Yes, and that is now file system aware with what
is done with MSDOS. That just makes it a file
system aware loader, NOT a 'reduced' OS.

it is yet not very easy to write one for Linux,

All that shows is that the Linux boot is more complex than the
DOS boot. The NT/2K/XP boot in spades and the complexity
of the NT/2K/XP is made worse by the fact that its not fully
documented by MS. Doesnt make the loader a 'reduced' OS
tho. Just makes it a more sophisticated loader, which is also
file system aware because it needs to be file system aware.

Even the MSDOS loader is file system aware now.

which is why Lilo was kept that much time despite
requiring an absolutely awkward making process.

It aint a 'reduced' OS either.

I believe nobody except MS and the wizards could
write something like Ntldr (I mean the loading part);

Yes, it has never been fully documented by MS so that would
be a complex task, to get the same result that ntldr gets.
Doesnt say anything useful about whether its a 'reduced' OS tho.

The NTFS file system is similarly poorly documented.
Irrelevant to whether ntldr is a 'reduced' OS tho.

as far as I know, ReactOS' FreeLoader is not able
to launch MS Windows, it defers on Ntldr to do that.

Yes, its the obvious way to do things, just let ntldr do it.

Irrelevant to whether ntldr is a 'reduced' OS tho.

Some of the partition managers dont bother to implement
FAT32 to NTFS file system conversion either, they just
get what comes with NT/2K/XP to do it for them.

And whether ntldr is a 'reduced' OS in spades.

I disagree.

Your problem.

Syslinux/Isolinux loads itself from a FAT/ISO9660 volume, then
reads it configuration file, then (usually, depending of circumstances)
loads the kernel into memory, then unpacks the ramdisk, and finally
starts the kernel. Ntldr loads itself from a FAT16/ISO9660 volume
(the boot record does for FAT32/NTFS), then reads its configuration
files, then inspects the configuration, then (usually, depending of
circumstances) loads the kernel and the boot-time drivers into
memory, and finally starts the kernel.

All that shows is that its a relatively sophisticated loader
that does quite a bit of what ntldr does. Says nothing
useful what so ever about whether either is a 'reduced' OS.

Neither is, they are just relatively sophisticated loaders.

Major differences are:
- NTFS support
- the registry
- Ntdetect
- the hability to use independant sidemodules (also with BootMgr)
- the HAL
- the ramdisk vs the preloaded device drivers
I stand on my point these differences are relatively
unimportant compared to the commonalities.

All completely irrelevant to whether either are 'reduced' OSs.

They arent, they are just relatively
sophisticated loaders for different OSs.

 

[Rod Speed]

Rod Speed wrote

Remark: As I said long ago, I do not agree with that claim in general,

Your problem.

just in particular, not common, cases.

That is just plain wrong.

Well, results are quite funny.

Computer A, MSI-7032 (2004), AMI BIOS, K8M800 chipset
(from memory, I do not have the computer handy.) The IDE
disks "below the first" do not show up in any list. End of this test.

That does however show that Timmy's claim that the rdisk()
param is the ordinal in the hard drive boot order list is just
plain wrong, most obviously with a bios that doesnt even
have a hard drive boot order list at all. And as I pointed out
repeatedly, that was the case at the time that the ntldr system
was introduced, hardly any if any bios had a hard drive boot
order list. Most at most had a boot order list that just
allowed for a single hard drive, just the C: drive.

Computer(s) B, several Dell (2001-2005, Latitude 8100/4300/4600,
Optiflex 115/150/260/270), so derivatives of Phoenix. The only list
where the disks "below the first" show up is the "Boot menu"
(obtained with F10), which allows to select a different disk to be
the first one for that boot only (by renumbering the disks, giving it
the 80h ribbon). No way I can find to change the order of the disks
"below the first."

I have also a PowerEdge830, but it only has one IDE channel,
and lacks the F10 feature (or I missed it); at any rate I did not
spot any list where the IDE disks can be reordered.

Computer T, Dell XPS [Tim]. There _seems_ to be a
"Hard Disk Boot order" list, which is fully editable, and
the positions there determine the BIOS ordinal numbers.

Does it determine what the rdisk() param refers to tho.

I do not have currently a (recent) Award computer with
several disks handy, sorry; nor did I test the case where
the 80h disk does not have the valid (active) MBR yet forces
a Int18 to boot the 81h disk (this one could be interesting.)

In fact, I would be interested by what you folks understand
as "the boot order list", _including_ all bootable IDE disks ;-).
OK, I already got Tim's no need to reiterate.

Also, I notice some BIOSes list HDD-1 to HDD-3 along with the
traditionnal A:, C:, CD-ROM, PXE etc. in the "IPL table"; (I should
resurrect some oldtimers since I seem to remember seeing this once);
but this is NOT universal behaviour as we can see from the above...
Perhaps reserved to the high-end boards? (I said that because I
understand I conducted all my tests with value-for-money computers.)

By the way, on computer A, the SATA disks are enumerated as several
BCV (clearly, main BIOS dated 2004 does not know about SATA), so I
can reorder them; as you select any of them, _all_ the SATA disks get
the lowest numbers; something similar occurs with USB, although it is
quite of brocken (there is only one BCV, even when it detects several
devices).

That is, not only the relative position for the IDE
disks is not editable, but the various lists for the
varying controllers behave as monolithic entities.

What matters is what the rdisk() parameter for those drives
is determined by. I bet its the physical drive on controller ordinal,
not varying with what is done with the boot order in the bios.

Again , the best position is, it varies.

So Timmy's original claim that it doesnt is
just plain wrong, like we all keep telling him.

 

[Rod Speed]

Rod Speed wrote

Problably yes. Like the most part of this thread...

Nope, the whole point of this thread is what the
rdisk() param means, and Timmy's original claim
that its the ordinal in the 'hard drive boot order'
list, even with bios which dont even have one.

I disagree.

Your problem. The whole point of boot.ini is that it allows
NT/2K/XP to be booted from drives and partitions that the
bios cannot boot and to provide a decent menu at boot time
so the user can select what he wants to boot at boot time.

Having the rdisk() param the ordinal in the hard drive
boot order list is a complete abortion for two reasons.

One problem is that if the order in the hard drive boot order list
is changed, the boot.ini needs to be edited if it involves those
drives which have been moved in the list. That is not required
if the rdisk() param is the drive on the controller instead.

AND there isnt any point in having the rdisk()
param as the ordinal in the hard drive boot order
list. That achieves absolutely nothing useful at all.

AND the other big downside with having the rdisk() param
as the ordinal in the hard drive boot order list is that you
cant boot from a drive which isnt actually in the hard drive
boot order list. With the MS approach you can.

There isnt even any evidence that Dell or whoever perpetrated
that abortion even intended it, its much more likely that
someone ****ed up completely and it was unintended.

Now *I* ask what is the relevance of this remark
with the whole point of the rdisk() parameter.

The whole point of the boot.ini was to allow booting of what the bios
could not boot. That is STILL true of a logical drive in an extended
dos partition, almost no current bios allows those to be booted by
the bios. I'm not aware of any that allows that.

For what it is worth, I think it is possible to succesfully
boot Ntldr in a logical partition, using bootstrap code
in EPBR and changing the HiddenSectors parameters.

I wasnt talking about that, I was talking
about where the OS comes from, not ntldr.

Sure, but again I do not see the point w.r.t. rdisk().

See above.

The very purpose of Ntldr+Boot.ini, like any
boot loader, is to enhance flexibility, yes.

And to allow booting that the bios cannot do, like
booting an install of the NT/2K/XP family from a
logical drive within an extended dos partition.

I disagree:

Your problem.

I routinely boot an array (on a different controller)
using rdisk(N), with N being beyond the number of
drives on the first controller (where Boot.ini stands).

And I perfectly know that when I add or remove a
disk in the first controller (usually because it is down),
I have to adjust the rdisk() parameter accordingly.

That isnt using the ordinal in the hard drive boot order list.

Sorry, I cannot make a sense of this.
Particularly, on a AMI bios I am using regularly, there
is no such thing as a "hard drive boot order list";

That clearly isnt the case when the hard drive boot order
list is the ordinal which is the rdisk() param, by definition.

as I am saying since the first post after Tim's...

As I also said a number of times in this thread. If there
aint even a hard drive boot order list, the rdisk() param
cant possibly be the ordinal in the hard drive boot order
list because there isnt one in some bios.

I know this is not required. In fact, it might
have worked back in 1990 or even earlier...

However, you have to assume this unless you want to
play dangerously: far too much code out there assume
blindly _or_ studbornly the booting harddisk is 80h.

Irrelevant to what ntldr and what loads it does.

Did not read the word "always" in his post: it just proposed a way
to think the rdisk() parameter as a "relative" position in this list.

The word 'think' was never used.

And before you elaborate: if you find a quote of him
saying "always", I would claim he was wrong on this one.

Thats what he said without using that particular word.

Thats the way english works.

As I said since the beginning.

Nothing for me to comment here.

Yes, I agree, you can find good reasons to
keep the order as stable, that's a good point.

And no good reason at all to use the ordinal in the hard drive
boot order list for the rdisk() param. Not even a poor reason.

Here I disagree, for two reasons.

One is that the ARC path rdisk(N) mechanism was designed around
1990 to make a gateway between the RISC world (where NT originally
was born) and the Intel/IBM/Compaq "i386" architecture; that's long
before BBS. I very much doubt if MS had the choice, they will still
use it in 2006 (NT on MIPS anyone?) As such, it is much of a
legacy of the history, like for example the Int13 interface itself.

Thats just plain wrong with the most basic functionality of boot.ini,
to provide a way to specify where the various OSs etc are on the
hard drives. That has to do be done somehow with any boot manager.

The second is that MS had become the "official" source for the
ARC path mechanism, failling any alternative. Whatever they
publish as documentation will instantly becomes the Standard.
So it is normal practice for themselves to keep gray areas
("undocumented", as Andrew Schulman &alii tagged it)
in order to allow paths for future expansions, as long
as doing so does not hamper interoperability.

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

 

[Folkert Rienstra]

Rod Speed wrote

Ntldr enumerates memory (and passes the memory map to the
kernel), enumerates PnP devices (that's NtDetect.com main job,
because it has to be a 16-bit mode program), enumerates disks,
loads the System registry, provides console emulation including
kanji, provides serial support etc. for debugging. Etc. [snip]

ALL it does is work out what should be booted [...]

Well, loading NT Executive + its drivers is a somewhat complex task. [snip]

Furthermore, Ntldr's mission is to make the ball rolling, so it
includes providing numerous informations at determined places.

That doesnt make it a 'reduced' OS either, just a boot manager

and part of a relatively complex boot process.

Gee Roddles, what a quick learner you are.
Just a mo ago you said it was only a simple boot manager and nothing more.

One could relatively easily write a loader for DOS; with documentation, [snip]

it is yet not very easy to write one for Linux,

All that shows is that the Linux boot is more complex than the
DOS boot. The NT/2K/XP boot in spades and the complexity
of the NT/2K/XP is made worse by the fact that its not fully
documented by MS.

Doesnt make the loader a 'reduced' OS tho.

Just makes it a more sophisticated loader, which is also
file system aware because it needs to be file system aware.

Could be a perfect description for DOS.

[snip]

which is why Lilo was kept that much time despite
requiring an absolutely awkward making process. [snip]

I believe nobody except MS and the wizards could
write something like Ntldr (I mean the loading part);

Yes, it has never been fully documented by MS so that would
be a complex task, to get the same result that ntldr gets.

Which just a post away was only a simple bootmanager.

Doesnt say anything useful about whether its a 'reduced' OS tho.
[snip]

as far as I know, ReactOS' FreeLoader is not able
to launch MS Windows, it defers on Ntldr to do that. [snip]

Look at SysLinux, its open source equivalent, to get my idea.
syslinux has nothing to do with what ntldr does.

[snip]

I disagree.

Your problem.

Syslinux/Isolinux loads itself from a FAT/ISO9660 volume, then
reads it configuration file, then (usually, depending of circumstances)
loads the kernel into memory, then unpacks the ramdisk, and finally
starts the kernel. Ntldr loads itself from a FAT16/ISO9660 volume
(the boot record does for FAT32/NTFS), then reads its configuration
files, then inspects the configuration, then (usually, depending of
circumstances) loads the kernel and the boot-time drivers into
memory, and finally starts the kernel.

All that shows is that its a relatively sophisticated loader
that does quite a bit of what ntldr does.

Which just a mo ago was only a simple bootmanager.

Says nothing useful what so ever about whether either is a 'reduced' OS.

Neither is, they are just relatively sophisticated loaders.

Thanks for debunking your previous
"syslinux has nothing to do with what ntldr does"
so elaborately for us.

All completely irrelevant to whether either are 'reduced' OSs.

They arent, they are just relatively sophisticated loaders for different OSs.

And once again my thanks for debunkig Fiddlers assertion that
logical disks only have meaning when an OS is loaded so eloquently.

 

[Folkert Rienstra]

And I'm with you 100% on this

Then the both of you seem to be disagreeing with what Microsoft and Roddles say.

 

[Folkert Rienstra]

Here's a simpler version, step by step:

1- You claimed that the rdisk number is related to the boot order.

2- One consequence of this is that if a controller can't boot from a disk,
I can't use your rule to determine the rdisk number.

3- I can use boot.ini entries to start Windows on drives the controller
can't boot from.

4- To do this, I use rdisk numbers determined in other ways than suggested
by you, because your method doesn't provide rdisk numbers for drives that
can't be booted by the controller.

5- This works. Windows can start from a drive that can't be booted by the
controller, given that the necessary files (ntldr and boot.ini among them)
are present and properly installed on a drive it can boot from.

6- Your claimed rule can't be used to determine the rdisk number for those
drives, yet they do have an rdisk number that can be used in boot.ini.

7- From this follows that the boot order (the term as used by you) is not a
generally usable method to determine the rdisk number of a drive for use in
boot.ini, as it requires the controller to be able to boot from the drive
in question.


(A maybe important side note:

There is a difference between "booting" and "starting Windows".

Only in words.

The boot drive does not have to be the one where Windows is installed.

As in: the second bootstage (OS bootstage) doesn't need it to be
on the same drive as where the OS bootstage is started from.

The boot drive needs to be the one that contains -- among other things --
boot.ini

and that gets booted by the controller.

Nope. That get's booted (through Int 19, supplied by the MoBo BIOS)
by the bootcode in the MBR (using Int13 supplied by the controller BIOS)
which in turn starts NTLDR which starts Windows.

Windows can be installed on another drive; that would be the one the rdisk
parameter points to, and this drive does not have to be bootable by the
controller.

It seems you can't replicate such a situation on your system,
because it seems your controller can boot from all drives you have
currently installed. You'd have to install a drive that you can't boot from
or run this on a system that has drives installed that the controller can't
boot to see first hand what I mean -- if you don't know it.)

That is a load of bollocks. Controllers don't boot, the system(MoBo) does.

 

[Rod Speed]

Some ****wit pseudokraut claiming to be
usual pathetic excuse for a troll thats all it can ever manage.

 

[Gerhard Fiedler]

Then the both of you seem to be disagreeing with what Microsoft and
Roddles say.

No. Just with what Tim said.

 

[Rod Speed]

Folkert Rienstra wrote

No. Just with what Tim said.

Then you arent actually saying that it varys, because
neither MS or I say that it varys. The rdisk() param
is always the ordinal of the drive on the controller.

 

[Antoine Leca]

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

All that shows is that its a relatively sophisticated loader
that does quite a bit of what ntldr does.

Which is more or less what I wanted you to understand.

Says nothing useful what so ever about whether either is a 'reduced' OS.

Here, you are missing that Syslinux does more or less what did DOS v.1. (far
more and little less).
Hold on, before you comment, see below!

Neither is, they are just relatively sophisticated loaders.

All completely irrelevant to whether either are 'reduced' OSs.

Sure, as I said (probably was unclear though)

They arent, they are just relatively sophisticated loaders for
different OSs.

What they are as you wrote is what they are _for_.

Qualifying them as reduced OS is a description of their _architecture_
(which is also why I emphatized about management), not their functions; that
is not incompatible in my eyes (and it is the reason I used 'reduced' in the
first place.)


Antoine

 

[Rod Speed]

Rod Speed wrote

Which is more or less what I wanted you to understand.

Irrelevant to whether ntldr is a 'reduced' OS, it isnt.

Here, you are missing that Syslinux does more
or less what did DOS v.1. (far more and little less).

Irrelevant to whether ntldr or syslinux is a 'reduced' OS.

Neither of them are.

Hold on, before you comment, see below!

No thanks.

Sure, as I said (probably was unclear though)

What is the point in even mentioning Syslinux when what is
being discussed is whether ntldr is a 'reduced' OS or not ?

Its no news what so ever that there are a variety of loaders around.

What they are as you wrote is what they are _for_.

Pity what was being discussed was whether
ntldr is a 'reduced' OS or not. It aint.

Qualifying them as reduced OS is a description of their _architecture_

No it isnt, its just plain wrong. ntldr is NOT an OS, its a loader.

(which is also why I emphatized about management),
not their functions; that is not incompatible in my eyes
(and it is the reason I used 'reduced' in the first place.)

ntldr is STILL not an OS or a 'reduced' OS either.
Its a loader. Its even named that way. Funny that.

 

[Antoine Leca]

En Rod Speed va escriure:

Nope,

You are saying the same as I said: most of this thread (not just the post
quoted above) is irrelevant to the...

the whole point of this thread is what the rdisk() param means,



The whole point of the boot.ini was to allow booting of what the bios
could not boot.
Admitting.

That is STILL true of a logical drive in an extended dos partition,

What is true?
A boot loader allows to sever the link between the booting (active)
partition and the kernel location. Great.

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

Because that is not BIOS' job, rather the one for the code inside the boot
records (MBR and the one for the active partition); if there is code at the
beginning of the extended partition(s) to load the logical one, and if there
is the correct code in the boot record of your logical drive, you'll
succeed.

I perfectly know IBM/Microsoft's Fdisk does not store such code.

I'm not aware of any that allows that.

Almost any BIOS is able to do it.

I wasnt talking about that, I was talking
about where the OS comes from, not ntldr.

Then please reformulate, I did not catch your point at all.

And to allow booting that the bios cannot do, like
booting an install of the NT/2K/XP family from a
logical drive within an extended dos partition.

And booting several OS installed in the same partition, perhaps of different
vintage (something that was really horrible back in OS/2 time).

As I also said a number of times in this thread.

Yes . This thread is full of repetitions and not very useful comments. I
do not believe you and I are likely to learn anything. I wonder if anyone is
going to learn anything at this point, in fact.

If there
aint even a hard drive boot order list, the rdisk() param
cant possibly be the ordinal in the hard drive boot order
list because there isnt one in some bios.

Was my point in the first place .

Thats just plain wrong with the most basic functionality of boot.ini,

???
Read http://support.microsoft.com/kb/102873 (knowing that NT was born on
MIPS) and you'll see that Boot.ini is a "solution" to supplement the lack of
a firmware way to record strings in a PC.

to provide a way to specify where the various OSs etc are on the
hard drives. That has to do be done somehow with any boot manager.

It could have been done using the disk(N) parameter instead, like with SCSI,
and it would have worked equally well. The fact there are two indices is a
given input, not a decision of the team. Using ARC paths including for i386
also was.

N could also have been defined clearly as the BIOS drive number, also
(signature() translates to scsi(128), for instance, although it came later).


It surely is convenient to be able to boot from another disk, but the main
beef for the ARC path and boot.ini is really with partition(N) and \WINNT,
not rdisk(N).

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.



Antoine

 

[Gerhard Fiedler]

Was my point in the first place .

That was yours, and Rod's and mine, while Tim made a different one:

---------------------------------------
Timothy Daniels wrote on 1/27:

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.

---------------------------------------

All the rest developed from not being able to reconcile these two
positions.

(And note, responding to another comment of yours, that Tim did not write
"/I/ can also think of ... relative to the head of /my/ BIOS's hard drive
boot order", he wrote "/You/ can also think of ... /the/ BIOS's ..." --
which generally means "any BIOS's ...". Which is not correct, as this is
apparently only so in his BIOS and perhaps a few unnamed others, and so
it's only him who can think like this, and only as long as he uses his
specific computer.)

Gerhard

 

[Gerhard Fiedler]

Then you arent actually saying that it varys, because neither MS or I
say that it varys. The rdisk() param is always the ordinal of the drive
on the controller.

I didn't say that it is this that varies.

What varies is how exactly this ordinal is created, and since MS doesn't
specify this, I can't disagree with MS on this. (Whether I disagree with
you, I don't know... It varies from computer to computer, as it is one
of or a combination of BIOS and controller and hard disk and their
respective configurations that determines what drive has what ordinal.

For example, on Tim's computer you apparently can switch the ordinals
around through reconfiguration in the BIOS. On most computers, you can't do
that. So yes, /this/ varies.

Gerhard

 

[Rod Speed]

Rod Speed wrote

except with that abortion of a bios that Timmy
has, if he isnt just mindlessly trolling/lying on that.

I didn't say that it is this that varies.

What varies is how exactly this ordinal is created,

Nope, except with that abortion of a bios that Timmy
has, if he isnt just mindlessly trolling/lying on that.

and since MS doesn't specify this,

Yes it does, MS says its the ordinal of the drive on the controller.
The phraseology could be clearer, but MS does specify that.

I can't disagree with MS on this.

You just did, MS does not say that
the meaning of the rdisk() param varys.

(Whether I disagree with you, I don't know...

Neither MS nor I say that the meaning of the rdisk() param varys.

It varies from computer to computer,

No it doesnt.

as it is one of or a combination of BIOS and controller
and hard disk and their respective configurations that
determines what drive has what ordinal.

Thats not the same thing as the MEANING of the rdisk() param
varying. Of course the actual number varys with the config.

For example, on Tim's computer you apparently can switch
the ordinals around through reconfiguration in the BIOS. On
most computers, you can't do that. So yes, /this/ varies.

Thats just because of the abortion seen with Timmy's bios
and since there is no point in doing it that way, its very
unlikely indeed to have been designed like that deliberately.

Its no news that there can be warts in bios.

 

[Rod Speed]

Rod Speed wrote

You are saying the same as I said: most of this thread
(not just the post quoted above) is irrelevant to the...

Nope, I am NOT saying that. A few bits of this thread like
your claim that ntldr is a 'reduced' OS is certainly irrelevant
to the whole point of the thread, what the rdisk() param
represents, but that is nothing like most of the thread.

Most of the tread is about what the rdisk() param represents.

What is true?

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

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

A boot loader allows to sever the link between the
booting (active) partition and the kernel location. Great.

Yes, that is like I said one of the whole points of ntldr.

Because that is not BIOS' job,

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

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

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.

if there is code at the beginning of the extended partition(s)
to load the logical one, and if there is the correct code in
the boot record of your logical drive, you'll succeed.

I perfectly know IBM/Microsoft's Fdisk does not store such code.

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

Almost any BIOS is able to do it.

Not boot a logical drive within an extended dos
partition without the use of a loader like ntldr.

That is one of the reasons for the ntldr system.

Then please reformulate, I did not catch your point at all.

That few if any bios can boot a logical drive that is in an
extended dos partition without ntldr or something similar
being used. That was one of the whole points of ntldr,
to allow that to be done, boot of a logical drive in an
extended dos partition, because the bios cant do that.

And booting several OS installed in the same
partition, perhaps of different vintage (something
that was really horrible back in OS/2 time).

One follows from the other.

Yes . This thread is full of repetitions and not very useful
comments. I do not believe you and I are likely to learn anything.

Yes, but it has shown that Timmy's original claim that the
rdisk() param is the orginal in the hard drive boot list order
is just plain wrong and that its just an abortion that has been
perpertrated in the bios in the system he is personally using.

I wonder if anyone is going to learn anything at this point, in fact.

Time will tell. If nothing else some lurkers may well learn that
Timmy couldnt bullshit his way out of a wet paper bag and they
may well look more closely at any claim he makes in the future.

Many dont bother reading longer threads, so they are irrelevant.

Was my point in the first place .

You were always Johnny come lately on that.

???
Read http://support.microsoft.com/kb/102873
(knowing that NT was born on MIPS)

I didnt say it wasnt.

and you'll see that Boot.ini is a "solution" to supplement
the lack of a firmware way to record strings in a PC.

Its purpose was a lot more than that.

It could have been done using the disk(N) parameter instead,
like with SCSI, and it would have worked equally well.

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

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

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

That sentence makes no sense.

Using ARC paths including for i386 also was.

Neither does that.

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.

also (signature() translates to scsi(128),
for instance, although it came later).

Yes, basically to handly more dynamic configs like with removable drives.

It surely is convenient to be able to boot from another
disk, but the main beef for the ARC path and boot.ini
is really with partition(N) and \WINNT, not rdisk(N).
Nope.

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

Because it isnt.

 

[Folkert Rienstra]

Rod Speed wrote

Rod Speed wrote
Gerhard Fiedler wrote
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.

[SNIP]

Problably yes. Like the most part of this thread...

[SNIP]

You are saying the same as I said: most of this thread
(not just the post quoted above) is irrelevant to the...

the whole point of this thread is what the rdisk() param means,

[SNIP]

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.
Now *I* ask what is the relevance of this remark
with the whole point of the rdisk() parameter.
The whole point of the boot.ini was to allow
booting of what the bios could not boot.

Admitting.

That is STILL true of a logical drive in an extended dos partition,

What is true?

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

None can. The boot interrupt is Int19 and it is clearly defined.

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

Exactly, so no to "few if any".

To allow this to happen the functionality has to be incorporated
in the MBR bootcode and possibly the rest of track 0.

A boot loader allows to sever the link between the
booting (active) partition and the kernel location. Great. [SNIP]

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

Because that is not a BIOS' job,

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

Through Int19, that's why not. You have been told several times now.
It involves a change to *not* boot through Int19.

Thats just the way ntldr does it.

Yes.
NTLDR is absolutely nowhere without the bootcode in the MBR and
partition bootrecord.

It doesnt have to be done that way. [SNIP]

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.

Because the BIOS is OS (and filesystem) independent.
The MBR bootcode and partition boot code are responsible for any
other/extra functionality.

if there is code at the beginning of the extended partition(s)
to load the logical one, and if there is the correct code in
the boot record of your logical drive, you'll succeed.

I perfectly know IBM/Microsoft's Fdisk does not store such code. [SNIP]

I'm not aware of any that allows that.

Almost any BIOS is able to do it.

With the help of revised MBR bootcode.

Not boot a logical drive within an extended dos
partition without the use of a loader like ntldr.

Only because the functionality in NTLDR is far
to big to be crammed in the MBR and track0.

That is one of the reasons for the ntldr system.
Exactly.



That few if any bios can boot a logical drive that is in an
extended dos partition without ntldr or something similar
being used. That was one of the whole points of ntldr,
to allow that to be done, boot of a logical drive in an
extended dos partition, because the bios cant do that.

Nonsense. You don't need NTLDR for that at all.
Booting a nonprimary partition is dead easy.
Booting it on a different physical drive involves a bit more
but may still be done without the help of a program.
But since you need NTLDR anyway to get Windows in the air
there is no reason to do it differently from what it is now.

And booting several OS installed in the same
partition, perhaps of different vintage (something
that was really horrible back in OS/2 time). [SNIP]

as I am saying since the first post after Tim's...
As I also said a number of times in this thread.

Yes . This thread is full of repetitions and not very useful
comments. I do not believe you and I are likely to learn anything. [SNIP]
I wonder if anyone is going to learn anything at this point, in fact. [SNIP]

If there aint even a hard drive boot order list, the rdisk()
param cant possibly be the ordinal in the hard drive
boot order list because there isnt one in some bios.

Was my point in the first place . [SNIP]

One is that the ARC path rdisk(N) mechanism was designed around
1990 to make a gateway between the RISC world (where NT originally
was born) and the Intel/IBM/Compaq "i386" architecture; that's long
before BBS. I very much doubt if MS had the choice, they will still
use it in 2006 (NT on MIPS anyone?) As such, it is much of a
legacy of the history, like for example the Int13 interface itself.
Thats just plain wrong with the most basic functionality of boot.ini,

???
Read http://support.microsoft.com/kb/102873
(knowing that NT was born on MIPS) [SNIP]
and you'll see that Boot.ini is a "solution" to supplement
the lack of a firmware way to record strings in a PC. [SNIP]

to provide a way to specify where the various OSs etc are on the
hard drives. That has to do be done somehow with any boot manager.

It could have been done using the disk(N) parameter instead,
like with SCSI, and it would have worked equally well. [SNIP]

The fact there are two indices is a given input, not a decision of the team. [SNIP]
Using ARC paths including for i386 also was. [SNIP]
N could also have been defined clearly as the BIOS drive number, [SNIP]
also (signature() translates to scsi(128), for instance, although it came later). [SNIP]

It surely is convenient to be able to boot from another
disk, but the main beef for the ARC path and boot.ini
is really with partition(N) and \WINNT, not rdisk(N). [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.

Bullshit.
That is how MS stupidly implemented it, contrary to
what the documentation implies.

 

[Gerhard Fiedler]

Yes it does, MS says its the ordinal of the drive on the controller.
The phraseology could be clearer, but MS does specify that.

What determines the actual number of the ordinal of the drive on the
controller? The controller? The BIOS? Is there a universally defined
process, or does it in fact vary?

Thats not the same thing as the MEANING of the rdisk() param varying.

I don't remember writing that the meaning varies -- this must be a
misunderstanding.

Of course the actual number varys with the config.

What I remember writing is that it varies "how exactly this ordinal is
created" -- with which I meant the actual number. Maybe wasn't worded in
the best possible way...

Gerhard

 

[Rod Speed]

Rod Speed wrote

What determines the actual number of
the ordinal of the drive on the controller?

The master/slave jumpering or the connector
used for the drive if cable select is used.

The controller? The BIOS? Is there a universally
defined process, or does it in fact vary?

No it doesnt vary.

I don't remember writing that the meaning
varies -- this must be a misunderstanding.

Just you with a problem with basic english.

What I remember writing is that it varies "how exactly
this ordinal is created" -- with which I meant the actual
number. Maybe wasn't worded in the best possible way...

Your wording was irrelevant. Its obvious what 'it varys' means.

 

[Rod Speed]

Rod Speed wrote
Rod Speed wrote
Gerhard Fiedler wrote
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. [SNIP]

Problably yes. Like the most part of this thread... [SNIP]

You are saying the same as I said: most of this thread
(not just the post quoted above) is irrelevant to the...
the whole point of this thread is what the rdisk() param means, [SNIP]

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.

Now *I* ask what is the relevance of this remark
with the whole point of the rdisk() parameter.

The whole point of the boot.ini was to allow
booting of what the bios could not boot.

That is STILL true of a logical drive in an extended dos partition,

What is true?

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

None can.

I said it that way because no one can ever
know what every single bios out there can do.

The boot interrupt is Int19 and it is clearly defined.

But is irrelevant to what the bios can do.

As you say below, you dont need ntldr to do that, so
the bios can certainly implement that functionality if
it chooses to. I'm not aware of any bios that does tho.

Exactly, so no to "few if any".

Wrong, as always.

To allow this to happen the functionality has to be incorporated
in the MBR bootcode and possibly the rest of track 0.

No it doesnt. The bios could incorporate that
code if the bios designer chose to do it that way.

A boot loader allows to sever the link between the
booting (active) partition and the kernel location. Great. [SNIP]

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

Because that is not a BIOS' job,

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

Through Int19, that's why not.

The bios doesnt have to use int19 to do that.

You have been told several times now.

You have made a spectacular fool of yourself several times now.

Nothing new about that.

It involves a change to *not* boot through Int19.

And there is no reason why the bios couldnt be done like that.

Yes.
NTLDR is absolutely nowhere without the
bootcode in the MBR and partition bootrecord.

It doesnt have to be done that way. [SNIP]

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.

Because the BIOS is OS (and filesystem) independent.
Duh.

The MBR bootcode and partition boot code are
responsible for any other/extra functionality.

Currently, yes. That isnt cast in stone tho.

There is not technical reason why what is currently done
in the MBR and PBR cant be done by the bios instead.

if there is code at the beginning of the extended partition(s)
to load the logical one, and if there is the correct code in
the boot record of your logical drive, you'll succeed.

I perfectly know IBM/Microsoft's Fdisk does not store such code. [SNIP]

I'm not aware of any that allows that.
Almost any BIOS is able to do it.

With the help of revised MBR bootcode.
Duh.

Only because the functionality in NTLDR is far
to big to be crammed in the MBR and track0.

Thats mostly for other stuff like the menu presented to the user at
boot time etc and the vast array of other stuff that ntldr does as well.

Separate issue entirely to JUST booting from a logical drive
in an extended dos partition. That doesnt involve much at all
and could be done by the bios if the designer chose to offer
that capability.

Nonsense. You don't need NTLDR for that at all.

Wrong, as always.

Booting a nonprimary partition is dead easy.
Duh.

Booting it on a different physical drive involves a bit more
but may still be done without the help of a program.
Duh.

But since you need NTLDR anyway to get Windows in the air
there is no reason to do it differently from what it is now.

I clearly said ntldr or some other loader, stupid.

The very purpose of Ntldr+Boot.ini, like any
boot loader, is to enhance flexibility, yes.

And to allow booting that the bios cannot do, like
booting an install of the NT/2K/XP family from a
logical drive within an extended dos partition.

And booting several OS installed in the same
partition, perhaps of different vintage (something
that was really horrible back in OS/2 time). [SNIP]

as I am saying since the first post after Tim's...

As I also said a number of times in this thread.

Yes . This thread is full of repetitions and not very useful
comments. I do not believe you and I are likely to learn anything. [SNIP]
I wonder if anyone is going to learn anything at this point, in
fact. [SNIP]

If there aint even a hard drive boot order list, the rdisk()
param cant possibly be the ordinal in the hard drive
boot order list because there isnt one in some bios.

Was my point in the first place . [SNIP]
One is that the ARC path rdisk(N) mechanism was designed around
1990 to make a gateway between the RISC world (where NT originally
was born) and the Intel/IBM/Compaq "i386" architecture; that's
long before BBS. I very much doubt if MS had the choice, they
will still use it in 2006 (NT on MIPS anyone?) As such, it is
much of a legacy of the history, like for example the Int13
interface itself.

Thats just plain wrong with the most basic functionality of
boot.ini,

???
Read http://support.microsoft.com/kb/102873
(knowing that NT was born on MIPS) [SNIP]
and you'll see that Boot.ini is a "solution" to supplement
the lack of a firmware way to record strings in a PC. [SNIP]
to provide a way to specify where the various OSs etc are on the
hard drives. That has to do be done somehow with any boot manager.

It could have been done using the disk(N) parameter instead,
like with SCSI, and it would have worked equally well. [SNIP]

The fact there are two indices is a given input, not a decision of
the team. [SNIP]
Using ARC paths including for i386 also was. [SNIP]
N could also have been defined clearly as the BIOS drive number, [SNIP]
also (signature() translates to scsi(128), for instance, although
it came later). [SNIP]

It surely is convenient to be able to boot from another
disk, but the main beef for the ARC path and boot.ini
is really with partition(N) and \WINNT, not rdisk(N). [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.

Because it isnt.

Bullshit.

Nope.

That is how MS stupidly implemented it,
contrary to what the documentation implies.

Bullshit.