A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » Storage (alternative)
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

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



 
 
Thread Tools Display Modes
  #1  
Old February 2nd 06, 12:30 PM posted to comp.sys.ibm.pc.hardware.storage
external usenet poster
 
Posts: n/a
Default meaning of "rdisk()" in boot.ini file

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)\WINDOW S
[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)\WINDOW S
[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)\WINDOW S
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(120G B part 1 boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(120G B part 1 boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(120G B 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*
  #2  
Old February 2nd 06, 08:04 PM posted to comp.sys.ibm.pc.hardware.storage
external usenet poster
 
Posts: n/a
Default meaning of "rdisk()" in boot.ini file

Timothy Daniels wrote:
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)\WINDOW S
[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)\WINDOW S
[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)\WINDOW S
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="(120G B part 1
boot.ini) rdisk 0, part 1" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="(120G B part 1
boot.ini) rdisk 1, part 1" /fastdetect
multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="(120G B 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.


  #3  
Old February 2nd 06, 09:47 PM posted to comp.sys.ibm.pc.hardware.storage
external usenet poster
 
Posts: n/a
Default meaning of "rdisk()" in boot.ini file

"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*
  #4  
Old February 2nd 06, 09:55 PM posted to comp.sys.ibm.pc.hardware.storage
external usenet poster
 
Posts: n/a
Default meaning of "rdisk()" in boot.ini file

"Rod Speed" wrote:
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*
  #5  
Old February 2nd 06, 11:49 PM posted to comp.sys.ibm.pc.hardware.storage
external usenet poster
 
Posts: n/a
Default meaning of "rdisk()" in boot.ini file

Timothy Daniels wrote
Rod Speed non-sequitured


Lying, as always.

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


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 bull**** its way out of a wet paper bag.


  #6  
Old February 2nd 06, 11:51 PM posted to comp.sys.ibm.pc.hardware.storage
external usenet poster
 
Posts: n/a
Default meaning of "rdisk()" in boot.ini file

"Rod Speed" wrote:

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*
  #7  
Old February 2nd 06, 11:54 PM posted to comp.sys.ibm.pc.hardware.storage
external usenet poster
 
Posts: n/a
Default meaning of "rdisk()" in boot.ini file

Timothy Daniels wrote
Rod Speed wrote


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.


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.


  #8  
Old February 3rd 06, 01:24 AM posted to comp.sys.ibm.pc.hardware.storage
external usenet poster
 
Posts: n/a
Default meaning of "rdisk()" in boot.ini file

Timothy Daniels wrote
Rod Speed wrote


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?


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.


  #9  
Old February 3rd 06, 01:46 AM posted to comp.sys.ibm.pc.hardware.storage
external usenet poster
 
Posts: n/a
Default meaning of "rdisk()" in boot.ini file

"Rod Speed" wrote in message
Timothy Daniels wrote:


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

  #10  
Old February 3rd 06, 02:03 AM posted to comp.sys.ibm.pc.hardware.storage
external usenet poster
 
Posts: n/a
Default meaning of "rdisk()" in boot.ini file

"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*
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
BenQ Dw1620 Dvd burner problem oops Cdr 2 May 20th 05 04:40 AM
aopen cdrw - 'session fixation error'? c p General 0 May 10th 05 08:47 PM
Fixing HDD errors perrin Storage (alternative) 3 March 27th 05 02:17 AM
PartitionMagic Question Harvey Gratt Storage (alternative) 43 February 5th 05 09:20 PM
Help! - The dreaded buffer underrun XPG Cdr 5 August 31st 03 06:27 PM


All times are GMT +1. The time now is 04:44 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.