Oh Gosh, Not Again About Bootloaders! ;-)

[distantvoices]

You all ... hm, may be not all, indeed ... have read about writing bootloaders, have written yourself one with or without success just to feed curiosity and surely felt some proud prickling under your skin upon former case.

I think, writing such a thing is a good point to start off. It gives one a feeling of what you may have to trade with further: all these initialization routines, first introduction to asm programming (yes, you have to use goto in asm regardless what they tell you in hll programming course - nassi shneiderman in mind), some pmode stuff, not to forget: The first Global Descriptor Table. And then, this not so dramatic step to change from real mode to protected mode: nothing more then three commandses. It is like switching light on or off. The more, writing a boot loader is a pretty good exercise for bug tracking in asm code as well as an introduction to research methods like those used in universities.

But one comes to the point where interest is drawn to other things, which can be realizend in hll langueges like c - I think of linked lists and sorts. One comes to the point where his self written pboot loader lacks the capability to boot the kernel in a proper way due to the size of that d(a)mned thing. Mybe he decides then to put boot loader development aside and draw attention to kernel development - and to use a given boot loader. F. ex. grub.(which is not, as the young legend claims, the holy grail, but this belongs to an other story. Never te less it comes near to it)

I don't want to convince the ones amongst us to use grub, who work on custom bootstrap code. Shall they write their boot loaders, since it is a Gosh-this-Light-Blends-D(a)mn-So-Does-The-Hare-Run-Experience to get it do what it is expected to.

I think it is wise to use present and well tested ressources for working further and AFTER having explored the file system world and the disk driver world continuing with the boot loader.

But it is better to continue work on the custom boot loader after having gained a certain amount of experience in programming: whilst working on the kernel internals.

But what I can not stand at all circumstances is stubborn, blindfold thinking like:

->using f. ex. grub shortens the impression my kernel draws upon other people.

->using f. ex. grub is crap entirely.

->i want to write a bootloader better then grub (or similar).

this is what they call "prata skitsnack" in sweden.

one more thingy: there often comes an "I didn't intend to induce a discussion about bootloaders...". This is how things run along when a group of people comes together. No one can forbide another one to say what he/she thinks. Let it run. discussions are normal in groups.

Now, feel free to discuss and elaborate the topic: "Writing a custom boot loader - Pro/Contra".

have a nice day, stay safe and enjoy life )

[_mark]

Well put. One misconception about bootloaders that I keep reading over and over though is it has to be written in ASM. This just is not true. Mine is 100% pure C - MBR and all. Just like many of the example C kernels out there, it just uses a small stub to get me into C. And even that stub can be dispensed with, but I find the code more readable with it.

_mark()

[Pype.Clicker]

Well put. One misconception about bootloaders that I keep reading over and over though is it has to be written in ASM. This just is not true. Mine is 100% pure C - MBR and all. Just like many of the example C kernels out there, it just uses a small stub to get me into C. And even that stub can be dispensed with, but I find the code more readable with it.

_mark()

i would be interrested to see how you actually set up a stack in pure C or call INT13h to read the disk and load the kernel ... I would also be interrested in knowing which free compiler you've used to do this, as the few ones i know are limited to 32 bits ...

BTW. i think one of the main reason why i would recommend the use (or the support) of Multiboot format (and therefore the compatibility with GRUB) is that it means your end-users will be able to boot your kernel without actually modifying their boot system if GRUB is already installed ... that's what grub is all about, after all ...

Even if you do something as flexible and powerful as GRUB to load your own kernel, there is little chance you can make it load a lot of other people's kernel including Linux and (correct me if i'm wrong) DOS/Windows partitions ...

[_mark]

Even if you do something as flexible and powerful as GRUB to load your own kernel, there is little chance you can make it load a lot of other people's kernel including Linux and (correct me if i'm wrong) DOS/Windows partitions ...

.

Why not? It is just a computer - I hate to put it this way, but I can pretty much make a computer do anything I want. This is easy stuff and it still amazes me each day that I get paid to do it. Real work is those guys out there putting in power lines and stuff.

