T
Timothy Daniels
Rod Speed said:
If you don't know where things are in your system,
you shouldn't be using a PC.
*TimDaniels*
If you don't know where things are in your system,
you shouldn't be using a PC.
*TimDaniels*
T
Timothy Daniels
Rod Speed said:
I'm very glad to see that you're now claiming my system
as your own. Anyone reading my experimental results
and reading this thread and the one titled "meaning of
'rdisk()' in boot.ini file" can see that. You're just counting
on the length of this thread to make review of it impractical.
That's just another sock puppet trick.
*TimDaniels*
T
Timothy Daniels
Rod Speed said:
*I* find it very easy to "keep track of that shit".
Alzheimer's is a terrible thing, sock puppet.
*TimDaniels*
T
Timothy Daniels
Rod Speed said:
If by "that test" you mean verifying that the motherboard
controller didn't determine the "rdisk()" value just as the
PCI controller didn't determine the "rdisk()" value, I merely
verified my claim that "rdisk()" was a function of the BIOS,
not the IDE controller. *You* haven't yet verified a thing
except that you're old and don't read much.
*TimDaniels*
R
Rod Speed
Timothy Daniels said:
Like hell they did.
SURE they would, child.
Even you should be able to bullshit better than that pathetic effort.
R
Rod Speed
Still havent managed to do anything about your
problem with premature ejaculations I see.
Wrong, as always.
There isnt necessarily any hard drive boot order list at all, stupid.
Fat lot of good that will do if there is no hard drive boot order list,
****wit.
problem with premature ejaculations I see.
Timothy Daniels said:
Wrong, as always.
There isnt necessarily any hard drive boot order list at all, stupid.
Fat lot of good that will do if there is no hard drive boot order list,
****wit.
R
Rod Speed
Timothy Daniels said:
Pity that aint gotta damned thing to
do with any hard drive boot order list.
Irrelevant to what happens when the *default*
hard drive boot order is changed, cretin.
ONLY with a bios that does the hard drive boot order
that way, and ONLY the order is changed, ****wit.
Completely ****ed way, actually when you have to edit
the boot.ini manually when the hard drive boot order list
is changed. Fat chance of too many ordinary users being
able to do that WHEN DELL DOESNT EVEN MENTION THE
CRUCIAL FACT THAT THE RDISK() PARAM IS ACTUALLY
THE ORDINAL IN THE HARD DRIVE BOOT ORDER LIST.
Makes a hell of a lot more sense to do it the way that MS
says it should be done, 'ordinal for the disk on the adapter'
and that keeps working fine regardless of what the user
does with the entrys in the hard drive boot order list.
Lying, as always. Thats actually the hard
drive boot order list ordinal, ****wit.
Lying, as always. The user is welcome to change the
order in the hard drive boot order list and doesnt need
to open any case, or manually edit the boot.ini either.
So does the old way, ****wit. And doesnt need any
editing of the boot.ini with no documentation what so
ever from Dell that the rdisk() param actually means
the ordinal in the hard drive boot order list.
<reams of juvenile deviate shit flushed where it belongs>
R
Rod Speed
Shit, talk about a rash of premature ejaculations.
You're gunna end up completely blind if you dont watch out, child.
Pity that the only comment on the entrys can be
some crap about physical drives and partitions.
What the user needs is a comment that documents which
particular copy of the OS will be booted by that entry, ****wit.
Its completely ****ed to have the user try to work out what got
installed on each partition on each physical drive in the unlikely
event that a hard drive is no longer bootable by the bios.
Never ever could bullshit its way out of a wet paper bag.
You're gunna end up completely blind if you dont watch out, child.
Timothy Daniels said:
Pity that the only comment on the entrys can be
some crap about physical drives and partitions.
What the user needs is a comment that documents which
particular copy of the OS will be booted by that entry, ****wit.
Its completely ****ed to have the user try to work out what got
installed on each partition on each physical drive in the unlikely
event that a hard drive is no longer bootable by the bios.
Never ever could bullshit its way out of a wet paper bag.
R
Rod Speed
Timothy Daniels said:
Thanks for that completely superfluous proof that
you have never ever had a ****ing clue about how
to setup a system so any user can use it.
The ONLY viable way to the boot.ini is to comment
the individual entrys in a way that is meaningful to
the user, in terms of what particular OS install will
be booted when that particular entry is selected.
Thats just as true with an experienced user who is
very very unlikely indeed to be able to remember
the fine detail of what OS install got installed where
on a collection of drives a long time after that was
done, when a particular drive is no longer bootable
by the bios, ****wit.
R
Rod Speed
Timothy Daniels said:
Never ever could bullshit its way out of a wet paper bag.
Anyone reading that terminally silly shit realises that its completely
****ed for the user to have to know where each OS install is on
the various hard drives before he can actually select the particular
OS install he wants to boot in the unlikely event that the bios can
no longer boot the original hard drive and shit has hit the fan and
the user wants to boot a particular OS install as quickly as possible.
Never ever could bullshit and lie its way out of a wet paper bag.
R
Rod Speed
Timothy Daniels said:
Lying again. In spades when the original drive that was
booted by the bios is no longer bootable and you want
to boot the same OS install that you normally boot of
another drive, or a different drive if the OS install you
normally boot is on a drive that the bios will no longer boot.
R
Rod Speed
Timothy Daniels said:
The test you lied about being 'gibberish' ****wit.
With just one completely ****ed bios implementation,
AFTER you pig ignorantly claimed that the rdisk()
ordinal was ALWAYS the order in the hard drive
boot order list, even when there was no such
animal in the bios. Wota terminal ****wit.
*I* made no claim, I just rubbed your stupid pig ignorant
silly little nose in the FACT that all the MS documentation
says its the ordinal of the drive ON THE CONTROLLER,
and that NOTHING FROM ANYONE EVEN MENTIONS ANY
HARD DRIVE BOOT ORDER LIST with the rdisk() param.
A
Antoine Leca
En news:[email protected], Rod Speed va escriure:
Sure, but I did not write that.
Ntldr does manage resources, and this is precisely why I consider to be a
reduced OS.
Then, it also have a pretty good notion of filesystems, which is why I
compared it to the mythical DOS.
Note it even has plugable drivers, like Ntbootdd.sys.
That's an aside, but I agree with the tendance is to program the whole thing
using (generally) Linux.
Can you dare to elaborate?
Antoine
Sure, but I did not write that.
Ntldr does manage resources, and this is precisely why I consider to be a
reduced OS.
Then, it also have a pretty good notion of filesystems, which is why I
compared it to the mythical DOS.
Note it even has plugable drivers, like Ntbootdd.sys.
That's an aside, but I agree with the tendance is to program the whole thing
using (generally) Linux.
Can you dare to elaborate?
Antoine
R
Rod Speed
Antoine Leca said:
You did however claim that its 'a reduced' DOS.
No it isnt, its just an executable that is file system aware.
No it doesnt. ALL it does is work out what should be booted
based on what is specified in boot.ini and what the user
specifys if there is more than one entry in that and the
user doesnt let it time out to the default entry.
And not everything that manages resources is a
'reduced OS' anyway, plenty of executables do that.
Its nothing like a reduced OS in fact, its just another
boot manager which happens to be file system aware.
It doesnt need that either, just be able to find boot.ini,
work out what partitions etc are on various physical
drives and how to boot a particular partition that the
particular boot.ini entry specifys needs to be booted.
Its nothing like any mythical DOS.
Doesnt make it a reduced OS, plenty
of executables have plugable drivers.
No, its the evidence that just being file system
aware doesnt mean that its a 'reduced' OS.
syslinux has nothing to do with what ntldr does.
A
Antoine Leca
In Rod Speed va escriure:
Sorry for my bad command of English.
I should have explained that there were details in the above part I did not
completely agree with, but it was not worth detailling, so I assumed this
starting position is agreed with.
Problably yes. Like the most part of this thread...
I disagree.
Now *I* ask what is the relevance of this remark with the whole point of the
rdisk() parameter.
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.
Sure, but again I do not see the point w.r.t. rdisk().
The very purpose of Ntldr+Boot.ini, like any boot loader, is to enhance
flexibility, yes.
I disagree: 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.
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"; as I am saying since the first post after
Tim's...
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.
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.
And before you elaborate: if you find a quote of him saying "always", I
would claim he was wrong on this one. 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.
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.
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.
Antoine
Sorry for my bad command of English.
I should have explained that there were details in the above part I did not
completely agree with, but it was not worth detailling, so I assumed this
starting position is agreed with.
Problably yes. Like the most part of this thread...
I disagree.
Now *I* ask what is the relevance of this remark with the whole point of the
rdisk() parameter.
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.
Sure, but again I do not see the point w.r.t. rdisk().
The very purpose of Ntldr+Boot.ini, like any boot loader, is to enhance
flexibility, yes.
I disagree: 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.
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"; as I am saying since the first post after
Tim's...
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.
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.
And before you elaborate: if you find a quote of him saying "always", I
would claim he was wrong on this one. 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.
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.
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.
Antoine
G
Gerhard Fiedler
Rod said:
From http://en.wikipedia.org/wiki/Operating_system:
"The lowest level of any operating system is its kernel, the first layer of
software loaded into computer memory when it starts up. As the first
software layer, all other software that gets loaded after it depends on
this software to provide them with various common core services. These
common core services include, but are not limited to: disk access, memory
management, task scheduling, and access to other hardware devices."
Not really a 100% clear definition, and Wikipedia is possibly not the
ultimate resource on this. But the fact that ntldr never ever gets back
control nor provides any services for the running applications is a pretty
good indication that it is /not/ an OS (or what generally is considered an
OS).
Pretty much at the core of any OS is the ability to run more than one
application (not necessarily concurrently, but at least in sequence) and to
provide these applications with some services while they are running. ntldr
does neither -- once it has done its job (running one single "application")
it completely vanishes from the picture.
Gerhard
A
Antoine Leca
En Timothy Daniels va escriure:
Not that clear to me.
It is pretty obvious to determine how it is really, even if this very
snippet does not explain it.
However, what is not said is how one can adjust it to his own taste.
Und so weiter. In fact, I have a very clear example in my head, with a SCSI
card which is BIOS-enabled; and I am not sure the way it is ultimately
derived is within the realm of the providers, but rather depends on my
fingers and the use I am making of the jumpers at the end of the _three_
disks...
Well, such a carefully studied setup is not exactly common.
Furthermore, the various cheatsheets floating around are not pointing at
this direction, but rather at the Recovery console or ASR or PE or similar
hacks...
Also, if you have such a setup, chances are your backup Windows
configuration (on HD1) is outdated, so I am not sure I like it (say, as
automatic emergency for a unattended server.)
As I pointed out in a different thread, the problem I have with this and
similar ideas is that I am not sure cloning programs are smart enough to
make it working correctly; and shuffling MountedDevices is *not* something I
expect a cloning program to do, at least not until I explicitely order it.
Call me crazy if you want, but in such a case, I'll prefer to spend a bit
more of time and come with a setup which allows the server to boot
automatically (after _any_ disk crash, and also controller crash if I can)
by carefully crafting each and every one of the Boot.ini that could be
involved.
If it is about my own machine, I do not care: I quite probably shall massage
Boot.ini's numerous times before any disk will break (at least, I hope so.
;-))
And my users' machines do not usually have two disks, and when they have,
they do not expect it to work flawlessly after a crash anyway: having two
disks have much more to do with disk space than with security for them.
Antoine
Not that clear to me.
It is pretty obvious to determine how it is really, even if this very
snippet does not explain it.
However, what is not said is how one can adjust it to his own taste.
Und so weiter. In fact, I have a very clear example in my head, with a SCSI
card which is BIOS-enabled; and I am not sure the way it is ultimately
derived is within the realm of the providers, but rather depends on my
fingers and the use I am making of the jumpers at the end of the _three_
disks...
Well, such a carefully studied setup is not exactly common.
Furthermore, the various cheatsheets floating around are not pointing at
this direction, but rather at the Recovery console or ASR or PE or similar
hacks...
Also, if you have such a setup, chances are your backup Windows
configuration (on HD1) is outdated, so I am not sure I like it (say, as
automatic emergency for a unattended server.)
As I pointed out in a different thread, the problem I have with this and
similar ideas is that I am not sure cloning programs are smart enough to
make it working correctly; and shuffling MountedDevices is *not* something I
expect a cloning program to do, at least not until I explicitely order it.
Call me crazy if you want, but in such a case, I'll prefer to spend a bit
more of time and come with a setup which allows the server to boot
automatically (after _any_ disk crash, and also controller crash if I can)
by carefully crafting each and every one of the Boot.ini that could be
involved.
If it is about my own machine, I do not care: I quite probably shall massage
Boot.ini's numerous times before any disk will break (at least, I hope so.
;-))
And my users' machines do not usually have two disks, and when they have,
they do not expect it to work flawlessly after a crash anyway: having two
disks have much more to do with disk space than with security for them.
Antoine
A
Antoine Leca
En news:[email protected], Rod Speed va escriure:
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.
Well, loading NT Executive + its drivers is a somewhat complex task.
Furthermore, Ntldr's mission is to make the ball rolling, so it includes
providing numerous informations at determined places.
One could relatively easily write a loader for DOS; with documentation, it
is yet not very easy to write one for Linux, which is why Lilo was kept that
much time despite requiring an absolutely awkward making process.
I believe nobody except MS and the wizards could write something like Ntldr
(I mean the loading part); as far as I know, ReactOS' FreeLoader is not able
to launch MS Windows, it defers on Ntldr to do that.
I disagree.
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.
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.
Antoine
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.
Well, loading NT Executive + its drivers is a somewhat complex task.
Furthermore, Ntldr's mission is to make the ball rolling, so it includes
providing numerous informations at determined places.
One could relatively easily write a loader for DOS; with documentation, it
is yet not very easy to write one for Linux, which is why Lilo was kept that
much time despite requiring an absolutely awkward making process.
I believe nobody except MS and the wizards could write something like Ntldr
(I mean the loading part); as far as I know, ReactOS' FreeLoader is not able
to launch MS Windows, it defers on Ntldr to do that.
I disagree.
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.
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.
Antoine
A
Antoine Leca
En news:[email protected], Rod Speed va escriure:
Remark: As I said long ago, I do not agree with that claim in general, just
in particular, not common, cases.
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.
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.
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.
Again, the best position is, it varies.
Antoine
Remark: As I said long ago, I do not agree with that claim in general, just
in particular, not common, cases.
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.
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.
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.
Again
, the best position is, it varies.Antoine
R
Rod Speed
Gerhard Fiedler said:
ntldr doesnt qualify, its just a boot manager. And that definition
of an OS glosses over how the OS is loaded. The NT/2K/XP
boot is quite complex and happens before the kernel is loaded.
Thats all nothing to do with what ntldr does.
Yeah, doesnt even mention the detail of how an OS is booted,
particularly a relatively complex boot like the NT/2K/XP boot.
It certainly isnt.
Precisely.
Even the MSDOS boot is file system aware now.
Yep. And the original, the fact that its file system aware is
completely irrelevant to whether its even a 'reduced' OS or
not. Plenty of executables are file system aware, everything
from some imagers to low level disk utes to drivers, etc etc etc.