Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Pre-OS boot benefits
41 views
Skip to first unread message
James Harris
Apr 22, 2012, 3:14:18 PM4/22/12
to
This is a follow up to the thread "Hard disk boot - space for extra
code" which was going into wider issues so am replying here as a
separate thread.
On Apr 19, 9:21 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> "James Harris" <james.harri...@gmail.com> wrote in message
...
> > The goal is to enhance the user experience of the first stage of the
> > hard disk booting process of a common or garden PC.
>
> Why?
Hard to answer without knowing what specifically you are querying. We
all want to make the use of a PC better for users don't we?
> OMG, I'm afraid my replies below are going to make me sound like such a
> "negative nelly" or like I'm bursting your bubble. I'm not, for real.
I believe your comments are genuine. I often find it hard to
understand where your replies are coming from, though. I have tried to
understand why. Sometimes I get the impression that you may not have
taken time to understand a post before replying. Sometimes it seems
that you take phrases in isolation and reply to your own
interpretation of those phrases rather than what they meant in
context. But I guess that's true of all of us, me included and it is
just an impression.
> So, I'll describe what I want from booting, so maybe they won't sound so
> negative. I want the PC to start and put me at a CLI boot prompt, as
> quickly as possible, without any messages or delays or halts. Once I'm at
> the command prompt, I can fix whatever problems might exist if the
> appropriate utilities are available, or reboot to change BIOS settings. If
> it's a GUI or TUI OS, I want a short name to start the GUI or TUI from the
> CLI. Otherwise, the BIOS setup, BIOS messages, BIOS diagnostic screen
> provide all I need. Sometimes, it's useful to be able to have the CLI start
> the TUI or GUI automatically.
I guess you are thinking of the OS starting in a very basic mode. If
that's what you mean, I agree. An option for a basic OS environment
could be very useful but the thread was asking about actions to take
even before the first byte of an OS has been loaded. A pre-OS command
prompt might have some uses but would be very limited, not even having
access to a file system.
> > I'm thinking of a
> > solution that we could deploy on any normal PC - i.e. one which has no
> > special hardware or software and which has a disk with an MBR
> > containing boot code and a traditional four-entry partition table.
>
> > What enhancements?
> > ==================
>
> > So then, what enhancements? Basically to do things like
>
> > * present a specific boot menu
>
> Why?
> - BIOS BBS menu
A BIOS menu is highly restricted, can only give the user choices of
which hard disk to boot from and the user cannot customise it.
> - slows down booting
Waiting for user input would slow down booting, yes, but given what
you say elsewhere are you thinking that displaying a menu would be
slow? There would only be a wait-for-input delay if chosen by a user.
> > * scan available disks looking for bootable partitions and
> > offer a choice of those to the user
>
> Why?
> - BIOS boot order in setup
I'm not sure that all BIOSes allow individual hard disks to be chosen.
Some may only allow a choice of whether to boot from hard disk or not
as if there was only one hard disk in the machine. Besides, the names
the BIOS uses may not mean anything to the user. Maybe we can use
better ones.
> - slows down booting
Hardly. If all disks were powered up at the time the MBR code got
control then, as an example, say there were five boot records (MBR/EBR/
VBR) to read and each took 10ms. Reading them would take a total of
0.05 seconds. That's not what I call slowing down booting.
Besides, if the user *wants* the above behaviour why not provide it?
> > * maintain a timer and take a default option if a
> > certain period elapses before a choice is made
>
> Ok.
LOL! ISTM the one thing that significantly does take time on bootup is
the only one you didn't complain about slowing down booting!
> > * issue meaningful diagnostics if errors occur
>
> Why?
> - good for scared newb's
When you refer to newbs are you thinking of new OS developers? If so I
can see more of where you are coming from with other comments. While
it's good to see things as a developer, in general shouldn't we focus
on how the machine behaves to a person who is not computer literate?
Even for us, existing messages may be of little use. Let's have a
quiz... Here are some messages one might get from an MBR program. What
exactly is each one telling us? I don't know. Much of the time it
would not even be clear which disk, partition table entry or error it
was talking about.
Invalid system disk
Disk I/O error
Replace the disk then press any key
Disk error
Missing operating system
Invalid partition table
Error loading operating system
All are taken from MBR code (not floppy code) found at
http://thestarman.pcministry.com/asm/mbr/
How is a normal PC user supposed to understand what any of those mean
or what to do to fix it???
Better diagnostics would be a boon, IMHO. They would be possible if
there was more boot space and we seem to have established that we can
provide such space. Happy days!
> - good for when a professional OS has a serious crash and restarts
I don't follow. Would pre-OS code be of much help with an OS crash? I
doubt it could even recognise that one had happened.
> - slows down booting
By printing a few messages! How can that possibly impact on boot
speed? No one will notice a few milliseconds difference especially if
something went wrong. Surely this is very worth doing.
> - In general, I don't want. Get me to a prompt where I can fix the issue.
A usable prompt in a pre-OS environment? That sounds a bit hopeful. It
would make the pre-OS code much larger than normal and fail to provide
any access to the OS boot filesystem. Wouldn't it be better if a basic
command prompt was provided by the *OS* instead or at least by the
boot code in the OS partition?
> > * generate informational messages about boot progress
>
> NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> - Sorry, I hate that. Linux does that.
> - slows down booting
I know you hate info messages and I accept that - but you wouldn't
notice any effect a few messages would have on boot speed. I'm not
sure why you think it would. I remember you thought that Windows
writing to a command prompt window was inherently slow but we
discussed that.
> > * provide other pre-OS information to the user
>
> Why?
> - BIOS PC setup screen
Compared with the BIOS a pre-OS environment would have different
scope, different resources, different target and different info that
can be presented to the user - and it would be something we could
control. As above, I'm thinking principally of being helpful to a non-
technical user but messages of this category could be very informative
to us.
I gave, in the initial post, a number of reasons why a pre-OS boot
system would be useful. You don't have to like *all* of them. Any
*one* would make it worth doing.
Since starting this I've come across other reasons such as how poor
(fragile, vulnerable, inflexible, uninformative) existing boot-menu
systems seem to be. All the more reason to consider writing a good
one.
A quick rant.... Can existing boot systems really be as bad as they
seem? Microsoft has an excuse (albeit an impermissible one) of
pretending the rest of the world does not exist. We know that and have
got used to it. I can understand (though not excuse) their approach to
put their boot management inside a Windows partition based on their
philosophy. I feel exasperated that Syslinux, Grub and Lilo apparently
load their second stages from fixed locations - often within a Linux
partition or, if not, from somewhere on the disk that has no
protection. Why can't people separate concepts when they design
things. A person's favourite OS is irrelevant to the choice of OS in a
pre-OS boot process? Why can't the people who design these things
think about how best to boot a PC irrespective of which OS is to be
booted? Why don't they think about what the user might want to do -
e.g. remove a Linux partition without losing the rest of the boot menu
options?
OK, rant over. I know that it's possible I will come across some
technical reason why the two concepts are not separated. I accept
that. I'll try to keep an open mind as to why the designers of these
boot systems did as they did but in the meantime what we have come up
with on this newsgroup seems far better. I am actually hopeful that it
might be possible to leave any old standard MBR code in place and get
control by just flagging the proposed boot partition as bootable. Then
there is no custom MBR to install and for a number of reasons related
to security that would be sweet!
James
code" which was going into wider issues so am replying here as a
separate thread.
On Apr 19, 9:21 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> "James Harris" <james.harri...@gmail.com> wrote in message
...
> > The goal is to enhance the user experience of the first stage of the
> > hard disk booting process of a common or garden PC.
>
> Why?
Hard to answer without knowing what specifically you are querying. We
all want to make the use of a PC better for users don't we?
> OMG, I'm afraid my replies below are going to make me sound like such a
> "negative nelly" or like I'm bursting your bubble. I'm not, for real.
I believe your comments are genuine. I often find it hard to
understand where your replies are coming from, though. I have tried to
understand why. Sometimes I get the impression that you may not have
taken time to understand a post before replying. Sometimes it seems
that you take phrases in isolation and reply to your own
interpretation of those phrases rather than what they meant in
context. But I guess that's true of all of us, me included and it is
just an impression.
> So, I'll describe what I want from booting, so maybe they won't sound so
> negative. I want the PC to start and put me at a CLI boot prompt, as
> quickly as possible, without any messages or delays or halts. Once I'm at
> the command prompt, I can fix whatever problems might exist if the
> appropriate utilities are available, or reboot to change BIOS settings. If
> it's a GUI or TUI OS, I want a short name to start the GUI or TUI from the
> CLI. Otherwise, the BIOS setup, BIOS messages, BIOS diagnostic screen
> provide all I need. Sometimes, it's useful to be able to have the CLI start
> the TUI or GUI automatically.
I guess you are thinking of the OS starting in a very basic mode. If
that's what you mean, I agree. An option for a basic OS environment
could be very useful but the thread was asking about actions to take
even before the first byte of an OS has been loaded. A pre-OS command
prompt might have some uses but would be very limited, not even having
access to a file system.
> > I'm thinking of a
> > solution that we could deploy on any normal PC - i.e. one which has no
> > special hardware or software and which has a disk with an MBR
> > containing boot code and a traditional four-entry partition table.
>
> > What enhancements?
> > ==================
>
> > So then, what enhancements? Basically to do things like
>
> > * present a specific boot menu
>
> Why?
> - BIOS BBS menu
A BIOS menu is highly restricted, can only give the user choices of
which hard disk to boot from and the user cannot customise it.
> - slows down booting
Waiting for user input would slow down booting, yes, but given what
you say elsewhere are you thinking that displaying a menu would be
slow? There would only be a wait-for-input delay if chosen by a user.
> > * scan available disks looking for bootable partitions and
> > offer a choice of those to the user
>
> Why?
> - BIOS boot order in setup
I'm not sure that all BIOSes allow individual hard disks to be chosen.
Some may only allow a choice of whether to boot from hard disk or not
as if there was only one hard disk in the machine. Besides, the names
the BIOS uses may not mean anything to the user. Maybe we can use
better ones.
> - slows down booting
Hardly. If all disks were powered up at the time the MBR code got
control then, as an example, say there were five boot records (MBR/EBR/
VBR) to read and each took 10ms. Reading them would take a total of
0.05 seconds. That's not what I call slowing down booting.
Besides, if the user *wants* the above behaviour why not provide it?
> > * maintain a timer and take a default option if a
> > certain period elapses before a choice is made
>
> Ok.
LOL! ISTM the one thing that significantly does take time on bootup is
the only one you didn't complain about slowing down booting!
> > * issue meaningful diagnostics if errors occur
>
> Why?
> - good for scared newb's
When you refer to newbs are you thinking of new OS developers? If so I
can see more of where you are coming from with other comments. While
it's good to see things as a developer, in general shouldn't we focus
on how the machine behaves to a person who is not computer literate?
Even for us, existing messages may be of little use. Let's have a
quiz... Here are some messages one might get from an MBR program. What
exactly is each one telling us? I don't know. Much of the time it
would not even be clear which disk, partition table entry or error it
was talking about.
Invalid system disk
Disk I/O error
Replace the disk then press any key
Disk error
Missing operating system
Invalid partition table
Error loading operating system
All are taken from MBR code (not floppy code) found at
http://thestarman.pcministry.com/asm/mbr/
How is a normal PC user supposed to understand what any of those mean
or what to do to fix it???
Better diagnostics would be a boon, IMHO. They would be possible if
there was more boot space and we seem to have established that we can
provide such space. Happy days!
> - good for when a professional OS has a serious crash and restarts
I don't follow. Would pre-OS code be of much help with an OS crash? I
doubt it could even recognise that one had happened.
> - slows down booting
By printing a few messages! How can that possibly impact on boot
speed? No one will notice a few milliseconds difference especially if
something went wrong. Surely this is very worth doing.
> - In general, I don't want. Get me to a prompt where I can fix the issue.
A usable prompt in a pre-OS environment? That sounds a bit hopeful. It
would make the pre-OS code much larger than normal and fail to provide
any access to the OS boot filesystem. Wouldn't it be better if a basic
command prompt was provided by the *OS* instead or at least by the
boot code in the OS partition?
> > * generate informational messages about boot progress
>
> NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> - Sorry, I hate that. Linux does that.
> - slows down booting
I know you hate info messages and I accept that - but you wouldn't
notice any effect a few messages would have on boot speed. I'm not
sure why you think it would. I remember you thought that Windows
writing to a command prompt window was inherently slow but we
discussed that.
> > * provide other pre-OS information to the user
>
> Why?
> - BIOS PC setup screen
Compared with the BIOS a pre-OS environment would have different
scope, different resources, different target and different info that
can be presented to the user - and it would be something we could
control. As above, I'm thinking principally of being helpful to a non-
technical user but messages of this category could be very informative
to us.
I gave, in the initial post, a number of reasons why a pre-OS boot
system would be useful. You don't have to like *all* of them. Any
*one* would make it worth doing.
Since starting this I've come across other reasons such as how poor
(fragile, vulnerable, inflexible, uninformative) existing boot-menu
systems seem to be. All the more reason to consider writing a good
one.
A quick rant.... Can existing boot systems really be as bad as they
seem? Microsoft has an excuse (albeit an impermissible one) of
pretending the rest of the world does not exist. We know that and have
got used to it. I can understand (though not excuse) their approach to
put their boot management inside a Windows partition based on their
philosophy. I feel exasperated that Syslinux, Grub and Lilo apparently
load their second stages from fixed locations - often within a Linux
partition or, if not, from somewhere on the disk that has no
protection. Why can't people separate concepts when they design
things. A person's favourite OS is irrelevant to the choice of OS in a
pre-OS boot process? Why can't the people who design these things
think about how best to boot a PC irrespective of which OS is to be
booted? Why don't they think about what the user might want to do -
e.g. remove a Linux partition without losing the rest of the boot menu
options?
OK, rant over. I know that it's possible I will come across some
technical reason why the two concepts are not separated. I accept
that. I'll try to keep an open mind as to why the designers of these
boot systems did as they did but in the meantime what we have come up
with on this newsgroup seems far better. I am actually hopeful that it
might be possible to leave any old standard MBR code in place and get
control by just flagging the proposed boot partition as bootable. Then
there is no custom MBR to install and for a number of reasons related
to security that would be sweet!
James
Rod Pemberton
Apr 22, 2012, 8:32:00 PM4/22/12
to
"James Harris" <james.h...@gmail.com> wrote in message
news:c280e519-b2d2-4fb3...@e42g2000yqa.googlegroups.com...
> On Apr 19, 9:21 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
> > "James Harris" <james.harri...@gmail.com> wrote in message
...
> > > The goal is to enhance the user experience of the first stage of the
> > > hard disk booting process of a common or garden PC.
> >
> > Why?
>
> Hard to answer without knowing what specifically you are querying.
In the other thread, I described what I wanted from booting. One way to
look at my description is that most of it comprised of *not enhancing* the
so called "user experience". If I'm like many others then, why would I want
an enhanced user experience during booting?
> We all want to make the use of a PC better for users don't we?
No. What users?
My (stalled) OS is light-years away from having any users (excluding me, of
course). Don't you need to get an OS written first before considering
users? Don't you need to get an OS written first before considering the OS'
impact upon users? etc. I.e., there are a number of good bootloaders out
there, so creating a phenomenal one before writing your OS seems like
putting the "cart first, horse after."
And,
No. I'm not sure I want users. Users will put me through hell.
> > > So then, what enhancements? Basically to do things like
> >
> > > * present a specific boot menu
> >
> > Why?
> > - BIOS BBS menu
>
> A BIOS menu is highly restricted, can only give the user choices of
> which hard disk to boot from and the user cannot customise it.
What needs to be customized?
Why would providing the user choices of which hard disk to boot from be
insufficient?
> > - slows down booting
>
> Waiting for user input would slow down booting, yes, but given what
> you say elsewhere are you thinking that displaying a menu would be
> slow? There would only be a wait-for-input delay if chosen by a user.
Yes. All console I/O is slow. And, I don't like text output during boot.
> > > * scan available disks looking for bootable partitions and
> > > offer a choice of those to the user
> >
> > Why?
> > - BIOS boot order in setup
>
> I'm not sure that all BIOSes allow individual hard disks to be chosen.
Of course not, the BIOS allows you to select device(s) to *not* boot also.
Wouldn't it be a security violation if your bootloader could boot devices
specifically set to not boot? I think it would. But, I'm guessing as to
your meaning here too, so maybe you meant to enhance an obsolete BIOS by
allowing it to boot other devices it doesn't recognize? You understand that
the bootloader would have to provide drivers for that other device, yes?
> Some may only allow a choice of whether to boot from hard disk or not
> as if there was only one hard disk in the machine.
So? Unplug, reconfigure, reboot, etc. It's only an issue if you don't own
the device in question, or are lazy about reconfiguring it, or creating
some type of forensic recovery software. Yes? No?
> Besides, the names the BIOS uses may not mean anything to the user.
> Maybe we can use better ones.
What ... ? Are you saying the device id string that BIOS reads and displays
isn't useful? Or, are you saying that you like Linux (etc) device names
better than _____ (something else)?
> > > * maintain a timer and take a default option if a
> > > certain period elapses before a choice is made
> >
> > Ok.
>
> LOL! ISTM the one thing that significantly does take time on
> bootup is the only one you didn't complain about slowing
> down booting!
It was too overwhelming at that point ... lol. ;)
If you're going to use a menu, then a timer doesn't make the situation any
worse. It can actually improve it, by shortening the delay, i.e., zero.
Hopefully, zero makes the menu go away too ...
> > > * issue meaningful diagnostics if errors occur
> >
> > Why?
> > - good for scared newb's
>
> When you refer to newbs are you thinking of new OS developers?
No, I'm thinking of novice OS users. They do stuff "no one" - i.e., those
who are computer literate or even semi-computer literate - would ever
expect, anyone to do.
Not to pry into your private life, but do you have elderly parents who use
computers? (no need to answer) I do. It's a nightmare, even with them
using a professional, high-quality, comercial OS like Windows.
Do you know how freaked out my parents get when they get a blue screen of
death (BSOD) with Windows? Do you know how freaked out they get when
resume mode doesn't resume leaving them with a black screen of death (BlSOD)
with Windows? My dad has managed the to get the BlSOD a few times now.
My mother has managed to get the BSOD screen too many times to count.
Fortunately, more recent Windows is less BSOD happy. Here is a basic
summary:
Dad: BlSOD: few Windows 7, 64-bit, Samsung laptop
Mom: BSOD: few Windows 7, 64-bit, Dell PC
Mom: BSOD: few Windows Vista, 32-bit, Dell PC
Mom: BSOD: numerous Windows XP/XPsp1/XPsp2/XPsp3, 32-bit, Dell laptop
Notice that that's not on Windows 98 or SE or ME. That's on MS' current top
of the line, line up. The Samsung is only four months old.
Linux with it's dark corners is too scary for me to contemplate them ever
using, even if it is 100% free.
I don't know if you recall, but I mentioned one issue I found was that my
mother, i.e., "novice user", was using filenames as a notepad, e.g., grocery
lists, to do lists, massively long descriptions, etc. Once the filenames
were more than 1024 characters in length, the Windows filesystem *failed* to
link the filename and file together. She starting asking why her files were
disappearing. That was with WinXP. Windows provide no warning that the
maximum file length was being exceeded. No joke.
The other BSODs she had seemed to have some correlation with her not waiting
for Windows to do things, i.e., repeatedly tapping the mouse pad. She
didn't understand that you have to wait for Windows to finish loading before
you use it or it crashes, i.e., starting to use Windows once the desktop
appears but before all those system tray icons are loaded. She didn't
understand that if Windows is doing something, i.e., lots of disk access,
that interrupting it will crash it. She didn't know that you have to wait
until Windows is finished writing to CDs or USBs to eject or unplug them,
i.e., corrupted copies. None of that is something we would likely ever do.
> If so I can see more of where you are coming from with other comments.
Uh ...
> While it's good to see things as a developer, in general shouldn't we
> focus on how the machine behaves to a person who is not computer literate?
Yes. A computer illiterate person doesn't know what he or she is seeing on
the screen anyway, so why do they need a more informative boot process?
Did you mean someone semi-literate?
> Even for us, existing messages may be of little use. Let's have a
> quiz... Here are some messages one might get from an MBR program. What
> exactly is each one telling us? I don't know. Much of the time it
> would not even be clear which disk, partition table entry or error it
> was talking about.
>
> Invalid system disk
> Disk I/O error
> Replace the disk then press any key
> Disk error
> Missing operating system
> Invalid partition table
> Error loading operating system
>
> All are taken from MBR code (not floppy code) found at
>
> [link]
>
Well, I know what those mean. I've also seen most of them at some point in
time. But, other than "Missing operating system" or "Invalid system disk",
and "Replace the disk then press any key", you won't see them too often.
> How is a normal PC user supposed to understand what any of those mean
> or what to do to fix it???
Like I said, there is no point in informing someone who doesn't understand.
They still won't understand when you inform them. They've got no context.
They don't know what an MBR, VBR, bootloader, etc are. So, for "Missing
operating system", you can tell them to install an OS all day long and it
won't mean much to them. "What do you mean by 'install'?" "What's an OS?"
...
> Better diagnostics would be a boon, IMHO. They would be possible if
> there was more boot space and we seem to have established that we can
> provide such space. Happy days!
Ok, quiz. What would be better "diagnostics" for "Error loading operating
system" or "Invalid system disk"?
> > - good for when a professional OS has a serious crash and restarts
>
> I don't follow. Would pre-OS code be of much help with an OS crash? I
> doubt it could even recognise that one had happened.
You only need to write a flag to disk. If the flag doesn't have the correct
value upon reboot, then a crash or shutdown failure occured. If numerous
values were written at various stages of shutdown or booting, then even more
specific messages could be provided. E.g., "Failure transferring execution
from 1st stage bootloader to 2nd stage bootloader." Etc.
> > - slows down booting
>
> By printing a few messages! How can that possibly impact on boot
> speed? No one will notice a few milliseconds difference especially if
> something went wrong. Surely this is very worth doing.
>
Ok, you're just thinking about your menu.
Have you seen a recent Linux boot? Once past the BIOS screens, DOS takes
about 1 second, if that. Windows 98 takes about 10 seconds. Linux scrolls
a vast volume of text, then stalls for module loadings, etc. It takes about
5 minutes. That's with a current high speed BSD based distro's like Vector
Linux. 85% of that load time is due *purely* to the slowness of console
I/O.
> > - In general, I don't want. Get me to a prompt where I can fix the
> > issue.
>
> A usable prompt in a pre-OS environment? That sounds a bit hopeful.
No, get me to the OS prompt. I don't want to see the pre-OS environment at
all, ever.
> I gave, in the initial post, a number of reasons why a pre-OS boot
> system would be useful. You don't have to like *all* of them. Any
> *one* would make it worth doing.
See last comment above.
> Since starting this I've come across other reasons such as how poor
> (fragile, vulnerable, inflexible, uninformative) existing boot-menu
> systems seem to be. All the more reason to consider writing a good
> one.
If you're not going to start from scratch, wouldn't it be better use of time
to take a good one and make it phenomenal?
> A quick rant.... Can existing boot systems really be as bad as they
> seem?
Of course, they can. What is good enough is rarely ever made great.
> Microsoft has an excuse (albeit an impermissible one) of
> pretending the rest of the world does not exist.
It's both an issue of security and market control for them. Their OS can't
be secure if someone can modify the boot sequence, and blocking out
competitors gives them monopoly power.
> I can understand (though not excuse) their approach to
> put their boot management inside a Windows partition based on their
> philosophy.
I don't see an issue with storing stuff in a partition.
> I feel exasperated that Syslinux, Grub and Lilo apparently
> load their second stages from fixed locations - often within a Linux
> partition or, if not, from somewhere on the disk that has no
> protection.
You've mentioned this a few times now. Why?
> Why can't people separate concepts when they design things.
Market control, limited foresight, history - that's the way it's always been
done, pick one of those as an answer or something else ...
So, you're saying that GM, Ford, Chrysler, and Toyota should have more
interchangeable parts than just tires? You can't use GM parts with Fords
and vice-versa, except tires, an industry which the automotive companies
left to tire manufacturers. For production vehicles, an alternator is an
alternator. Some are more powerful. Some require specific circuitry etc.
But, basically, if the automotive manufacturers hadn't been in the business
of manufacturing their own alternators, then we wouldn't have dozens of
alternator designs from each company which only work on specific product
lines. If tires had been manufactured by the auto companies, tires wouldn't
fit other vehicles either. Ditto for windows, doors, seats, lights,
exhausts, engine parts, transmissions. Radio's might be interchangeable
too.
> A person's favourite OS is irrelevant to the choice of OS in a
> pre-OS boot process?
Not historically ...
> Why can't the people who design these things think about how best
> to boot a PC irrespective of which OS is to be booted?
Not enough demand, complexity, market control, limited foresight, history -
that's the way it's always been done, pick one of those as an answer or
something else ...
> Why don't they think about what the user might want to do -
> e.g. remove a Linux partition without losing the rest of the
> boot menu options?
They do, but, in the context of users using the OS, not OS setup,
installation, or modification.
Rod Pemberton
news:c280e519-b2d2-4fb3...@e42g2000yqa.googlegroups.com...
> This is a follow up to the thread "Hard disk boot - space for extra
> code" which was going into wider issues so am replying here as a
> separate thread.
...
> code" which was going into wider issues so am replying here as a
> separate thread.
> On Apr 19, 9:21 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
> > "James Harris" <james.harri...@gmail.com> wrote in message
...
> > > The goal is to enhance the user experience of the first stage of the
> > > hard disk booting process of a common or garden PC.
> >
> > Why?
>
> Hard to answer without knowing what specifically you are querying.
look at my description is that most of it comprised of *not enhancing* the
so called "user experience". If I'm like many others then, why would I want
an enhanced user experience during booting?
> We all want to make the use of a PC better for users don't we?
My (stalled) OS is light-years away from having any users (excluding me, of
course). Don't you need to get an OS written first before considering
users? Don't you need to get an OS written first before considering the OS'
impact upon users? etc. I.e., there are a number of good bootloaders out
there, so creating a phenomenal one before writing your OS seems like
putting the "cart first, horse after."
And,
No. I'm not sure I want users. Users will put me through hell.
> > > So then, what enhancements? Basically to do things like
> >
> > > * present a specific boot menu
> >
> > Why?
> > - BIOS BBS menu
>
> A BIOS menu is highly restricted, can only give the user choices of
> which hard disk to boot from and the user cannot customise it.
Why would providing the user choices of which hard disk to boot from be
insufficient?
> > - slows down booting
>
> Waiting for user input would slow down booting, yes, but given what
> you say elsewhere are you thinking that displaying a menu would be
> slow? There would only be a wait-for-input delay if chosen by a user.
> > > * scan available disks looking for bootable partitions and
> > > offer a choice of those to the user
> >
> > Why?
> > - BIOS boot order in setup
>
> I'm not sure that all BIOSes allow individual hard disks to be chosen.
Wouldn't it be a security violation if your bootloader could boot devices
specifically set to not boot? I think it would. But, I'm guessing as to
your meaning here too, so maybe you meant to enhance an obsolete BIOS by
allowing it to boot other devices it doesn't recognize? You understand that
the bootloader would have to provide drivers for that other device, yes?
> Some may only allow a choice of whether to boot from hard disk or not
> as if there was only one hard disk in the machine.
the device in question, or are lazy about reconfiguring it, or creating
some type of forensic recovery software. Yes? No?
> Besides, the names the BIOS uses may not mean anything to the user.
> Maybe we can use better ones.
isn't useful? Or, are you saying that you like Linux (etc) device names
better than _____ (something else)?
> > > * maintain a timer and take a default option if a
> > > certain period elapses before a choice is made
> >
> > Ok.
>
> LOL! ISTM the one thing that significantly does take time on
> bootup is the only one you didn't complain about slowing
> down booting!
If you're going to use a menu, then a timer doesn't make the situation any
worse. It can actually improve it, by shortening the delay, i.e., zero.
Hopefully, zero makes the menu go away too ...
> > > * issue meaningful diagnostics if errors occur
> >
> > Why?
> > - good for scared newb's
>
> When you refer to newbs are you thinking of new OS developers?
who are computer literate or even semi-computer literate - would ever
expect, anyone to do.
Not to pry into your private life, but do you have elderly parents who use
computers? (no need to answer) I do. It's a nightmare, even with them
using a professional, high-quality, comercial OS like Windows.
Do you know how freaked out my parents get when they get a blue screen of
death (BSOD) with Windows? Do you know how freaked out they get when
resume mode doesn't resume leaving them with a black screen of death (BlSOD)
with Windows? My dad has managed the to get the BlSOD a few times now.
My mother has managed to get the BSOD screen too many times to count.
Fortunately, more recent Windows is less BSOD happy. Here is a basic
summary:
Dad: BlSOD: few Windows 7, 64-bit, Samsung laptop
Mom: BSOD: few Windows 7, 64-bit, Dell PC
Mom: BSOD: few Windows Vista, 32-bit, Dell PC
Mom: BSOD: numerous Windows XP/XPsp1/XPsp2/XPsp3, 32-bit, Dell laptop
Notice that that's not on Windows 98 or SE or ME. That's on MS' current top
of the line, line up. The Samsung is only four months old.
Linux with it's dark corners is too scary for me to contemplate them ever
using, even if it is 100% free.
I don't know if you recall, but I mentioned one issue I found was that my
mother, i.e., "novice user", was using filenames as a notepad, e.g., grocery
lists, to do lists, massively long descriptions, etc. Once the filenames
were more than 1024 characters in length, the Windows filesystem *failed* to
link the filename and file together. She starting asking why her files were
disappearing. That was with WinXP. Windows provide no warning that the
maximum file length was being exceeded. No joke.
The other BSODs she had seemed to have some correlation with her not waiting
for Windows to do things, i.e., repeatedly tapping the mouse pad. She
didn't understand that you have to wait for Windows to finish loading before
you use it or it crashes, i.e., starting to use Windows once the desktop
appears but before all those system tray icons are loaded. She didn't
understand that if Windows is doing something, i.e., lots of disk access,
that interrupting it will crash it. She didn't know that you have to wait
until Windows is finished writing to CDs or USBs to eject or unplug them,
i.e., corrupted copies. None of that is something we would likely ever do.
> If so I can see more of where you are coming from with other comments.
> While it's good to see things as a developer, in general shouldn't we
> focus on how the machine behaves to a person who is not computer literate?
the screen anyway, so why do they need a more informative boot process?
Did you mean someone semi-literate?
> Even for us, existing messages may be of little use. Let's have a
> quiz... Here are some messages one might get from an MBR program. What
> exactly is each one telling us? I don't know. Much of the time it
> would not even be clear which disk, partition table entry or error it
> was talking about.
>
> Invalid system disk
> Disk I/O error
> Replace the disk then press any key
> Disk error
> Missing operating system
> Invalid partition table
> Error loading operating system
>
> All are taken from MBR code (not floppy code) found at
>
>
Well, I know what those mean. I've also seen most of them at some point in
time. But, other than "Missing operating system" or "Invalid system disk",
and "Replace the disk then press any key", you won't see them too often.
> How is a normal PC user supposed to understand what any of those mean
> or what to do to fix it???
They still won't understand when you inform them. They've got no context.
They don't know what an MBR, VBR, bootloader, etc are. So, for "Missing
operating system", you can tell them to install an OS all day long and it
won't mean much to them. "What do you mean by 'install'?" "What's an OS?"
...
> Better diagnostics would be a boon, IMHO. They would be possible if
> there was more boot space and we seem to have established that we can
> provide such space. Happy days!
system" or "Invalid system disk"?
> > - good for when a professional OS has a serious crash and restarts
>
> I don't follow. Would pre-OS code be of much help with an OS crash? I
> doubt it could even recognise that one had happened.
value upon reboot, then a crash or shutdown failure occured. If numerous
values were written at various stages of shutdown or booting, then even more
specific messages could be provided. E.g., "Failure transferring execution
from 1st stage bootloader to 2nd stage bootloader." Etc.
> > - slows down booting
>
> By printing a few messages! How can that possibly impact on boot
> speed? No one will notice a few milliseconds difference especially if
> something went wrong. Surely this is very worth doing.
>
Have you seen a recent Linux boot? Once past the BIOS screens, DOS takes
about 1 second, if that. Windows 98 takes about 10 seconds. Linux scrolls
a vast volume of text, then stalls for module loadings, etc. It takes about
5 minutes. That's with a current high speed BSD based distro's like Vector
Linux. 85% of that load time is due *purely* to the slowness of console
I/O.
> > - In general, I don't want. Get me to a prompt where I can fix the
> > issue.
>
> A usable prompt in a pre-OS environment? That sounds a bit hopeful.
all, ever.
> I gave, in the initial post, a number of reasons why a pre-OS boot
> system would be useful. You don't have to like *all* of them. Any
> *one* would make it worth doing.
> Since starting this I've come across other reasons such as how poor
> (fragile, vulnerable, inflexible, uninformative) existing boot-menu
> systems seem to be. All the more reason to consider writing a good
> one.
to take a good one and make it phenomenal?
> A quick rant.... Can existing boot systems really be as bad as they
> seem?
> Microsoft has an excuse (albeit an impermissible one) of
> pretending the rest of the world does not exist.
be secure if someone can modify the boot sequence, and blocking out
competitors gives them monopoly power.
> I can understand (though not excuse) their approach to
> put their boot management inside a Windows partition based on their
> philosophy.
> I feel exasperated that Syslinux, Grub and Lilo apparently
> load their second stages from fixed locations - often within a Linux
> partition or, if not, from somewhere on the disk that has no
> protection.
> Why can't people separate concepts when they design things.
done, pick one of those as an answer or something else ...
So, you're saying that GM, Ford, Chrysler, and Toyota should have more
interchangeable parts than just tires? You can't use GM parts with Fords
and vice-versa, except tires, an industry which the automotive companies
left to tire manufacturers. For production vehicles, an alternator is an
alternator. Some are more powerful. Some require specific circuitry etc.
But, basically, if the automotive manufacturers hadn't been in the business
of manufacturing their own alternators, then we wouldn't have dozens of
alternator designs from each company which only work on specific product
lines. If tires had been manufactured by the auto companies, tires wouldn't
fit other vehicles either. Ditto for windows, doors, seats, lights,
exhausts, engine parts, transmissions. Radio's might be interchangeable
too.
> A person's favourite OS is irrelevant to the choice of OS in a
> pre-OS boot process?
> Why can't the people who design these things think about how best
> to boot a PC irrespective of which OS is to be booted?
that's the way it's always been done, pick one of those as an answer or
something else ...
> Why don't they think about what the user might want to do -
> e.g. remove a Linux partition without losing the rest of the
> boot menu options?
installation, or modification.
Rod Pemberton
wolfgang kern
Apr 23, 2012, 5:48:32 AM4/23/12
to
James in discussion with Rod:
> This is a follow up to the thread "Hard disk boot - space for extra
> code" which was going into wider issues so am replying here as a
> separate thread.
Pre-OS-boot? You see me a bit confused now :)
You sure mean the load process.
Of course it may need two steps to fully load an OS.
1. MBR-code can only load and execute a few sectors to low memory
2. this piece of code may then do all run-once stuff and finally
load and run PM above 1.MB.
If the question is about where to store this "OS-loader" then it
may depend on its size and functionalty.
A single sector will not be enough to hold GDT/IDT, exception-handlers
and IRQ-reponders beside all required HD-routines.
So I'd put this loader (mine is ~32KB large) to the very start of a
volume, even not accessible by the FS (ie: before any FAT/MFT$/...).
I see no reason for distributing the job over several sectors
(MBR>EBR>VBR) except for M$ or Linux styled boot. Or do you have
problems to merge the first-step loader into the MBR ?
In opposition to M$'s apart aproach methink the MBR can already
contain all information about the actual active FS.
Even this would loose the ?convenient? single active bit setting.
Altering an MBR usually need full sector read/modify/write anyway.
For machines delivered with my OS I got two MBR-variants:
KESYS.SAFE
doesn't have partitions at all and all FS-info is already stored
within the MBR, so it dont need an VBR in addition to load and start.
and KESYS.OPEN
this MBR got a partition-table which may use all four entries,
it could even look like:
1. DOS_FAT
2. windoze_NTFS
3. Loonix
4. Extended
and you may now ask: "where is the KESYS-partition ?"
answer: same as in KESYS.SAFE !
and it could be well on the very last sectors of a 2TB HD.
as said above, the startup code may load a few sectors below 1.MB,but
here all PRE-OS-START-code can take place (0.2 seconds incl. msg-text)
like hardware detection checks and creating partition-tree info,etc..
and then it may (if configured that way) show a boot-selection menu
to start KESYS or any other installed OS.
GDT/IDT/IVT, PM32 setup, mounting drives and volumes, etc.. are also
mainly 'run-once' and may be seen as pre-OS start, but just done and
kept before the OS deploys itself by loading all desired code modules.
__
wolfgang
Antoine Leca
Apr 26, 2012, 7:09:20 AM4/26/12
to
James Harris wrote:
> This is a follow up to the thread "Hard disk boot - space for extra
> code" which was going into wider issues so am replying here as a
> separate thread.
>
> On Apr 19, 9:21 pm, Rod Pemberton wrote:
> This is a follow up to the thread "Hard disk boot - space for extra
> code" which was going into wider issues so am replying here as a
> separate thread.
>
>> James Harris wrote in message
>>> What enhancements?
>>> ==================
>>
>>> So then, what enhancements? Basically to do things like
>>
<snip>
>>> ==================
>>
>>> So then, what enhancements? Basically to do things like
>>
>>> * scan available disks looking for bootable partitions and
>>> offer a choice of those to the user
>>
>> Why?
>> - BIOS boot order in setup
>
> I'm not sure that all BIOSes allow individual hard disks to be chosen.
True.
>>> offer a choice of those to the user
>>
>> Why?
>> - BIOS boot order in setup
>
> I'm not sure that all BIOSes allow individual hard disks to be chosen.
> Some may only allow a choice of whether to boot from hard disk or not
> as if there was only one hard disk in the machine.
cast it into stone around 1993 (and that we can see with the BBS "IPL
table"). In this model, among the BAIDs (BIOS-aware IPL devices, which
are using BIOS-provided INT13h to bootstrap) there is only one fixed
disk allowed as booting medium, and that disk gets the number 80h. If
you happen to have several fixed disks, they are not considered allowed
as IPL devices (under the BBS):
Note that only the first floppy drive and the first hard
drive are considered IPL devices. The main reason why a
system cannot boot from other drives is that the boot
sector code specifically addresses only these drives
(00h for floppy and 80h for hard drive) when INT 13h is
called to load the O/S.
The result of that specification, is that BIOSes are forced to maintain
a two-level hierarchy (and consequently menus), with the first list
having all the IPL devices (e.g. floppy, primary (IDE/SATA) hard disk,
primary CD-ROM, primary USB-HD, and other BEVs like PXE cards); and at
second level, potentially several sublists within each category to
determine which among the drives is the "primary" (in practical terms
though, those sublists exist for IDE/SATA drives only.)
> Besides, the names the BIOS uses may not mean anything to the user.
> Maybe we can use better ones.
as seen within the final OS (what the real user sees) is often not
trivial, and sometimes impossible (as in cases of logical volume
management.)
>> - slows down booting
>
> Hardly.
_only_ the booting one is the only change involved in those new
"FastBoot" BIOSes, then having access to all the devices probably slows
down booting.
> If all disks were powered up at the time the MBR code got
> control then, as an example, say there were five boot records (MBR/EBR/
> VBR) to read and each took 10ms.
to be powered up and rotating, there are also the time needed for each
of the intermediary electronic devices in between to finish their
"reset" cycles. And if in between you have a RAID controller which
checks all of its 256MB of cache memory as part of its reset, or an USB
root arbitrator which resets the whole USB bus, it certainly will last
more than a few milliseconds.
<snip>
> Since starting this I've come across other reasons such as how poor
> (fragile, vulnerable, inflexible, uninformative) existing boot-menu
> systems seem to be. All the more reason to consider writing a good
> one.
>
> A quick rant.... Can existing boot systems really be as bad as they
> seem? Microsoft has an excuse (albeit an impermissible one) of
> pretending the rest of the world does not exist.
I do not consider the (NT6) "pre-boot environment" to be either of
> (fragile, vulnerable, inflexible, uninformative) existing boot-menu
> systems seem to be. All the more reason to consider writing a good
> one.
>
> A quick rant.... Can existing boot systems really be as bad as they
> seem? Microsoft has an excuse (albeit an impermissible one) of
> pretending the rest of the world does not exist.
- fragile
- inflexible
- uninformative (look at the debugging options)
About vulnerability, it certainly is, but at the same time it also is
much less vulnerable than any of its predecessors, particularly when TPM
and full disk encryption are used.
> We know that and have
> got used to it. I can understand (though not excuse) their approach to
> put their boot management inside a Windows partition based on their
> philosophy. I feel exasperated that Syslinux, Grub and Lilo apparently
> load their second stages from fixed locations - often within a Linux
> partition or, if not, from somewhere on the disk that has no
> protection.
Can you elaborate? Protected from who? Why?
The very purpose of Syslinux is to load Linux from a FAT partition: no
more, no less. Of course, the resulting 2nd stage cannot be in a
"protected area of the disk", since it has to be in the root of a FAT
volume; BTW, the only "fixed location" of it is its name, LDLINUX.SYS
OTOH GRUB is very much the jack of all trades (and it does look like an
OS in reduction, and growing/bloating.) While it can load Linux form a
fixed location inside a Linux volume, like --and because-- LILO does, it
can also do a lot of other things, like in GRUB4NT variants directly
loading the Windows kernel dynamically from a Windows volume...
Antoine
Harry Vaderchi
Apr 26, 2012, 3:44:59 PM4/26/12
to
On Mon, 23 Apr 2012 01:32:00 +0100, Rod Pemberton
<do_no...@notemailnot.cmm> wrote:
{tidied up]
> Have you seen a recent Linux boot? Once past the BIOS screens, DOS takes
> about 1 second, if that. Windows 98 takes about 10 seconds. Linux
> scrolls
> a vast volume of text, then stalls for module loadings, etc. It takes
> about
> 5 minutes. That's with a current high speed BSD based distro's like
> Vector
> Linux. 85% of that load time is due *purely* to the slowness of console
> I/O.
I have boot times for Puppy of 30s and xPud of 10s on an eee 701.
You have a slow PC, booting from slow media, lack memory, or a strange
linux (even the "light" edition of Vector Linux is 640M!)
[more removed]
you're line length would be nicer if it was set at 72
>
>
> Rod Pemberton
>
>
>
>
--
[dash dash space newline 4line sig]
Albi CNU
<do_no...@notemailnot.cmm> wrote:
{tidied up]
> Have you seen a recent Linux boot? Once past the BIOS screens, DOS takes
> about 1 second, if that. Windows 98 takes about 10 seconds. Linux
> scrolls
> a vast volume of text, then stalls for module loadings, etc. It takes
> about
> 5 minutes. That's with a current high speed BSD based distro's like
> Vector
> Linux. 85% of that load time is due *purely* to the slowness of console
> I/O.
You have a slow PC, booting from slow media, lack memory, or a strange
linux (even the "light" edition of Vector Linux is 640M!)
[more removed]
you're line length would be nicer if it was set at 72
>
>
> Rod Pemberton
>
>
>
>
--
[dash dash space newline 4line sig]
Albi CNU
James Harris
Apr 28, 2012, 4:19:48 AM4/28/12
to
On Apr 23, 10:48 am, "wolfgang kern" <nowh...@never.at> wrote:
> James in discussion with Rod:
>
> > This is a follow up to the thread "Hard disk boot - space for extra
> > code" which was going into wider issues so am replying here as a
> > separate thread.
>
> ...
>
> Pre-OS-boot? You see me a bit confused now :)
> You sure mean the load process.
Yes, in a way but just a small part of the load process. By Pre-OS I
> James in discussion with Rod:
>
> > This is a follow up to the thread "Hard disk boot - space for extra
> > code" which was going into wider issues so am replying here as a
> > separate thread.
>
> ...
>
> Pre-OS-boot? You see me a bit confused now :)
> You sure mean the load process.
mean just that which starts with the MBR and comes before starting
anything from the partition which contains the OS. Probably Pre-OS
would be more accurately stated as "code that runs before running code
from the OS partition" but that's a bit of a mouthful!
> Of course it may need two steps to fully load an OS.
> 1. MBR-code can only load and execute a few sectors to low memory
> 2. this piece of code may then do all run-once stuff and finally
> load and run PM above 1.MB.
smaller steps. I'd like the MBR to ultimately load nothing more than
one VBR though it may take various actions to find out which VBR to
load. And I'd like there to be enough code space that I can issue
meaningful diagnostics if it finds anything wrong with what it has
been told to load.
I've not looked at what the VBR should do in much detail yet but it
would have to load some more extensive code from within its own
partition. Maybe the code it loads would be what you call the run-once
stuff or, below, the OS-loader.
>
> If the question is about where to store this "OS-loader" then it
> may depend on its size and functionalty.
> A single sector will not be enough to hold GDT/IDT, exception-handlers
> and IRQ-reponders beside all required HD-routines.
> So I'd put this loader (mine is ~32KB large) to the very start of a
> volume, even not accessible by the FS (ie: before any FAT/MFT$/...).
the beginning of the partition though I think it is just 1024 bytes.
Maybe other file systems also make provision for some code to run
before anything has to walk the file system.
> I see no reason for distributing the job over several sectors
> (MBR>EBR>VBR) except for M$ or Linux styled boot. Or do you have
> problems to merge the first-step loader into the MBR ?
like it to do).
> In opposition to M$'s apart aproach methink the MBR can already
> contain all information about the actual active FS.
> Even this would loose the ?convenient? single active bit setting.
> Altering an MBR usually need full sector read/modify/write anyway.
>
> For machines delivered with my OS I got two MBR-variants:
>
> KESYS.SAFE
> doesn't have partitions at all and all FS-info is already stored
> within the MBR, so it dont need an VBR in addition to load and start.
>
> and KESYS.OPEN
> this MBR got a partition-table which may use all four entries,
> it could even look like:
> 1. DOS_FAT
> 2. windoze_NTFS
> 3. Loonix
> 4. Extended
>
> and you may now ask: "where is the KESYS-partition ?"
> answer: same as in KESYS.SAFE !
> and it could be well on the very last sectors of a 2TB HD.
Extended partition VBR chain?
Just out of curiosity as I have started looking at partition type
codes recently (and the supposed depletion thereof) if you do include
the Kesys partition in a VBR or MBR partition table what type code did
you choose?
> as said above, the startup code may load a few sectors below 1.MB,but
> here all PRE-OS-START-code can take place (0.2 seconds incl. msg-text)
> like hardware detection checks and creating partition-tree info,etc..
>
> and then it may (if configured that way) show a boot-selection menu
> to start KESYS or any other installed OS.
OS's VBR to 0:0x7c00 and start it? From what I have seen so far it
looks like the Microsoft partitions would work that way but I'm not
sure about Linux or others.
> GDT/IDT/IVT, PM32 setup, mounting drives and volumes, etc.. are also
> mainly 'run-once' and may be seen as pre-OS start, but just done and
> kept before the OS deploys itself by loading all desired code modules.
James
James Harris
Apr 28, 2012, 5:20:17 AM4/28/12
to
On Apr 26, 12:09 pm, Antoine Leca <r...@localhost.invalid> wrote:
...
> > Besides, the names the BIOS uses may not mean anything to the user.
> > Maybe we can use better ones.
>
> Only maybe. The mapping between the BIOS (INT13h) drives and the drives
> as seen within the final OS (what the real user sees) is often not
> trivial, and sometimes impossible (as in cases of logical volume
> management.)
Yes, only "maybe" - I used the word deliberately. I have not looked
into that yet but with the extra code space that the proposed boot
partition would give there are definitely possibilities.
For sure it would be good to avoid just using UUIDs. :-|
> >> - slows down booting
>
> > Hardly.
>
> Well, if removing the enumeration of _all_ the devices (on USB etc.) to
> _only_ the booting one is the only change involved in those new
> "FastBoot" BIOSes, then having access to all the devices probably slows
> down booting.
>
> > If all disks were powered up at the time the MBR code got
> > control then, as an example, say there were five boot records (MBR/EBR/
> > VBR) to read and each took 10ms.
>
> I challenge that number. It is not only about having the physical plates
> to be powered up and rotating, there are also the time needed for each
> of the intermediary electronic devices in between to finish their
> "reset" cycles. And if in between you have a RAID controller which
> checks all of its 256MB of cache memory as part of its reset, or an USB
> root arbitrator which resets the whole USB bus, it certainly will last
> more than a few milliseconds.
Understood. Sometimes I wonder why things are so slow but I'll have to
wait until I get to that point to find out. What I can say is that I
have often found that it is possible to write code which is much
faster than people who are used to existing systems expect.
OT but, as an example, at work we needed a syslog collector to run on
a Windows machine and receive significant quantities of syslog reports
(UDP port 514). Among others I tried the Solarwinds offering but it
completely maxed-out the CPU and became unresponsive until we stopped
sending the syslogs to it. In the end I wrote a simple collector to do
what we wanted and it worked with tiny CPU usage. Since then it has
run for months on lower levels of reports, has collected many
megabytes of data and it hardly registers any CPU usage!
That's not an isolated case and I don't mean to single out any one
package. The point is that code written by people who are paid to do
what they do and which can have a good reputation can be achingly
inefficient.
Of course there's no option but to wait for hardware where necessary
but it's not until we look at writing stuff ourselves that we can
finally see whether something really needs to be slow or not.
...
> > I feel exasperated that Syslinux, Grub and Lilo apparently
> > load their second stages from fixed locations - often within a Linux
> > partition or, if not, from somewhere on the disk that has no
> > protection.
>
> I am not sure I understand the "un/protected area of the disk" concept.
> Can you elaborate? Protected from who? Why?
I meant areas which are not part of a defined structure such as the
MBR, an EBR or a partition. For example, AIUI Grub 1 might store some
of its code in the sectors following the MBR. Was that it's "stage
1.5" code?
> The very purpose of Syslinux is to load Linux from a FAT partition: no
> more, no less.
Confusingly, Syslinux is the name of both the whole project and just
the FAT loader within that project.
http://www.syslinux.org/wiki/index.php/The_Syslinux_Project
Maybe the variant should have been called FATLINUX!
> Of course, the resulting 2nd stage cannot be in a
> "protected area of the disk", since it has to be in the root of a FAT
> volume; BTW, the only "fixed location" of it is its name, LDLINUX.SYS
Doesn't the FAT system allow for some reserved sectors to come before
the first FAT - e.g. the reserved sectors in
http://en.wikipedia.org/wiki/BIOS_Parameter_Block
Perhaps that could be a good location for the initial loader.
> OTOH GRUB is very much the jack of all trades (and it does look like an
> OS in reduction, and growing/bloating.) While it can load Linux form a
> fixed location inside a Linux volume, like --and because-- LILO does, it
> can also do a lot of other things, like in GRUB4NT variants directly
> loading the Windows kernel dynamically from a Windows volume...
Yes, bloatware is a good description of it. I'm beginning to think the
Grand Unified Bootloader is becoming too Grand!
I had hopes for Syslinux but it seems to suffer from the same issue of
assuming that a file it needs starts in a fixed location. See
https://wiki.archlinux.org/index.php/Syslinux#Syslinux_Boot_Process
where it says, "in the case of ext2/3/4 and fat12/16/32, the starting
sector of ldlinux.sys is hard-coded into the VBR. The VBR will execute
(ldlinux.sys). Therefore, if the location of ldlinux.sys changes,
syslinux will no longer boot."
Not good!
James
...
> > Besides, the names the BIOS uses may not mean anything to the user.
> > Maybe we can use better ones.
>
> Only maybe. The mapping between the BIOS (INT13h) drives and the drives
> as seen within the final OS (what the real user sees) is often not
> trivial, and sometimes impossible (as in cases of logical volume
> management.)
into that yet but with the extra code space that the proposed boot
partition would give there are definitely possibilities.
For sure it would be good to avoid just using UUIDs. :-|
> >> - slows down booting
>
> > Hardly.
>
> Well, if removing the enumeration of _all_ the devices (on USB etc.) to
> _only_ the booting one is the only change involved in those new
> "FastBoot" BIOSes, then having access to all the devices probably slows
> down booting.
>
> > If all disks were powered up at the time the MBR code got
> > control then, as an example, say there were five boot records (MBR/EBR/
> > VBR) to read and each took 10ms.
>
> I challenge that number. It is not only about having the physical plates
> to be powered up and rotating, there are also the time needed for each
> of the intermediary electronic devices in between to finish their
> "reset" cycles. And if in between you have a RAID controller which
> checks all of its 256MB of cache memory as part of its reset, or an USB
> root arbitrator which resets the whole USB bus, it certainly will last
> more than a few milliseconds.
wait until I get to that point to find out. What I can say is that I
have often found that it is possible to write code which is much
faster than people who are used to existing systems expect.
OT but, as an example, at work we needed a syslog collector to run on
a Windows machine and receive significant quantities of syslog reports
(UDP port 514). Among others I tried the Solarwinds offering but it
completely maxed-out the CPU and became unresponsive until we stopped
sending the syslogs to it. In the end I wrote a simple collector to do
what we wanted and it worked with tiny CPU usage. Since then it has
run for months on lower levels of reports, has collected many
megabytes of data and it hardly registers any CPU usage!
That's not an isolated case and I don't mean to single out any one
package. The point is that code written by people who are paid to do
what they do and which can have a good reputation can be achingly
inefficient.
Of course there's no option but to wait for hardware where necessary
but it's not until we look at writing stuff ourselves that we can
finally see whether something really needs to be slow or not.
...
> > I feel exasperated that Syslinux, Grub and Lilo apparently
> > load their second stages from fixed locations - often within a Linux
> > partition or, if not, from somewhere on the disk that has no
> > protection.
>
> I am not sure I understand the "un/protected area of the disk" concept.
> Can you elaborate? Protected from who? Why?
MBR, an EBR or a partition. For example, AIUI Grub 1 might store some
of its code in the sectors following the MBR. Was that it's "stage
1.5" code?
> The very purpose of Syslinux is to load Linux from a FAT partition: no
> more, no less.
the FAT loader within that project.
http://www.syslinux.org/wiki/index.php/The_Syslinux_Project
Maybe the variant should have been called FATLINUX!
> Of course, the resulting 2nd stage cannot be in a
> "protected area of the disk", since it has to be in the root of a FAT
> volume; BTW, the only "fixed location" of it is its name, LDLINUX.SYS
the first FAT - e.g. the reserved sectors in
http://en.wikipedia.org/wiki/BIOS_Parameter_Block
Perhaps that could be a good location for the initial loader.
> OTOH GRUB is very much the jack of all trades (and it does look like an
> OS in reduction, and growing/bloating.) While it can load Linux form a
> fixed location inside a Linux volume, like --and because-- LILO does, it
> can also do a lot of other things, like in GRUB4NT variants directly
> loading the Windows kernel dynamically from a Windows volume...
Grand Unified Bootloader is becoming too Grand!
I had hopes for Syslinux but it seems to suffer from the same issue of
assuming that a file it needs starts in a fixed location. See
https://wiki.archlinux.org/index.php/Syslinux#Syslinux_Boot_Process
where it says, "in the case of ext2/3/4 and fat12/16/32, the starting
sector of ldlinux.sys is hard-coded into the VBR. The VBR will execute
(ldlinux.sys). Therefore, if the location of ldlinux.sys changes,
syslinux will no longer boot."
Not good!
James
James Harris
Apr 28, 2012, 6:45:38 AM4/28/12
to
On Apr 23, 1:32 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
...
As you know, I do make an effort to respond to all non-rhetorical
questions but there are something like 15 to 20 in your post! And they
take time to answer. So I hope you don't mind but starting with this
post I'm going to change tack and respond just to selected ones.
...
> > We all want to make the use of a PC better for users don't we?
>
> No. What users?
That speaks volumes. :-o
> My (stalled) OS is light-years away from having any users (excluding me, of
> course). Don't you need to get an OS written first before considering
> users? Don't you need to get an OS written first before considering the OS'
> impact upon users? etc.
It's an approach, for sure. I'd rather consider the users' needs as I
go.
...
> > > - slows down booting
>
> > Waiting for user input would slow down booting, yes, but given what
> > you say elsewhere are you thinking that displaying a menu would be
> > slow? There would only be a wait-for-input delay if chosen by a user.
>
> Yes. All console I/O is slow.
That STM a bizarre view. What led you to that conclusion? IIRC you may
be comparing Windows command prompt speed. *It* is very slow but
that's a problem with the Windows software, not with the concept of
console output. Could it be the work like hardware detection between
console messages that led you to think the console output is the slow
factor?
...
> Wouldn't it be a security violation if your bootloader could boot devices
> specifically set to not boot? I think it would. But, I'm guessing as to
> your meaning here too, so maybe you meant to enhance an obsolete BIOS by
> allowing it to boot other devices it doesn't recognize? You understand that
> the bootloader would have to provide drivers for that other device, yes?
No to both questions. I'm only thinking about devices that the BIOS
supports.
...
> > > > * issue meaningful diagnostics if errors occur
>
> > > Why?
> > > - good for scared newb's
>
> > When you refer to newbs are you thinking of new OS developers?
>
> No, I'm thinking of novice OS users. They do stuff "no one" - i.e., those
> who are computer literate or even semi-computer literate - would ever
> expect, anyone to do.
>
> Not to pry into your private life, but do you have elderly parents who use
> computers? (no need to answer)
...
Point taken. There is little we can do for some people, I agree. But
we can make computers easier for many. The diagnostic messages that
some programs output, even for seasoned IT professionals, can be
mystifying.
...
You made some valid points about users (snipped) and reminded me of
how difficult it is for some people to use computers. Have you ever
read the book "The Psychology of Everyday Things"? It is not about
computers but about how humans interact with normal objects. It talks
about examples of good or bad designs and the effect they have on us
as users of those objects. Essentially, a badly designed object can be
confusing even to a clever person. By contrast, a well designed object
can become so usable, even to someone with little knowledge, that it
becomes transparent. The book is a good read for someone designing
something (e.g. an OS) for others to use.
...
> > Even for us, existing messages may be of little use. Let's have a
> > quiz... Here are some messages one might get from an MBR program. What
> > exactly is each one telling us? I don't know. Much of the time it
> > would not even be clear which disk, partition table entry or error it
> > was talking about.
>
> > Invalid system disk
> > Disk I/O error
> > Replace the disk then press any key
> > Disk error
> > Missing operating system
> > Invalid partition table
> > Error loading operating system
>
> > All are taken from MBR code (not floppy code) found at
>
> > [link]
>
> Well, I know what those mean.
You do...? Are you sure you are not deluding yourself? ;-)
...
> Ok, quiz. What would be better "diagnostics" for "Error loading operating
> system" or "Invalid system disk"?
If you tell me what they mean I'll try to come up with better
messages.
...
> > > - slows down booting
>
> > By printing a few messages! How can that possibly impact on boot
> > speed? No one will notice a few milliseconds difference especially if
> > something went wrong. Surely this is very worth doing.
>
> Ok, you're just thinking about your menu.
No, not at this point. In the comment above I was thinking about
diagnostic messages.
> Have you seen a recent Linux boot? Once past the BIOS screens, DOS takes
> about 1 second, if that. Windows 98 takes about 10 seconds. Linux scrolls
> a vast volume of text, then stalls for module loadings, etc. It takes about
> 5 minutes. That's with a current high speed BSD based distro's like Vector
> Linux. 85% of that load time is due *purely* to the slowness of console
> I/O.
I don't find Linux anything like that slow (and versions of Windows
post 98 are also slow to start). But to an extent that's irrelevant.
As you acknowledge, Linux is detecting hardware and doing other things
on bootup. Those things are what is slow, not the console output.
...
> > Since starting this I've come across other reasons such as how poor
> > (fragile, vulnerable, inflexible, uninformative) existing boot-menu
> > systems seem to be. All the more reason to consider writing a good
> > one.
>
> If you're not going to start from scratch, wouldn't it be better use of time
> to take a good one and make it phenomenal?
* There is no good one out there!
* The ones I have seen have too big a scope.
* Some I have seen are too big and difficult to learn.
* A good pre-OS piece of code would not be a lot of work to write. In
some ways it would be easier than an MBR as there is not the same code
space restriction.
...
> > Why can't people separate concepts when they design things.
>
> Market control, limited foresight, history - that's the way it's always been
> done, pick one of those as an answer or something else ...
>
> So, you're saying that GM, Ford, Chrysler, and Toyota should have more
> interchangeable parts than just tires?
...
No but I am saying that it would be better for train manufacturers if
there was an agreed spec for the tracks. ;-)
James
wrote:
...
As you know, I do make an effort to respond to all non-rhetorical
questions but there are something like 15 to 20 in your post! And they
take time to answer. So I hope you don't mind but starting with this
post I'm going to change tack and respond just to selected ones.
...
> > We all want to make the use of a PC better for users don't we?
>
> No. What users?
> My (stalled) OS is light-years away from having any users (excluding me, of
> course). Don't you need to get an OS written first before considering
> users? Don't you need to get an OS written first before considering the OS'
> impact upon users? etc.
go.
...
> > > - slows down booting
>
> > Waiting for user input would slow down booting, yes, but given what
> > you say elsewhere are you thinking that displaying a menu would be
> > slow? There would only be a wait-for-input delay if chosen by a user.
>
> Yes. All console I/O is slow.
be comparing Windows command prompt speed. *It* is very slow but
that's a problem with the Windows software, not with the concept of
console output. Could it be the work like hardware detection between
console messages that led you to think the console output is the slow
factor?
...
> Wouldn't it be a security violation if your bootloader could boot devices
> specifically set to not boot? I think it would. But, I'm guessing as to
> your meaning here too, so maybe you meant to enhance an obsolete BIOS by
> allowing it to boot other devices it doesn't recognize? You understand that
> the bootloader would have to provide drivers for that other device, yes?
supports.
...
> > > > * issue meaningful diagnostics if errors occur
>
> > > Why?
> > > - good for scared newb's
>
> > When you refer to newbs are you thinking of new OS developers?
>
> No, I'm thinking of novice OS users. They do stuff "no one" - i.e., those
> who are computer literate or even semi-computer literate - would ever
> expect, anyone to do.
>
> Not to pry into your private life, but do you have elderly parents who use
> computers? (no need to answer)
Point taken. There is little we can do for some people, I agree. But
we can make computers easier for many. The diagnostic messages that
some programs output, even for seasoned IT professionals, can be
mystifying.
...
You made some valid points about users (snipped) and reminded me of
how difficult it is for some people to use computers. Have you ever
read the book "The Psychology of Everyday Things"? It is not about
computers but about how humans interact with normal objects. It talks
about examples of good or bad designs and the effect they have on us
as users of those objects. Essentially, a badly designed object can be
confusing even to a clever person. By contrast, a well designed object
can become so usable, even to someone with little knowledge, that it
becomes transparent. The book is a good read for someone designing
something (e.g. an OS) for others to use.
...
> > Even for us, existing messages may be of little use. Let's have a
> > quiz... Here are some messages one might get from an MBR program. What
> > exactly is each one telling us? I don't know. Much of the time it
> > would not even be clear which disk, partition table entry or error it
> > was talking about.
>
> > Invalid system disk
> > Disk I/O error
> > Replace the disk then press any key
> > Disk error
> > Missing operating system
> > Invalid partition table
> > Error loading operating system
>
> > All are taken from MBR code (not floppy code) found at
>
> > [link]
>
> Well, I know what those mean.
...
> Ok, quiz. What would be better "diagnostics" for "Error loading operating
> system" or "Invalid system disk"?
messages.
...
> > > - slows down booting
>
> > By printing a few messages! How can that possibly impact on boot
> > speed? No one will notice a few milliseconds difference especially if
> > something went wrong. Surely this is very worth doing.
>
> Ok, you're just thinking about your menu.
diagnostic messages.
> Have you seen a recent Linux boot? Once past the BIOS screens, DOS takes
> about 1 second, if that. Windows 98 takes about 10 seconds. Linux scrolls
> a vast volume of text, then stalls for module loadings, etc. It takes about
> 5 minutes. That's with a current high speed BSD based distro's like Vector
> Linux. 85% of that load time is due *purely* to the slowness of console
> I/O.
post 98 are also slow to start). But to an extent that's irrelevant.
As you acknowledge, Linux is detecting hardware and doing other things
on bootup. Those things are what is slow, not the console output.
...
> > Since starting this I've come across other reasons such as how poor
> > (fragile, vulnerable, inflexible, uninformative) existing boot-menu
> > systems seem to be. All the more reason to consider writing a good
> > one.
>
> If you're not going to start from scratch, wouldn't it be better use of time
> to take a good one and make it phenomenal?
* The ones I have seen have too big a scope.
* Some I have seen are too big and difficult to learn.
* A good pre-OS piece of code would not be a lot of work to write. In
some ways it would be easier than an MBR as there is not the same code
space restriction.
...
> > Why can't people separate concepts when they design things.
>
> Market control, limited foresight, history - that's the way it's always been
> done, pick one of those as an answer or something else ...
>
> So, you're saying that GM, Ford, Chrysler, and Toyota should have more
> interchangeable parts than just tires?
No but I am saying that it would be better for train manufacturers if
there was an agreed spec for the tracks. ;-)
James
Harry Vaderchi
Apr 28, 2012, 10:51:23 AM4/28/12
to
> I had hopes for Syslinux but it seems to suffer from the same issue of
> assuming that a file it needs starts in a fixed location. See
>
> https://wiki.archlinux.org/index.php/Syslinux#Syslinux_Boot_Process
>
> where it says, "in the case of ext2/3/4 and fat12/16/32, the starting
> sector of ldlinux.sys is hard-coded into the VBR. The VBR will execute
> (ldlinux.sys). Therefore, if the location of ldlinux.sys changes,
> syslinux will no longer boot."
>
> Not good!
>
track 0.
They managed to get a search string function (for NTLDR) in the NT code,
but it's quite tight!
(I wrote a program way back last century to identify various disks by boot
track)
> James
Rod Pemberton
Apr 28, 2012, 7:31:01 PM4/28/12
to
"James Harris" <james.h...@gmail.com> wrote in message
news:feb3dfa9-4466-4bc7...@21g2000vbh.googlegroups.com...
> On Apr 23, 1:32 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
...
> > Yes. All console I/O is slow.
>
> That STM a bizarre view. What led you to that conclusion? IIRC you may
> be comparing Windows command prompt speed. *It* is very slow but
> that's a problem with the Windows software, not with the concept of
> console output. Could it be the work like hardware detection between
> console messages that led you to think the console output is the slow
> factor?
- pick any OS
- create a large file
- type or cat that file
- 1st time redirect to a disk file
- 2nd time directly to the screen
So, why does the screen console I/O take orders of magnitudes longer to
display? Why is this true even on high-performance graphics cards?
The hard disk is order of magnitudes slower. The hard disk has a slower
interface with less throughput and uses a physical mechanism too.
It doesn't matter if you choose MS-DOS/FreeDOS/IBMDOS/PCDOS, a new or old
Linux, Free/Open/BSD, Windows 98/SE/ME, or Windows Vista/XP/7. The hard
disk always wins that speed challenge. I.e., RM and PM and drivers or BIOS
calls used are insignificant to the outcome. These results haven't changed
since I started using x86 PCs, back in the era of MFM HDs.
My graphics card (which recently died) could do 500+ fps for Q3A with 32-bit
color at 1680x1050 resolution. When I built the machine, I didn't have a
new hard disk. I had to use one of my old drives. Console I/O at that time
was beaten by a Seagate hard disk from 1998 which does one sector per
second. You can actually hear the drive mechanism click each time it moves.
It's that slow.
Yes, a move of a character to the screen should be just one MOV - a few
clocks cycles, but something - hardware or software - kills console I/O on
x86 PCs. My belief is it's the hardware based on multi-OS experience.
That is the basis of my statements.
> Have you ever read the book "The Psychology of Everyday Things"?
> It is not about computers but about how humans interact with normal
> objects. It talks about examples of good or bad designs and the effect
> they have on us as users of those objects. Essentially, a badly designed
> object can be confusing even to a clever person. By contrast, a well
> designed object can become so usable, even to someone with little
> knowledge, that it becomes transparent. The book is a good read for
> someone designing something (e.g. an OS) for others to use.
That sounds like engineering principles. Some might say design principles.
Others might say research and development. Others might say user feedback.
> > > Invalid system disk
> > > Disk I/O error
> > > Replace the disk then press any key
> > > Disk error
> > > Missing operating system
> > > Invalid partition table
> > > Error loading operating system
>
> > Well, I know what those mean.
>
> You do...?
Well, in general, yes. I haven't seen many of them in a long time. IIRC,
>
> You do...?
the basic failure messages were similar on multiple PCs, i.e., C64, Apple
IIs, IBM PCs, etc. When I see them, I have just experienced the exact
failure context that generated the error, so usually know what they mean.
Even if I'm not correct about their exact meanings below, I'd suspect these
are documented as to their exact meanings either on the site with the link,
or the general internet for those who care to know precisely.
I.e., you just plugged in a new hard drive, intended to boot from a boot
floppy, but the BIOS was setup to boot from harddisk and you were slow
inserting the floppy. You know the "Missing operating system" or "Invalid
system disk" or "Invalid partition table" was due to your failure to finish
setting up the hard disk and the BIOS attempting to boot it, and you know
which stage you were at: partition, format, make active, install
MBR/VBR/PBR, install OS.
"Invalid system disk"
I think that usually means the disk wasn't formatted. It could be
something else related like the active partition was deleted and so not
found. Or, possibly, there was no active, i.e., bootable, partition table
entry found.
"Missing operating system"
The disk was setup as a boot disk, the filesystem was formatted, but no OS
was installed to that disk. I.e., OS files not found error.
"Error loading operating system"
Something went wrong with loading the OS. I don't recall ever seeing this
one. This may be a memory related error, e.g., on early PC with an
insufficient amount of RAM.
"Replace the disk then press any key"
I.e., it can't boot and is asking for a different valid boot disk as a
replacement.
"Invalid partition table"
Something was detectably wrong with the partition table. I don't know
what the boot code attempts to detect. I would suspect it does multiple
checks. This could be due to active flag on a wrong partition, invalid
start or end tracks or sectors in partition table, all blank partition
entries, wrong partition type for the boot code, etc. I.e., something is
wrong with your partition table entry or entries. So, you need to start
your partition editor program and fix it or repartition.
"Disk I/O error"
"Disk error"
I'm not sure of the exact difference between these. I've seen "Disk I/O
error" a few times. So, I suspect the "Disk I/O error" indicates that the
floppy drive couldn't read a bad track. The "Disk error" may be a low track
read error, or error reading the filesystem's structures, e.g., FAT or
filesystem directory. Track zero corruption used to be notorious on
floppies.
> Are you sure you are not deluding yourself? ;-)
>
can a singularity, i.e., individual, accurately confirm delusion within
oneself? I.e., one maybe delusional or maybe not. Or, does that take two?
I.e., one delusional and one not. Which is delusional? Or, three? So, one
delusional and two not, or two delusional and one not, or three not or three
are ... Well, who is delusional? I still can't tell. Or, many? I.e.,
majority rules. Ask your psychologist ... while a mathematician friend is
present ...
> > Ok, quiz. What would be better "diagnostics" for "Error loading
> > operating system" or "Invalid system disk"?
>
> If you tell me what they mean I'll try to come up with better
> messages.
Yahoo search for the messages? Are you asking me to provide *code derived*
meanings, i.e., "Invalid partition table" means it checks for this and this
and fails for this ... ?
Rod Pemberton
wolfgang kern
Apr 30, 2012, 5:46:23 AM4/30/12
to
James Harris wrote:
(need to use manually quotes "|" yet)
but it would need a certain formatting tool to make extra space to hold
a larger (consecutive) VBR.
> I see no reason for distributing the job over several sectors
> (MBR>EBR>VBR) except for M$ or Linux styled boot. Or do you have
> problems to merge the first-step loader into the MBR ?
|I do, yes. The MBR itself is too small on its own (for what I would
|like it to do).
Too many verbose messages may be more confusing than of any help ...
> In opposition to M$'s apart aproach methink the MBR can already
> contain all information about the actual active FS.
> Even this would loose the ?convenient? single active bit setting.
> Altering an MBR usually need full sector read/modify/write anyway.
>
> For machines delivered with my OS I got two MBR-variants:
>
> KESYS.SAFE
> doesn't have partitions at all and all FS-info is already stored
> within the MBR, so it dont need an VBR in addition to load and start.
>
> and KESYS.OPEN
> this MBR got a partition-table which may use all four entries,
> it could even look like:
> 1. DOS_FAT
> 2. windoze_NTFS
> 3. Loonix
> 4. Extended
>
> and you may now ask: "where is the KESYS-partition ?"
> answer: same as in KESYS.SAFE !
> and it could be well on the very last sectors of a 2TB HD.
|In this case does the Kesys partition have a VBR in the normal
|Extended partition VBR chain?
And the .OPEN version is found after the end of extended partition(s)
(windoze may call this area unused/unformatted).
My old now obsolete KESYS.DEMO were started from DOS with a '.com',
and this used of course the code found in an KESYS-partition.
IMHO: Partitions are just part of a FileSystem, which we only need
for compatibility with other OS-formats.
|Just out of curiosity as I have started looking at partition type
|codes recently (and the supposed depletion thereof) if you do include
|the Kesys partition in a VBR or MBR partition table what type code did
|you choose?
So by any luck neither windoze nor Loonix will touch my partitions, even
they are rare seen on machines which run one of the big two.
> as said above, the startup code may load a few sectors below 1.MB,but
> here all PRE-OS-START-code can take place (0.2 seconds incl. msg-text)
> like hardware detection checks and creating partition-tree info,etc..
> and then it may (if configured that way) show a boot-selection menu
> to start KESYS or any other installed OS.
|If you chain load another OS how do you do it? Do you just load that
|OS's VBR to 0:0x7c00 and start it? From what I have seen so far it
|looks like the Microsoft partitions would work that way but I'm not
|sure about Linux or others.
valid partition entries and installation-status.
And btw:
it may be wise to not install several different OS onto one HD, while
data within any FileSystem of any format can reside everywhere.
Every OS (incl. mine) tend to modify the whole MBR and more...
__
wolfgang
James Harris
Apr 30, 2012, 4:57:53 PM4/30/12
to
On Apr 30, 10:46 am, "wolfgang kern" <nowh...@never.at> wrote:
...
> > I see no reason for distributing the job over several sectors
> > (MBR>EBR>VBR) except for M$ or Linux styled boot. Or do you have
> > problems to merge the first-step loader into the MBR ?
>
> |I do, yes. The MBR itself is too small on its own (for what I would
> |like it to do).
>
> :) KISS ? (keep it 'small'&'simple')
> Too many verbose messages may be more confusing than of any help ...
Agreed about normal messages. I'd like to keep it to one screenful -
in part because there is no scrolling and I don't want info shooting
at turbo speed off the top of the screen before the user has a chance
to read it.
...
> My choosen partition type 0x4B ("K") may have never made it into public.
> So by any luck neither windoze nor Loonix will touch my partitions, even
> they are rare seen on machines which run one of the big two.
Seems to be unused by anything else:
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
> > as said above, the startup code may load a few sectors below 1.MB,but
> > here all PRE-OS-START-code can take place (0.2 seconds incl. msg-text)
> > like hardware detection checks and creating partition-tree info,etc..
> > and then it may (if configured that way) show a boot-selection menu
> > to start KESYS or any other installed OS.
>
> |If you chain load another OS how do you do it? Do you just load that
> |OS's VBR to 0:0x7c00 and start it? From what I have seen so far it
> |looks like the Microsoft partitions would work that way but I'm not
> |sure about Linux or others.
>
> Yes, and in opposition to what a BIOS does, here I have to check for
> valid partition entries and installation-status.
I don't understand. A VBR doesn't have partition entries so what do
you have to check for?
From your MBR code if you have to start a Linux partition do you just
load the VBR of that partition (probably to 0x7c00) and start it? If
not, what do you do to start Linux from your MBR?
> And btw:
> it may be wise to not install several different OS onto one HD, while
> data within any FileSystem of any format can reside everywhere.
I know. I don't like having multiple OSes on one hard disk and tend to
avoid it. Some people use it, though. In fact I do have such on one
laptop. It works well there because I use one OS nearly all the time.
On occasion when I want to use the other one it is there already
installed. So I guess it is useful sometimes.
> Every OS (incl. mine) tend to modify the whole MBR and more...
I think that as long as the MBR eventually does nothing more than
start-up the VBR of the selected partition then all should be well
with the world. Surprisingly, from what I have seen the Microsoft MBRs
do just that - ultimately they start a VBR and it is up to the VBR to
take the next step. It is the Grubs and Lilos and whatnot that do
everything different. As a consequence I'm not sure how well Linux
will start from a VBR. I'll get round to testing at some point but it
sounds like you may already know.
James
...
> > I see no reason for distributing the job over several sectors
> > (MBR>EBR>VBR) except for M$ or Linux styled boot. Or do you have
> > problems to merge the first-step loader into the MBR ?
>
> |I do, yes. The MBR itself is too small on its own (for what I would
> |like it to do).
>
> :) KISS ? (keep it 'small'&'simple')
> Too many verbose messages may be more confusing than of any help ...
in part because there is no scrolling and I don't want info shooting
at turbo speed off the top of the screen before the user has a chance
to read it.
...
> My choosen partition type 0x4B ("K") may have never made it into public.
> So by any luck neither windoze nor Loonix will touch my partitions, even
> they are rare seen on machines which run one of the big two.
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
> > as said above, the startup code may load a few sectors below 1.MB,but
> > here all PRE-OS-START-code can take place (0.2 seconds incl. msg-text)
> > like hardware detection checks and creating partition-tree info,etc..
> > and then it may (if configured that way) show a boot-selection menu
> > to start KESYS or any other installed OS.
>
> |If you chain load another OS how do you do it? Do you just load that
> |OS's VBR to 0:0x7c00 and start it? From what I have seen so far it
> |looks like the Microsoft partitions would work that way but I'm not
> |sure about Linux or others.
>
> Yes, and in opposition to what a BIOS does, here I have to check for
> valid partition entries and installation-status.
you have to check for?
From your MBR code if you have to start a Linux partition do you just
load the VBR of that partition (probably to 0x7c00) and start it? If
not, what do you do to start Linux from your MBR?
> And btw:
> it may be wise to not install several different OS onto one HD, while
> data within any FileSystem of any format can reside everywhere.
avoid it. Some people use it, though. In fact I do have such on one
laptop. It works well there because I use one OS nearly all the time.
On occasion when I want to use the other one it is there already
installed. So I guess it is useful sometimes.
> Every OS (incl. mine) tend to modify the whole MBR and more...
start-up the VBR of the selected partition then all should be well
with the world. Surprisingly, from what I have seen the Microsoft MBRs
do just that - ultimately they start a VBR and it is up to the VBR to
take the next step. It is the Grubs and Lilos and whatnot that do
everything different. As a consequence I'm not sure how well Linux
will start from a VBR. I'll get round to testing at some point but it
sounds like you may already know.
James
Rod Pemberton
May 1, 2012, 1:08:51 AM5/1/12
to
"James Harris" <james.h...@gmail.com> wrote in message
news:0244f90c-04ac-4f9c...@21g2000vbh.googlegroups.com...
> > My choosen partition type 0x4B ("K") may have never made it into public.
>
>
> Seems to be unused by anything else:
>
> [link]
>
>
0x4B is not in my list either. So, you're probably good.
The webpage at the link must be adding current partition types and values,
and removing obsolete ones. That webpage above had ten or so that I didn't
have. I compiled my list around 2007 from a few major sources and a bunch
of insignificant ones. It's only missing one partition value which has or
had a partition type (0xe2). Also, a bunch of partition values which that
list has marked "reserved" are marked "HP Volume Expansion" on other lists.
However, it's missing, or has removed, partition types on many partition
values:
a bunch on 0x42
a few on 0x43
one on 0x81
one on 0x83
one on 0x86
two on 0x87
one on 0x8b
one on 0x8c
one on 0x93
one on 0xe2 - entirely missing
one on 0xf2
one on 0x0d - uncertain if real
HTH,
Rod Pemberton
wolfgang kern
May 2, 2012, 2:11:14 PM5/2/12
to
James Harris wrote:
...
>> I see no reason for distributing the job over several sectors
>> (MBR>EBR>VBR) except for M$ or Linux styled boot. Or do you have
>> problems to merge the first-step loader into the MBR ?
> |I do, yes. The MBR itself is too small on its own (for what I would
> |like it to do).
> :) KISS ? (keep it 'small'&'simple')
> Too many verbose messages may be more confusing than of any help ...
|Agreed about normal messages. I'd like to keep it to one screenful -
|in part because there is no scrolling and I don't want info shooting
|at turbo speed off the top of the screen before the user has a chance
|to read it.
screen access [es:di] or INT0x10-fn, so almost just a few bytes...
...
> My choosen partition type 0x4B ("K") may have never made it into public.
> So by any luck neither windoze nor Loonix will touch my partitions, even
> they are rare seen on machines which run one of the big two.
|Seems to be unused by anything else:
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
perhaps just by luck I'm the only 4B-user :)
> My choosen partition type 0x4B ("K") may have never made it into public.
> So by any luck neither windoze nor Loonix will touch my partitions, even
> they are rare seen on machines which run one of the big two.
|Seems to be unused by anything else:
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
>> as said above, the startup code may load a few sectors below 1.MB,but
>> here all PRE-OS-START-code can take place (0.2 seconds incl. msg-text)
>> like hardware detection checks and creating partition-tree info,etc..
>> and then it may (if configured that way) show a boot-selection menu
>> to start KESYS or any other installed OS.
> |If you chain load another OS how do you do it? Do you just load that
> |OS's VBR to 0:0x7c00 and start it? From what I have seen so far it
> |looks like the Microsoft partitions would work that way but I'm not
> |sure about Linux or others.
> Yes, and in opposition to what a BIOS does, here I have to check for
> valid partition entries and installation-status.
|I don't understand. A VBR doesn't have partition entries so what do
|you have to check for?
stored within the KESYS-bit-fields.
|From your MBR code if you have to start a Linux partition do you just
|load the VBR of that partition (probably to 0x7c00) and start it? If
|not, what do you do to start Linux from your MBR?
attempts to directly find and start Loonix-master/root-inodes failed.
> And btw:
> it may be wise to not install several different OS onto one HD, while
> data within any FileSystem of any format can reside everywhere.
|I know. I don't like having multiple OSes on one hard disk and tend to
|avoid it. Some people use it, though. In fact I do have such on one
|laptop. It works well there because I use one OS nearly all the time.
|On occasion when I want to use the other one it is there already
|installed. So I guess it is useful sometimes.
> Every OS (incl. mine) tend to modify the whole MBR and more...
|I think that as long as the MBR eventually does nothing more than
|start-up the VBR of the selected partition then all should be well
|with the world. Surprisingly, from what I have seen the Microsoft MBRs
|do just that - ultimately they start a VBR and it is up to the VBR to
|take the next step. It is the Grubs and Lilos and whatnot that do
|everything different.
|As a consequence I'm not sure how well Linux
|will start from a VBR. I'll get round to testing at some point but it
|sounds like you may already know.
and they already point in the MBR to a structure in a given LBA like KESYS.
__
wolfgang
James Harris
May 12, 2012, 3:05:41 PM5/12/12
to
On Apr 29, 12:31 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
Maybe the character-by-character nature of the output is slower. Maybe
it is deliberately slowed on some systems because it is for human
presentation. Maybe scrolling is slow on some systems, again, maybe on
purpose.
Perhaps it is slow where there are too many user-to-supervisor
transitions on some poorly-written OSes. We can do much better, can't
we!
As you say, there's not an obvious reason for the slowness you have
seen. I expect the systems you listed vary in character-output speed
too...?
Don't forget my proposal was a small amount of text. There's no time
to go into this now but a suitable test of the case in point would be
to add some code to a bootloader which works in real mode and uses the
BIOS int 0x10 to write about a page of text to the screen. I don't
think it would have an appreciable effect on the time taken to boot
up.
...
> > > Ok, quiz. What would be better "diagnostics" for "Error loading
> > > operating system" or "Invalid system disk"?
>
> > If you tell me what they mean I'll try to come up with better
> > messages.
>
> I didn't go to the link. Does it provide more info or code?
If you go to it you'll find out.
> Did you do a
> Yahoo search for the messages? Are you asking me to provide *code derived*
> meanings, i.e., "Invalid partition table" means it checks for this and this
> and fails for this ... ?
I did offer to come up with a better message or two if you explained
what they meant so to keep the commitment....
"Error loading operating system"
I think you maybe only guessed at the meaning of this when you spoke
about available RAM so I took a look at the source code on the site I
linked to earlier. Based on what I remember the meaning is that the
BIOS encountered an uncorrectable read error. You know the pattern:
read fail, disk reset and repeat a few times. If still no joy report
an error.
Based on that interpretation I'd offer as a better error message than
"Error loading operating system" something like
[CODE] File [NAME] unreadable at offset [OFFSET]. Run [OS] recovery
process.
Where [CODE] is a string the user could look up on the internet for a
detailed explanation, [NAME] is the file name or some other suitable
designation if unnamed and [OFFSET] is the offset into the file of
where the error was noticed. [OS] is an indicator to help the user
find the right recovery media.
IIRC you were about right with the other message "Invalid system disk"
but the meaning was more specific, it just complaining about the
absence of 0x55, 0xaa at the end of a boot sector. So here's a
suggested better message to replace "Invalid system disk"
[CODE] Disk [D] partition [P] boot sector is missing the 0x55, 0xaa
signature.
[CODE] The partition may be unformatted. Run [OS] recovery process to
check.
Again, the [CODE] part is a distinctive string that can be looked up
on the Internet (or looked up on a booklet). As well as providing
detailed explanation and instructions for recovery it can also be in
any number of languages.
Having the space (by virtue of the proposed boot partition) to give
clearer messages should make it much easier for IT experts to
understand what happened if something went wrong. Competent non-
experts can also get some clue as to what happened and, perhaps more
importantly, what to do next.
Even people who are afraid of computers and who have just one failed
PC and no internet access can get some help. They can phone a
competent friend who has internet access and quote the code at the
start of the message.
Why anyone would want to stick with the old messages is, frankly,
beyond me. IIRC one boot sector, probably for reasons of lack of
available space, just reports "Disk error" for almost anything. A boot
partition only needs to be tiny but would allow us to do much much
better.
James
wrote:
it is deliberately slowed on some systems because it is for human
presentation. Maybe scrolling is slow on some systems, again, maybe on
purpose.
Perhaps it is slow where there are too many user-to-supervisor
transitions on some poorly-written OSes. We can do much better, can't
we!
As you say, there's not an obvious reason for the slowness you have
seen. I expect the systems you listed vary in character-output speed
too...?
Don't forget my proposal was a small amount of text. There's no time
to go into this now but a suitable test of the case in point would be
to add some code to a bootloader which works in real mode and uses the
BIOS int 0x10 to write about a page of text to the screen. I don't
think it would have an appreciable effect on the time taken to boot
up.
...
> > > Ok, quiz. What would be better "diagnostics" for "Error loading
> > > operating system" or "Invalid system disk"?
>
> > If you tell me what they mean I'll try to come up with better
> > messages.
>
> I didn't go to the link. Does it provide more info or code?
> Did you do a
> Yahoo search for the messages? Are you asking me to provide *code derived*
> meanings, i.e., "Invalid partition table" means it checks for this and this
> and fails for this ... ?
what they meant so to keep the commitment....
"Error loading operating system"
I think you maybe only guessed at the meaning of this when you spoke
about available RAM so I took a look at the source code on the site I
linked to earlier. Based on what I remember the meaning is that the
BIOS encountered an uncorrectable read error. You know the pattern:
read fail, disk reset and repeat a few times. If still no joy report
an error.
Based on that interpretation I'd offer as a better error message than
"Error loading operating system" something like
[CODE] File [NAME] unreadable at offset [OFFSET]. Run [OS] recovery
process.
Where [CODE] is a string the user could look up on the internet for a
detailed explanation, [NAME] is the file name or some other suitable
designation if unnamed and [OFFSET] is the offset into the file of
where the error was noticed. [OS] is an indicator to help the user
find the right recovery media.
IIRC you were about right with the other message "Invalid system disk"
but the meaning was more specific, it just complaining about the
absence of 0x55, 0xaa at the end of a boot sector. So here's a
suggested better message to replace "Invalid system disk"
[CODE] Disk [D] partition [P] boot sector is missing the 0x55, 0xaa
signature.
[CODE] The partition may be unformatted. Run [OS] recovery process to
check.
Again, the [CODE] part is a distinctive string that can be looked up
on the Internet (or looked up on a booklet). As well as providing
detailed explanation and instructions for recovery it can also be in
any number of languages.
Having the space (by virtue of the proposed boot partition) to give
clearer messages should make it much easier for IT experts to
understand what happened if something went wrong. Competent non-
experts can also get some clue as to what happened and, perhaps more
importantly, what to do next.
Even people who are afraid of computers and who have just one failed
PC and no internet access can get some help. They can phone a
competent friend who has internet access and quote the code at the
start of the message.
Why anyone would want to stick with the old messages is, frankly,
beyond me. IIRC one boot sector, probably for reasons of lack of
available space, just reports "Disk error" for almost anything. A boot
partition only needs to be tiny but would allow us to do much much
better.
James
Rod Pemberton
May 14, 2012, 10:39:20 PM5/14/12
to
"James Harris" <james.h...@gmail.com> wrote in message
news:ea39d5fe-43a4-448f...@s5g2000vbc.googlegroups.com...
...
> IIRC one boot sector, probably for reasons of lack of
> available space, just reports "Disk error" for almost anything.
single message would be insufficient IMO.
Personally, I'd expect the user to know the *software* to run to:
partition a device
format a disk or device
make a disk or device bootable
But, I came from an era where a computer user had to be knowledgeable about
how to use the computer. Today, no instruction manuals come with the OS or
software. The software is supposedly "intuitive" and "smart" and "user
frienldy" etc. You can be intuitive or ignorant, have zero skills, and
still use the computer, smart-phone, whatever...
> Why anyone would want to stick with the old messages is, frankly,
> beyond me.
users know what that means? How many know how to fix it? You're not going
to hand a novice a disk editor are you?
What happens if that were to happen to an iPhone or Win7? Let's pretend a
malicious virus or malware corrupted that data intentionally. What would a
user see? Does a message say: "Please contact APPLE"? "... MS ..." ?
"Please take this device to a qualified service center?" Apple clearly
wouldn't allow the user to fix the error, so they probably don't allow the
user to install the OS either, i.e., factory installed. MS pushes
pre-installed Windows too.
Saying "invalid MBR" or "non-bootable disk" or "unexecutable MBR run
FDISK/MBR" or "FDISK MBR not found" etc would be better. The user
is likely to know what utility to use to make the disk bootable (e.g., FDISK
for DOS in my example).
Rod Pemberton
James Harris
May 15, 2012, 1:39:27 AM5/15/12
to
On May 15, 3:39 am, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
...
> > Why anyone would want to stick with the old messages is, frankly,
> > beyond me.
>
> Well, telling someone 0x55 and 0xAA weren't found doesn't do much. How many
> users know what that means? How many know how to fix it? You're not going
> to hand a novice a disk editor are you?
The following was part of the same error message.
[CODE] The partition may be unformatted. Run [OS] recovery process to
check.
The idea was to provide info at different levels so that different
people have appropriate info to gain from the report. I wouldn't omit
the 55-aa reference as it means something very specific and useful to
the people who may need to know what exactly was detected as wrong.
James
wrote:
...
> > Why anyone would want to stick with the old messages is, frankly,
> > beyond me.
>
> Well, telling someone 0x55 and 0xAA weren't found doesn't do much. How many
> users know what that means? How many know how to fix it? You're not going
> to hand a novice a disk editor are you?
[CODE] The partition may be unformatted. Run [OS] recovery process to
check.
people have appropriate info to gain from the report. I wouldn't omit
the 55-aa reference as it means something very specific and useful to
the people who may need to know what exactly was detected as wrong.
James
0 new messages