-----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@gmail.com Website: http://fd0man.chadeux.net/ Jabber: mtrausch@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!