LtG wrote:
The crux of the problem (for bootloaders) is that you have to store a pointer, in the bootloader itself, to the second (next) stage. In the FAT explanation you gave that would be a hardcoded "first (and second) entry in FAT". Personally I'm not a huge fan of that idea because now you are leaking bootloader stuff into the FS proper.
The FS should not (ever) care about bootloaders. It's a FS, and it should do its job the best it can, without caring about anyone or anything else.
While I don't disagree, in my explanation I was primarily focusing on how MS-DOS actually did this, rather than on judging if it was a good approach or not. The truth is, there really
are no good approaches when it comes to the PC standard, because the PC standard was designed for a bygone era when booting from cassettes or floppy disks was the norm for personal computers (the original IBM PC had a built-in cassette port, and AFAICT the only type of disks the BIOS supported was 5 1/4" double-sided, double-density floppies with a 360KB formatted capacity), and no one thought twice about mixing things like that. It is only with the benefit of hindsight that this seem a bad idea - even in the mainframe world, this wasn't that uncommon an issue at the time.
It is unfortunate, I agree, but it is what we are stuck with when talking about PC compatible systems. For hard drives and more modern data storage such as SSDs, we have a few better options, paramount of which being to set aside a small, separate partition for the boot loader; AFAICT this is what Windows now does (the NTLDR partition), and it is also one of the options for GRUB. However, floppies don't have MBRs or partition tables.
LtG wrote:
The simple fact is that bootloader runs 0.0001% of the time and 99.9999% of the time the FS proper is being used. Allowing the FS the most freedom to do its job is paramount. In practice for most (if not all) FS types this distinction might not make much of a difference, but at least I'm designing my own FS from the "perspective" of not caring at all about bootloader/bootsector and contain the bootstrap problem into the loader.
That's the part that is frustrating to me and many others here, because writing a boot loader is not part of writing an operating system - it's a distraction from it. Too many newcomers assume that they need to write one, but the fact is that there is nothing to be gained, or learned, from doing it.
For an OS developer, writing your own boot loader is a purely a waste of time and effort.Conversely, if writing a boot loader is your primary goal, you'd be better off studying the
Multiboot Spec and how to implement that rather than working with floppy disk images and FAT file systems.
While I
do intend to do just that, I don't see it as part of my OS work at all - Bereshith is a completely separate project only tangentially related to either Kether OS or the Kelephstis hypervisor.
I am willing to help the OP, despite this, but... well, I have no doubt at all that this is something that will be regretted as lost effort later.
The insistence on 'writing everything yourself' is false fire - it isn't possible, because you still need to use the BIOS for critical parts of the boot sequence, and by the time your code starts, a lot of other peoples' code had
already run. And yes, a fair amount of some modern BIOSes - especially UEFI ones - is written in C, albeit with a compiler that can target real mode (which GCC can't).
My goal with VERBUM was to give enough information to show how the loader works, and dissuade others from writing one once I'd made it clear that, no, it is not something you need to do or even should be doing as part of an OS project. Embarrassing mistakes aside, it is clear that I failed at that.
TL;DR: Boot loader != operating system.