10 Apr
2005
10 Apr
'05
8:40 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Phillip Susi wrote:
Yea, so that's 9 years ago. Any computer newer than 9 years old should
support it no?
That's what I was thinking. Besides, some of the boot code that I've
written myself depends on that behavior (and I wrote it that way
specifically because there is a multi-vendor standard to back it up). I
have yet to find a computer that doesn't boot it off of any boot device.
Just because all of Microsoft's filesystems use a BPB doesn't mean that
*every single* device does. Under Windows NT raw hardware access is
denied, anyway, just like any other real 32-bit protected system should
be. Meaning that that data should only be there if it is of real
benefit to the operating system, and if not, that's several bytes that
can be used by the first stage boot loader for whatever purposes
(intelligent finding of a system file to load, perhaps, so that the
kernel can be dynamically located somewhere in the root directory,
verses a boot-block-list being required or something like that).
I am sure that while Microsoft systems aren't the only family to use the
BPB method of doing things, that there are plenty of other systems out
there that don't use that method for one reason or another. I think
it's more beneficial to have a static boot sector rather then one that
needs to be updated constantly by programs that format or initialize a
filesystem.
Perhaps when I have a little bit more time I'll look into the source for
some other programs and see how they manage the task of being on
bootable media and booting. However, as far as I can tell from what
I've looked at so far, LILO doesn't use a BPB, just taking a first
glance at their assembly language source to the boot loader.
Sure, it'd be wise to support the BPB for FATxx file systems as well as
NTFS, but not because it's "generally a smarter thing to do." More like
because that's the published standard for those filesystems, so any
program interoperating with those particular filesystems should adhere
to that standard. But does that mean that ReactOS is bound to it?
Certainly not. If the ReactOS programmers go and implement support in
the kernel for ext3 and ReiserFS, and they can use that as the system
boot volume's filesystem, then most certainly their boot loader
shouldn't be tied to objects from another family of filesystems.
A quick (*NOT* complete - so don't take this as etched in stone) glance
on Google tells me that there isn't a specified format for boot sectors
for ext[23] or ReiserFS, meaning that nobody should rely on them for
information about the filesystem or boot device, but rather that the
operating system should be able to figure that out on it's own.
I think that the standard mentioned in my last post was probably created
to help define the state of the system to promote alternative operating
systems growth, without hindering their ability to figure out what's
going on with the computer. That's a Good Thing, IMHO.
Were any of them newer than 1996? If it is only computers older than
1996 that we have to worry about, I don't think that is much of a concern.
Anyhow, just changing the value to 0xff would not have any better
effect, as it would still be looking to DL even on computers that do not
set it, so how is that any better of a fix?
I personally have yet to find a system that does not place the value of
the boot device into the DL register. I'm not an expert -- or even an
intermediate level -- programmer by any stretch of the imagination, but
for the various hobbyist level type things that I've tinkered with, all
of it has worked on every x86 box I've had my hands on -- mind you,
nothing older then probably 1998 or so. I only started seriously
getting into computers and different operating systems in 1996, and from
there, started programming in probably 1999 or so, and by the time I
started tinkering with OS-level things, it was 2001 and I had nothing
older then 1998 lying around. So we're talking a total of maybe 30 - 40
machines, but all of them were able to boot my code, and all of them
were from various manufacturers with different BIOS vendors.
- Mike
- --
Michael B. Trausch <fd0man(a)gmail.com>
Website: http://fd0man.chadeux.net/ Jabber: mtrausch(a)jabber.com
Phone: +1-(678)-522-7934 FAX (US Only): 1-866-806-4647
===================================================================
Do you have PGP or GPG? Key at pgp.mit.edu, Please Encrypt E-Mail!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCWY9BPXInbkqM7nwRAxAxAJ4lP13IlymrsGBwXfC78OBwv3vuEwCfZWaS
acbp3qWTB1+EpdqxUVDJYxw=
=Q2Z9
-----END PGP SIGNATURE-----