OSDev.org

I am going to make a multiboot loader with a BSD license (which _should_ also be better than GRUB). If anyone's interested in helping (or just wants to know about it), e-mail me (xsadar) at users.sourceforge.net.

A while back I registered a project for it on sourceforge, calling it The Anteo System (http://sourceforge.net/projects/anteosys/), but I haven't done anything with it yet. I was wanting to get people to help first, and I didn't want to get people to help until I thought I had time to work on it, which I think I do now.
To be honest, I don't really like the name The Anteo System very much. I prefer the name Antium, although I'm open to other suggestions as well. I think because I haven't done anything with it yet that sourceforge will be willing to delete the old project. Then we just create a new one with the new name.

Dont really want to help. i have enough work as it is, with a full time college course, 1 os to develop and a web site to maintain.

However i would like to make one request.
In Grub, you can load modules but if the module isnt present, im told by CarbonBased, that Grub will complain and theres no way to stop the complaint. But im sure, and ill have to check this, the multiboot standard sets up a table or list of modules that have been loaded and where, thus if a module wasnt loaded then that fact that it failed to load could be detected. So im requesting, can it be made that your multiboot loader will not complain, or be configured in the config (presuming it will have one) to now complain at the absense of modules.

Its basically for my me so i can load a module without any problems because of what im using the module for (a config file ) but im supprised grub complains and cant be told to go to hell if a module is not present.

Thanks
Moose.

I remember that thread. That's one of the things that I was considering. It makes sense to me that you should be able to flag some modules as optional, meaning that if it's there, load it, and if it's not, ignore it. So I'll keep that in mind.

MBLOAD is public domain; you can rip it off if you want:
http://my.execpc.com/~geezer/temp/mbload.zip

It doesn't support kernel or module command lines, MENU.LST file, or GZIP compression yet.

Good luck with your project. GRUB is nice, but there's a lot of room for improvement:

My GRUB gripes:
1. Clear the EFLAGS.NT bit before jumping to the kernel; otherwise
   the first IRET will cause a task-switch instead.  (GRUB 0.90
   leaves this bit set, I think.)
2. Also in GRUB 0.90, the code in 'mbchk' no longer agrees with
   the rest of GRUB, so it's possible to make an unbootable
   kernel that passes mbchk.
3. Get rid of support for non-Multiboot kernels. If you want to
   boot Linux with GRUB, then make Linux Multiboot-compatible
4. Speaking of warning messages: something more informative than
   "Error 28" would be nice.
5. Please avoid the use of autoconf, automake, and scripts to
   "configure" the source code before compiling it. All of this
   makes it difficult to build under DOS and Windows.
6. I don't know if the GRUB shell has something like an "ls"
   or "dir" comand, but it would be nice.
7. When the kernel file format is ELF, GRUB ignores the a.out
   kludge if it's present. This is confusing. At the very
   least, there should be a warning message.
8. Maybe support 1.68 meg floppies?
9. Isolate user interface code from the rest of the bootloader,
   so you can have different UIs: menu, bash-like shell, GUI,
   COMMAND.COM-like shell, GRUB-like shell, listbox, etc.

My Multiboot gripes:
1. Getting the load address from the ELF LMAs is a mistake.
   ALL kernels, regardless of file type, should be made to
   use the a.out kludge. The distinction between ELF and
   non-ELF kernels is pointless and confusing.
2. Information stored by the bootloader in conventional memory
   for use by the kernel -- the Multiboot system info structure,
   module tables, kernel and module command lines -- should be
   stored compactly and aligned on a page (4K) boundary.
3. Maybe remove the load address field from the a.out kludge.
   (Is there a compelling reason to load a protected mode
   kernel at an address other than 1 MB?)
4. The aout kludge contains physical addresses, which are
   difficult to calculate at assemble-time. Change all of
   these (except the load address) to virtual addresses.
5. Clean up the enormous holes and assumptions in the
   Multiboot spec.

really, whats needed is a revision to the multiboot spec (which i think was being worked on at some point.... by the grub ppl)...

my gripe;
grub will ignore your aout kludge if the bit in the grub flags saying you have

grub says.. hmm we have a mb header.. but its not an elf... i wont load it.
hellooo! we have an MB header.. just use the aout kludge! (ok i spent ages once trying to work out why my image wouldnt load just to find the damn aout kludge flag.....)