I'll make the code available when I get a chance.
_mark()

[Pype.Clicker]

i'm not doubting of your coding skillz. I just doubt you can write a bootloader that will be compatible with a kernel i've not finished yet if we don't both agree to comply with some standard. Multiboot Header *is* a de facto standard and it has a good reference implementation (GRUB)

If your Os has a custom bootloader, there will come a time (soon or late) where you'll have to make a multiboot-compliant trampoline that will fake your custom bootloader and let somebody with an installed version of multiboot start your OS without messing up his HDD (at least, that's what i think ...)

Now, maybe i'm knowing GRUB too bad and that it would be able to detect that i have a non-compliant bootloader on partition XYZ and load it just as the BIOS would have done if it was the only bootable partition it had found ...

[Whatever5k]

I agree with Pype: if you want to make your bootloader compatible with other/many OSes, you *need* to use a standard, that is multiboot.

[_mark]

Is this another dare? They said you cannot write a bootloader in C. Now if we want our C bootloader compatible with other/many OSes, we *need* to use the multiboot standard. Hmmm...I may have to take that dare also....

_mark()

[Perica]

..

[_mark]

You can get the docs with the grub souce download. But it is not that big a deal, and only a standard for people that use Grub. Windows is not Grub (or multiboot) complient. Neither is Solaris, DOS, OS/2, NeXT, PALM, CE, or probably any other OS you have heard of except for linux and freeBSD. And actually both of those are patched kernels. Depending on your linux distribution, you may or may not get GRUB. And for the ones that do come with it, it is an option. I still use lilo.

Standard - I think not. But I have to agree that it is a good idea and if there was a standard it should be something like multiboot. But face it people - it is not a standard (not yet anyway).

_mark()

[distantvoices]

To my knowledge, grub can load windows - by loading first the windows loader, which is located on the windows partition - something like chain loading? I have it installed on my workstation, and it rocks.

lilo can do this too, according to my experience.

NeXT ... wasn't it this os that came along with a computer in a Box - NeXT Step?

[Whatever5k]

AFAIK, Linux doesn't support Multiboot. It's just that GRUB can load Linux + multiboot (+ many other things).

[Tim]

_mark(): at least Multiboot is a standard, which is more than can be said of those others you mentioned. AFAIK it's the only standardised boot method for IA-32 machines. Of course, other architectures have long had their own standard boot loaders. Perhaps with GRUB and Multiboot, the PC is finally catching up with all these other architectures.

[_mark]

My point was it is not a standard unless people use it. It is kind of like having a law noone obays and noone enforces. What good is it? One day Microsoft will introduce a standard, then pretty much everyone will comply - who knows it could actually be multi-boot, but I doubt it.

Now - like I said earlier, I'm all for standards and think multiboot would probably be a good one. I might even add it to my bootloader, but I'm in no rush to do so. I have better things to do them implement a not-so-standard standard.

_mark()

[Tim]

People don't have to use something for it to be a standard. Multiboot is a standard because somebody sat down, wrote about it, called it a standard, and made public what they had written. I have my own standard -- the RDSK in-memory file system -- which (to my knowledge) has only ever been used by one person other than myself.

If the world suddenly stopped using ISO C, would it stop being a standard? Would all the standards documents evaporate? No.

PS: Microsoft is unlikely to have any involvement in boot loaders other than their own, and they're unlikely to document OSLOADER, unless for some reason the courts demand that they do. They have no reason to do so, and it would be more work (i.e. more to support) on their part.

[_mark]

Out of the many definitions of standard, the one from Webster's that we are talking about is:

"Something, such as a practice or a product, that is widely recognized or employed, especially because of its excellence. "

It is still debateable if multi-boot fits this definition, but I would doubt youe RDSKIMFS is a fits this definition.

Let's not confuse a standard with a document. Any old monkey can write a document, but unless it is "widely recognized or employed", it can hardly be a standard.

_mark()