meaning of "rdisk()" in boot.ini file

[Timothy Daniels]

ABSTRACT

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


HARDWARE

Dell Dimension XPS-R450 with a Phoenix Tech BIOS,
(3) Maxtor DiamondMaxPlus 9 hard drives connected to
(1) SIIG IDE PCI controller card used in the 1st half of
the investigation, and connected to
(1) motherboard IDE controller used in the 2nd half of
the investigation.


HARD DRIVE CONFIGURATION

IDE channel 0, Master - 80GB hard drive
IDE channel 0, Slave - 40GB hard drive
IDE channel 1, Master - 120GB hard drive

Each HD had a Master Boot Record (MBR),
each HD had as its partition #1 a Primary partition
that
1) had a Boot Sector,
2) was marked "Active", and which
3) contained the boot files ntldr, boot.ini, and ntdetect.com .


SOFTWARE CONFIGURATION

Microsoft WindowsXP Pro installed in partition #1 of each HD.

boot.ini file in the 80GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(80GB part 1 boot.ini) rdisk 2, part 1" /fastdetect

boot.ini file in the 40GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(40GB part 1 boot.ini) rdisk 2, part 1" /fastdetect

boot.ini file in the 120GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(120GB part 1 boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(120GB part 1 boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(120GB part 1 boot.ini) rdisk 2, part 1" /fastdetect


Each of the above boot.ini file entries under the line
"[operating systems]" specified an OS in partition #1 of one
of the HDs, i.e. from "rdisk(0)", "rdisk(1)", or "rdisk(2)".
The character string between the quotes in each OS entry
became a line in the on-screen menu displayed by ntldr at
boot time, and it was to aid in identifying which HD got
control from the BIOS (i.e 80GB, 40GB, or 120GB) and which
"rdisk()" value each line corresponded to.

A file with a name identifying the HD which contained it
was put on the Desktop of each OS. This was to aid in identi-
fying the HD of the OS that was loaded.


EXPERIMENT

Each HD was in turn put at the head of the BIOS's hard drive
boot order and the PC was started. Each of the three entries in
the on-screen boot menu was selected in turn, and the OS that
loaded was recorded. Since the boot.ini files contained entries
only for the partition #1 on each HD, the experiment was a specific
test for the meaning of the "rdisk()" parameter.

Then the order of the 2nd and 3rd HD in the hard drive boot order
was reversed in the BIOS, and the above experiment was repeated.

Then, the hard drives were disconnected from the IDE PCI controller
card and connected to the IDE controller on the motherboard, and the
entire experimental sequence detailed above was repeated. A total of
36 boot-ups were executed.


RESULTS

The following results were identical for both the PCI IDE controller
case and for the motherboard IDE controller case:

HD boot order: 80GB, 40GB, 120GB
boot menu entry selected: HD the OS booted from:
(80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1
(80GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1
(80GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1

HD boot order: 80GB, 120GB, 40GB
boot menu entry selected: HD the OS booted from:
(80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1
(80GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1
(80GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1

HD boot order: 40GB, 80GB, 120GB
boot menu entry selected: HD the OS booted from:
(40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1
(40GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1
(40GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1

HD boot order: 40GB, 120GB, 80GB
boot menu entry selected: HD the OS booted from:
(40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1
(40GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1
(40GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1

HD boot order: 120GB, 40GB, 80GB
boot menu entry selected: HD the OS booted from:
(120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1
(120GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1
(120GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1

HD boot order: 120GB, 80GB, 40GB
boot menu entry selected: HD the OS booted from:
(120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1
(120GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1
(120GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1


DISCUSSION

The OS always booted from the hard drive having a position in
the hard drive boot order expressed as the n in "rdisk(n)" parameter
of the boot.ini file entry. This correspondence persisted throughout
all all permutations of the hard drive boot order and despite which
IDE controller the HDs were connected to. Whether this is the case
in other less common BIOSes is unknown by this investigator. But
since the Phoenix Technologies' BIOSes are used by many large
PC manufacturers, it is probably a very common meaning of "rdisk()"
among modern PCs running a Microsoft Windows operating system.


*TimDaniels*

 

[Rod Speed]

ABSTRACT

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


HARDWARE

Dell Dimension XPS-R450 with a Phoenix Tech BIOS,
(3) Maxtor DiamondMaxPlus 9 hard drives connected to
(1) SIIG IDE PCI controller card used in the 1st half of
the investigation, and connected to
(1) motherboard IDE controller used in the 2nd half of
the investigation.


HARD DRIVE CONFIGURATION

IDE channel 0, Master - 80GB hard drive
IDE channel 0, Slave - 40GB hard drive
IDE channel 1, Master - 120GB hard drive

Each HD had a Master Boot Record (MBR),
each HD had as its partition #1 a Primary partition
that
1) had a Boot Sector,
2) was marked "Active", and which
3) contained the boot files ntldr, boot.ini, and ntdetect.com .


SOFTWARE CONFIGURATION

Microsoft WindowsXP Pro installed in partition #1 of each HD.

boot.ini file in the 80GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(80GB part 1
boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(80GB part 1
boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(80GB part 1 boot.ini)
rdisk 2, part 1" /fastdetect
boot.ini file in the 40GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(40GB part 1
boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(40GB part 1
boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(40GB part 1 boot.ini)
rdisk 2, part 1" /fastdetect
boot.ini file in the 120GB HD:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(120GB part 1
boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(120GB part 1
boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(120GB part 1 boot.ini)
rdisk 2, part 1" /fastdetect

Each of the above boot.ini file entries under the line
"[operating systems]" specified an OS in partition #1 of one
of the HDs, i.e. from "rdisk(0)", "rdisk(1)", or "rdisk(2)".
The character string between the quotes in each OS entry
became a line in the on-screen menu displayed by ntldr at
boot time, and it was to aid in identifying which HD got
control from the BIOS (i.e 80GB, 40GB, or 120GB) and which
"rdisk()" value each line corresponded to.

A file with a name identifying the HD which contained it
was put on the Desktop of each OS. This was to aid in identi-
fying the HD of the OS that was loaded.


EXPERIMENT

Each HD was in turn put at the head of the BIOS's hard drive
boot order and the PC was started. Each of the three entries in
the on-screen boot menu was selected in turn, and the OS that
loaded was recorded. Since the boot.ini files contained entries
only for the partition #1 on each HD, the experiment was a specific
test for the meaning of the "rdisk()" parameter.

Then the order of the 2nd and 3rd HD in the hard drive boot order
was reversed in the BIOS, and the above experiment was repeated.

Then, the hard drives were disconnected from the IDE PCI controller
card and connected to the IDE controller on the motherboard, and the
entire experimental sequence detailed above was repeated. A total of
36 boot-ups were executed.


RESULTS

The following results were identical for both the PCI IDE
controller case and for the motherboard IDE controller case:

HD boot order: 80GB, 40GB, 120GB
boot menu entry selected: HD the OS booted from:
(80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1
(80GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1
(80GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1

HD boot order: 80GB, 120GB, 40GB
boot menu entry selected: HD the OS booted from:
(80GB part 1 boot.ini) rdisk 0, part 1 80GB, part 1
(80GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1
(80GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1

HD boot order: 40GB, 80GB, 120GB
boot menu entry selected: HD the OS booted from:
(40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1
(40GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1
(40GB part 1 boot.ini) rdisk 2, part 1 120GB, part 1

HD boot order: 40GB, 120GB, 80GB
boot menu entry selected: HD the OS booted from:
(40GB part 1 boot.ini) rdisk 0, part 1 40GB, part 1
(40GB part 1 boot.ini) rdisk 1, part 1 120GB, part 1
(40GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1

HD boot order: 120GB, 40GB, 80GB
boot menu entry selected: HD the OS booted from:
(120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1
(120GB part 1 boot.ini) rdisk 1, part 1 40GB, part 1
(120GB part 1 boot.ini) rdisk 2, part 1 80GB, part 1

HD boot order: 120GB, 80GB, 40GB
boot menu entry selected: HD the OS booted from:
(120GB part 1 boot.ini) rdisk 0, part 1 120GB, part 1
(120GB part 1 boot.ini) rdisk 1, part 1 80GB, part 1
(120GB part 1 boot.ini) rdisk 2, part 1 40GB, part 1


DISCUSSION

The OS always booted from the hard drive having a position in
the hard drive boot order expressed as the n in "rdisk(n)" parameter
of the boot.ini file entry. This correspondence persisted throughout
all all permutations of the hard drive boot order and despite which
IDE controller the HDs were connected to. Whether this is the case in
other less common BIOSes is unknown by this investigator.

Still lying. The Phoenix bios is in fact the least common of the 3 majors.

But since the Phoenix Technologies' BIOSes are used by many large PC
manufacturers,

Bugger all, actually.

it is probably a very common meaning of "rdisk()" among modern PCs
running a Microsoft Windows operating system.

Wrong, as always. And have fun explaining why ALL the documentation
of the ARC path naming convention fails to mention the hard drive boot
order at all when documenting the rdisk() parameter. There has GOT
to be a reason for that.

AND its a stupid way to implement a system anyway because the
boot.ini file would have to be changed when the boot order is changed.

ALL the evidence points to the fact that its a terminal
stupidity that has been perpetrated in the Phoenix bios
and that it doesnt get mentioned just because the phoenix
bios is by far the least commonly used of the big 3.

 

[Timothy Daniels]

"Rod Speed" non-sequitured:

....have fun explaining why ALL the documentation
of the ARC path naming convention fails to mention the
hard drive boot order at all when documenting the rdisk()
parameter. There has GOT to be a reason for that.

AND its a stupid way to implement a system anyway
because the boot.ini file would have to be changed
when the boot order is changed.

ALL the evidence points to the fact that its a terminal
stupidity that has been perpetrated in the Phoenix bios
and that it doesnt get mentioned just because the phoenix
bios is by far the least commonly used of the big 3.

All I did was report reality. What does it matter what
some obscure specification says? Do you run a spec
or a PC?

*TimDaniels*

 

[Timothy Daniels]

ALL the evidence points to the fact that its a terminal
stupidity that has been perpetrated in the Phoenix bios
and that it doesnt get mentioned just because the phoenix
bios is by far the least commonly used of the big 3.

Maybe. But Dell is a MAJOR brand.

*TimDaniels*

 

[Rod Speed]

Rod Speed non-sequitured

Lying, as always.

All I did was report reality.

No you didnt. You reported what YOU see on a badly implemented
system and claimed that that proved that the rdisk() param is the boot
drive order number on all systems out there. That is just plain wrong.

What does it matter what some obscure specification says?

It matters because it proves that your claim that the rdisk() parameter
is ALWAYS the boot order sequence number is just plain wrong when
that spec for the boot.ini file, written by the designers of that boot.ini
file dont even mention the boot order sequence number with rdisk()

Do you run a spec or a PC?

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

 

[Timothy Daniels]

AND its a stupid way to implement a system anyway because the
boot.ini file would have to be changed when the boot order is changed.

What's so hard about that? In my normal system, which contains
8 or 9 bootable clones, the boot.ini file in each primary partition
contains a generic boot.ini file that has 10 optional entries (the max
for my BIOS). The comment character string in each entry indicates
its rdisk() and partition() value, and knowing where the desired clone
is in the boot order, I can boot to any clone in the system. Which is
harder - knowing the position of a HD in terms of IDE channel no. and
Master/Slave setting, or knowing where the HD is in the hard drive
boot order?

But the Phoenix BIOS, in fact, accomodates geriatric users such as
yourself. It has as a DEFAULT hard drive boot order which is tied to
the physical position of each hard drive:
Master, IDE channel 0
Slave, IDE chennel 0
Master, IDE channel 1
Slave, IDE channel 1

Thus, if one doesn't want to adjust the hard drive boot order (or doesn't
know how), one can just rely on the default hard drive boot order. To change
which hard drive is at the head of the order, one must physically rearrange
the hard drives. But hey(!), some people *like* restrictions more than
convenience.

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

Maybe.

No maybe about it.

But Dell is a MAJOR brand.

Irrelevant to your original pig ignorant claim that the rdisk()
param ALWAYS refers to the boot order sequence number,
on all systems, regardless of the bios.

ALL you have actually shown is that ONE particularly badly
designed system does it that way. And that is a terminally
stupid way to design it too, because even someone as
stupid as you should be able to grasp that if the rdisk()
param does refer to the boot order sequence number,
you have to edit the boot.ini whenever you change
anything in the boot order sequence that shifts the
drive that line in the boot.ini refers to in the order.

That is just plain completely ****ed.

 

[Rod Speed]

Rod Speed wrote

What's so hard about that?

Never ever said anything about being hard. Just stupid to need
to edit the boot.ini files when a change is made to the boot order.

If you do want multiple copys of bootable OSs available to boot
between quickly, the only approach that makes any sense at all
is to select which system to boot from the boot.ini, and to have
that boot.ini duplicated on at least two physical drives, so that
even if one of the drives does die, the worst you have to do is
to change the boot order in the bios and continue to select the
system to boot from the boot.ini menu. You would by definition
know that some of the menu items arent available when they
are on the dead drive.

It makes absolutely no sense to have to edit the boot.ini
to be able to boot the system you want to boot after the
boot order has been changed. It makes a hell of a lot more
sense for the rdisk() parameter to be the physical drive
on the particular controller specified in the boot.ini instead
with that only needing to be edited if drives are rearranged
on a particular controller in the master/slave sense.

In my normal system,

Which has always had a completely ****ed mindlessly silly config.

which contains 8 or 9 bootable clones,

Mindlessly silly for starters.

the boot.ini file in each primary partition contains a generic boot.ini
file that has 10 optional entries (the max for my BIOS).

It makes a hell of a lot more sense for all those boot.ini files
to be identical and reflect the location of the bootable systems
regardless of the boot order specified in the bios. Then
regardless of which physical drive is booted by the bios
boot list, the user just selects from the same boot.ini
menu which particular system he wants to boot.

The comment character string in each entry indicates its rdisk() and
partition() value,

You dont need to bother if the boot.ini files are all identical and
the rdisk() value is the physical drive on the particular controller.

and knowing where the desired clone is in the boot order, I can boot to
any clone in the system.

You dont have to know if the boot.ini files are all identical and
the rdisk() param doesnt vary with the boot order in the bios.

Which is harder - knowing the position of a HD in terms of IDE channel
no. and Master/Slave setting,

That only has to be known when writing the single boot.ini
file that is on every bootable drive. No need to have to know
that when a drive has failed and you have changed the boot
order in the bios to get it to get the bios to boot a drive.

AND what matters is that there is absolutely no point in
the rdisk() parameter referring to the entry in the bios
boot order list at all. None, zero, nada, ziltch.

Its just a completely ****ed and stupid way to design a system.

or knowing where the HD is in the hard drive boot order?

But the Phoenix BIOS, in fact, accomodates geriatric users such as
yourself.

No it doesnt, the ****ed approach it uses fails when the
drive you normally have the bios boot is no longer bootable
for whatever reason. In that case you have to BOTH change
the boot sequence, AND edit the boot.ini thats on that drive.

That is completely ****ed.

It has as a DEFAULT hard drive boot order which is tied to the physical
position of each hard drive:
Master, IDE channel 0
Slave, IDE chennel 0
Master, IDE channel 1
Slave, IDE channel 1

The default order is completely irrelevant when configuring
the system so you can quickly boot anything thats on other
than a drive which has failed or has been unplugged etc.

Thus, if one doesn't want to adjust the hard drive boot order (or doesn't
know how), one can just rely on the default hard drive boot order.

Useless if the reason for the multiple bootable OSs is to
allow you to quickly boot something useful on a drive failure.

To change which hard drive is at the head of the order, one must
physically rearrange the hard drives.

Terminally stupid approach.

But hey(!), some people *like* restrictions more than convenience.

What a terminal ****wit you have always been, child.

 

[Folkert Rienstra]

[snip]

DISCUSSION

The OS always booted from the hard drive having a position in
the hard drive boot order expressed as the n in "rdisk(n)" parameter
of the boot.ini file entry. This correspondence persisted throughout
all all permutations of the hard drive boot order and despite which
IDE controller the HDs were connected to. Whether this is the case in
other less common BIOSes is unknown by this investigator.

Still lying. The Phoenix bios is in fact the least common of the 3 majors.

But since the Phoenix Technologies' BIOSes are used by many large PC
manufacturers,

Bugger all, actually.

it is probably a very common meaning of "rdisk()" among modern PCs
running a Microsoft Windows operating system.

Wrong, as always. And have fun explaining why ALL the documentation
of the ARC path naming convention fails to mention the hard drive boot
order at all when documenting the rdisk() parameter.

There has GOT to be a reason for that.

And here's that wet paper bag for Roddy.

AND its a stupid way to implement a system anyway because the
boot.ini file would have to be changed when the boot order is changed.

ALL the evidence > points to the fact that its a terminal
stupidity that has been perpetrated in the Phoenix bios
and that it doesnt get mentioned just because the phoenix
bios is by far the least commonly used of the big 3.

And another one. Roddy grasping at fibres.

 

[Timothy Daniels]

"Rod Speed" floundered:

It makes a hell of a lot more sense for all those boot.ini files
to be identical and reflect the location of the bootable systems
regardless of the boot order specified in the bios. Then
regardless of which physical drive is booted by the bios
boot list, the user just selects from the same boot.ini
menu which particular system he wants to boot.

As I explained, each bootable partition in my PC has a
generic boot.ini file that allows booting from ANY of 10
partitions in the system. That means if one HD fails, the
boot.ini file in any partition in any of the remaing HDs could
be used without editing a thing. All you have to know is where
the clone is that you want to boot. The boot.ini file doesn't
have to know anything - indeed, they're all the same. The
comments in each entry tell you the values of rdisk() and
partition(), and you just choose the one having the path
that you want. I'm sorry that this has never occurred to you,
but I'm happy to educated you on modern techniques.

*TimDaniels*

 

[Rod Speed]

Rod Speed floundered

What a flagrantly dishonest arsehole you have always been Daniels.

As I explained, each bootable partition in my PC has a generic boot.ini
file that allows booting from ANY of 10 partitions in the system.

Even someone as stupid as you should be able to
grasp that IDENTICAL boot.ini files on ALL bootable
physical drives makes a hell of a lot more sense, ****wit.

That means if one HD fails, the boot.ini file in any partition in any of
the remaing HDs could be used without editing a thing.

But you have to **** around editing each of the boot.ini
files when the rdisk() param varys with each boot.ini
depending on the boot list entry that drive has at boot time.

All you have to know is where the clone is that you want to boot.

I'd rather have a single identical boot.ini with rdisk() values
which reflect the physical location of the physical drives
on the ribbon cables, rather than a completely ****ed system
with different boot.ini files on each physical drive with the
rdisk() param being the entry in the bios boot order list.

The boot.ini file doesn't have to know anything - indeed, they're all the
same.

No they arent.

The comments in each entry tell you the values of rdisk() and
partition(), and you just choose the one having the path that you want.

It makes a hell of a lot more sense for the comment
on each entry to list the actual OS install variant that
is to be booted by that entry with the user not even
being aware of which physical drive etc its on, ****wit.

I'm sorry that this has never occurred to you, but I'm happy to educated
you on modern techniques.

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

 

[Timothy Daniels]

"Rod Speed" ****witted and charmed:

Even someone as stupid as you should be able to
grasp that IDENTICAL boot.ini files on ALL bootable
physical drives makes a hell of a lot more sense, ****wit.

They ARE all identical. That's what I meant by "generic" -
the boot.ini file is NOT specific to the partition that it is in,
just as in my experiment that I've laboriously described.
All the boot.ini files in the system have the same contents.
Each boot.ini file has an entry for each path leading to
a partition in the system. Knowing the path, you just choose
the corresponding entry from the boot menu, each entry
being indicated by a character string that indicates the
rdisk() and partition() value of that entry. Look back at the
description of the boot.ini files in my experiment, and
imagine 10 entries per file instead of just 3, and one boot.ini
file in each partition. The setting of the "active" flag chooses
which partition's boot.ini file is used, but since all boot.ini's
are the same, it matters not.

In fact, though, since the length of the boot menu is
limited to 10, I cannot reference 4 primary partitions on
each of the hard drives because I have 3 hard drives -
necessitating 12 entries if I am to be able to address
all partitions. So, without editing, I am limited to 3 primary
partitions per hard drive, i.e. 9 bootable clones on the
3 HDs. But since most people have only 1 or 2 hard drives,
this limitation to 10 entries does not pose a problem (unless,
of course, one resorts to putting in more clones by use of
Extended partitions).

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

They ARE all identical.

Pity that you dont get the same OS booted when the user
selects a particular boot.ini entry at boot time, ****wit.
That means you cant even comment the particular
boot.ini entrys properly by the OS that will be booted
and the user has to know what OS is installed in each
of the physical partitions on each physical drive.

That is completely ****ed and useless and defeats the
whole purpose of the comment on each boot.ini entry.

And you didnt have identical boot.ini files in your purported test.

You're clearly still lying.

That's what I meant by "generic" - the boot.ini file is NOT specific to
the partition that it is in, just as in my experiment that I've
laboriously described. All the boot.ini files in the system have the same
contents.

They clearly dont in the sense that a particular
OS install will be booted when the same entry in
the boot.ini is selected by the user at boot time, liar.

Each boot.ini file has an entry for each path leading to
a partition in the system. Knowing the path, you just choose
the corresponding entry from the boot menu, each entry
being indicated by a character string that indicates the
rdisk() and partition() value of that entry. Look back at the
description of the boot.ini files in my experiment, and
imagine 10 entries per file instead of just 3, and one boot.ini
file in each partition. The setting of the "active" flag chooses
which partition's boot.ini file is used, but since all boot.ini's
are the same, it matters not.

Pity the user doesnt even see a list of OSs that
can be booted with that list always being the same
regardless of which physical drive is booted.

In fact, though, since the length of the boot menu is
limited to 10, I cannot reference 4 primary partitions on
each of the hard drives because I have 3 hard drives -
necessitating 12 entries if I am to be able to address
all partitions. So, without editing, I am limited to 3 primary
partitions per hard drive, i.e. 9 bootable clones on the
3 HDs. But since most people have only 1 or 2 hard drives,
this limitation to 10 entries does not pose a problem (unless,
of course, one resorts to putting in more clones by use of
Extended partitions).

And anyone with a clue, which obvious counts you out,
wouldnt be using boot.ini for a boot manager for that
utterly obscene mess you have managed to perpetrate.

 

[Timothy Daniels]

"Rod Speed" counts to 1:

And anyone with a clue, which obvious counts you out,
wouldnt be using boot.ini for a boot manager for that
utterly obscene mess you have managed to perpetrate.

Boot.ini is not a boot manager. It's just a menu for
the boot manager, which is ntldr. And it works quite
well... for *me*.

*TimDaniels*

 

[Rod Speed]

Rod Speed wrote

Boot.ini is not a boot manager. It's just a menu for the boot manager,
which is ntldr.

Utterly mindless juvenile hair splitting.

And it works quite well... for *me*.

It obviously doesnt when you have more things bootable
than you have entrys for in the boot.ini, ****wit.

Keep desperately digging, you'll be out in china any day now, as always.