To GRUB or not to GRUB...

[Solar]

Ever since I found out about GRUB and the Multiboot Specification, I wonder:

Why are so many people going through the pain of writing their own bootloader (including A20, protected mode etc.)?

* don't know about GRUB / Multiboot;
* not-invented-here;
* want to learn how to do a bootloader;
* GRUB is deficient in some way;
* other?

Especially the latter two I would like to hear...

[distantvoices]

Mainly because it is a good point to start with. It gives a clue about what comes along with os dev and it shows also the culprits and caveats of asm programming. So, I wouldn't bother: If someone wants to stuff together a bootloader: shall he/she feel so free to do it. It is a good learing experience. ?'ve written/stuffed to gether a boot sector too, before I took grub to do the booting further, because I didn't want to spend time programming file system support in the boot loader thing. I didn't conider it a pain.

So I don't tell anyone it is a bad thing to write a boot sector.

hmmm ... being lazy to look in a dictionary ... what is "deficient"?

[Pype.Clicker]

for me it's just because i wasn't aware of the existence of GRUB when i started (about 5 years ago ) I also didn't worried about bootloaders for a long time since i had a dos-based loader (a kind of loadlin.exe) instead of a "real" bootloader...

one day, maybe i'll migrate to GRUB, but so far, i don't really see the advantage of doing so as i have something else working

[Solar]

what is "deficient"?

buggy, broken, screwed up, unusable... I'm not native speaker myself so I might even been wrong.

i don't really see the advantage of doing so as i have something else working

Well... my "kernel" as of now doesn't do anything beyond printing "Hej" to screen and going into an infinite loop.

But since it's Multiboot compliant, it can be booted from various file systems, and even across a network...

And I don't have to bugger the BIOS for various settings - GRUB has them stored away in a comfortable data structure. Live is good.

[distantvoices]

By that time five years ago, GrUB has of course been kinda unmature, hasn't it?

[nullify]

Not using GRUB allows you to do things like enable paging before even passing control of the bootloader to the kernel, or the ability to run 16-bit real-mode code such as a vga mode switch without having to do it within a v86 monitor in your kernel. Granted, these kind of things are not really necessary, but it does provide a degree of flexibility that you probably won't try with GRUB. (Well, you could modify the GRUB source, but adding or modifying your own functionality may compromise its multiboot compliance).

Regardless, I use GRUB because I can't be bothered with relatively obscure bits such as enabling the A20 gate -- these kind of skills are confusing to pick up, and probably not useful anywhere else. In addition, you get all sorts of functionality in GRUB that would take lots of extra coding time if you rolled your own bootloader.

A note on multiboot compliance: it really doesn't mean that much at this point IMHO, because its not such a widely used standard (e.g, GRUB is the only multiboot compliant bootloader I know of).

[Tim]

GRUB is brilliant in 99% of cases, because it gives you so much for free. I started using it when I found one too many bugs in my own loader. Even if you do manage to trace an OS bug back to GRUB, there is a team of developers who can fix it.

[Solar]

Not using GRUB allows you to do things like enable paging before even passing control of the bootloader to the kernel, or the ability to run 16-bit real-mode code such as a vga mode switch without having to do it within a v86 monitor in your kernel.

Am I mistaken or can you request screen resolution from GRUB by setting some flags?

A note on multiboot compliance: it really doesn't mean that much at this point IMHO, because its not such a widely used standard (e.g, GRUB is the only multiboot compliant bootloader I know of).

That might change, and in the long run it will change once we feel we're ready to start porting our stuff to other platforms.

[The Pro from Dover]

When I first started learning about boot loaders, years ago, GRUB wasn't around; more recently, I have continued to work on boot loaders for the sake of learning more about it. In my later designs, I certainly intend to use GRUB instead of my own.

I had been writing what I hoped would be a detailed tutorial on the subject, (LOIS), a project which has been stalled for some time. I have considered writing a multiboot-compatible version of LOIS as a final part of the tutorial series, but more likely, I will simply drop the project; it is frankly far more time consuming and difficult than it reall is worth. Instead, I think I'll move on to writing GLOAT, a tutorial on working with GRUB. I'm not sure; I had gotten some positive feedback on LoIS, but the Funnelweb tool has proven more cumbersome than I anticipated, and the whole project has become rather sluggish. Futhermore, I soon will no longer have the Mindspring account, and will have to set it up on a new web host.

[nullify]

Am I mistaken or can you request screen resolution from GRUB by setting some flags?

Supposedly, yes. The multiboot specification allows for this in the graphics fields of the multiboot header. Unfortunately, I've never quite gotten this to work right in GRUB. After inspecting the GRUB source, it appears that GRUB only supports this for Linux at the moment. I could be wrong, though... please tell me if you know how to do this!

A note on multiboot compliance: it really doesn't mean that much at this point IMHO, because its not such a widely used standard (e.g, GRUB is the only multiboot compliant bootloader I know of).

That might change, and in the long run it will change once we feel we're ready to start porting our stuff to other platforms.

GRUB is not currently ported to any other platform other than Intel x86 that I am aware of. As you can see, many open-source systems still use their own bootloader in spite of the existance of GRUB. There's probably not any compelling reason for proprietary operating system providers to start following multiboot as a standard, either. So don't get your hopes up too high. That said, multiboot is probably the only breed of its kind around, so I guess you are better off adhereing to some standard than no standard at all.

[Chris Giese]

A note on multiboot compliance: it really doesn't mean that much at this point IMHO, because its not such a widely used standard (e.g, GRUB is the only multiboot compliant bootloader I know of).

I wrote a Multiboot loader that works from the DOS command line. It has bugs in the XMS code, which I discovered by writing a Multiboot graphical test kernel:
http://my.execpc.com/~geezer/temp/mbtest.zip
("Danger! A magazine has been discovered in Marketing!")

It loads the kernels I've written, and it loads the Wild Magnolia kernel, but it crashes when I use it to load Mobius or Tabos.

Multiboot may not be the best standard (I have a list of things I'd do differently), but it's the only one out there.

[Tim]

Any chance you could make your DOS multiboot loader public? I'd been meaning to write one for a while but never got round to doing it. It would be really useful (at least for myself), as I could have users unzip the Mobius file to their FAT hard disk, reboot into DOS, and run your loader, without having to play with boot sectors. Of course, the advanced users could use the built-in installer which creates a proper GRUB floppy.

[Chris Giese]

Any chance you could make your DOS multiboot loader public?

Sure. I didn't find the problem with my XMS code, but I think I have a work-around for it. There are a few other things to fix, though. Give me a week; I'll post here when it's up.