OSDev.org

Hi, i'm new to OS development and did loads of tutorials on it. To bad there arn't much (maybe just 1) tutorials that make a complete c++ os from scratch.
I would like to make an OS from scratch where i will be able to create the kernel in c++. I found tutorials in loading c++ kernels from asm, these had mostly to do with a special file type like PE and ELF (isnt it possible with just a .bin file without file type?), loading these filetypes were way to advanced for me. I just want to create a OS that hasnt much functions but could just load a c++ file compiled by gcc and linked ( not sure what linking does though).
What steps should i do to create this? A bootload is needed for sure , and I know a GDT would have to be loaded and Protective mode I guess.

Please answer...

If you're loading something compiled into C++, you'll probably need to use ELF or PE. The ELF format isn't very complicated, and you only need to worry about two structures while loading. There are plenty of tutorials for C++, definitely not just 1, and they cover this type of thing. You could always use GRUB which will load your kernel for you.

GreenPiggy wrote:Hi, i'm new to OS development and did loads of tutorials on it. To bad there arn't much (maybe just 1) tutorials that make a complete c++ os from scratch.

That wouldn't really be your os, then. There are tutorials about in C++, and loads in C. You could simply take C tutorials and add C++ stuff (overloaded new and delete, constructors, template classes and so on...).

I found tutorials in loading c++ kernels from asm, these had mostly to do with a special file type like PE and ELF (isnt it possible with just a .bin file without file type?), loading these filetypes were way to advanced for me.

PE or ELF (I personally recommend ELF) is the way to go. If you use flat binary, you will find that your final kernel a) has problems with guessing where things are located and b) takes up loads of disk space due to zeroed sections being stored on disk.

The ELF loader part of my boot loader takes up 70 lines of ASM including comments and paragraph spacing to make things more readable. You could do it in a lot less. If loading and ELF file is too advanced, what happens when you get beyond "tutorial-stage" and want to develop drivers, for which you may only have a datasheet or reverse-engineering tool?

I just want to create a OS that hasnt much functions but could just load a c++ file compiled by gcc and linked ( not sure what linking does though).

If you don't understand what a linker does, you need to practice some more applications programming first.

What steps should i do to create this? A bootload is needed for sure , and I know a GDT would have to be loaded and Protective mode I guess.

As JohnnyTheDon says, you could use GRUB, but don't do that just because you are afraid of writing an ELF loader - you'll have to do that to load apps eventually anyway and I can't help feeling that in your case, practicing by writing a boot loader first could be a Good Idea(tm).

Cheers,
Adam

First, thank you very much for the quick answer. Second thanks for the good replies.
I now know i really need the ELF format and can't stay with flat files. The point I don't like using GRUB is because at the moment im working on Windows, and i got a bugged version of GRUB on my dual booted computer (Vista and Ubuntu). Not having a floppy drive is annoying too, there isnt much support of USB drives on GRUB. But thanks alot!

The point I don't like using GRUB is because at the moment im working on Windows, and i got a bugged version of GRUB on my dual booted computer (Vista and Ubuntu).

Then don't use GRUB-write your own that better suits your needs

Not having a floppy drive is annoying too, there isnt much support of USB drives on GRUB

You dont need a drive. Just an image tool and a program to create a bootable CD ISO from it is usually all that is needed to run the system in an emulator, virtual environment, or on real hardware. I personally use Magic ISO. (Although I'm going to have to switch soon as Im running out of FDD space and Magic ISO only seems to support CD floppy emulation)

Writing a C++ kernel is practically the same as a C kernel, except that it requires some extra support. This way you'll need to loop and call the global and static constructors (and possibly destructors, if they're even needed when shutting down the kernel) defined in the linker script. You'll also need to add some thread-stuff about static variables if I remember correctly, a few minimalistic functions for GCC (if that's what you're using anyway) and a few variables. You'll also need to use 'extern "C"' commonly to interface between ASM and C++, it's not required, but it will give C++ symbols a C-symbol name (if I'm saying that correctly) and make it much easier to interface them between the two languages.

Like the wiki says, a lot of C++ features will come for free (such as classes, inheritance, templates, etc...) but there will also be features that will never be supported or will be very hard to implement. As far as GRUB goes, you just tell it to load your C++ kernel instead of your C kernel. An ELF kernel is probably the best, as said before me.

Using flat binary works perfectly well, check the manual for gnu linker on how to write linker scripts which might be useful. The logical location for the loaded code has to be fixed (or the code has to be truly position independent), for executables this is normally the case anyway. Zeros don't have to be stored in the file since you could put the text and data sections together and add symbols indicating where the bss section is (so it can be zeroed out by the crt-startup).

For the kernel the benefits of ELF/PE is really minor. IIRC linux uses a zipped flat binary so why shouldn't it be possible to use a flat binary? I use flat binary myself...

You can use also the older a.out object type instead of elf or coff with the DJGPP.
Look here at the make process: http://www.henkessoft.de/OS_Dev/Bilder/make_process.PNG

skyking wrote:Using flat binary works perfectly well, check the manual for gnu linker on how to write linker scripts which might be useful. The logical location for the loaded code has to be fixed (or the code has to be truly position independent), for executables this is normally the case anyway. Zeros don't have to be stored in the file since you could put the text and data sections together and add symbols indicating where the bss section is (so it can be zeroed out by the crt-startup).

For the kernel the benefits of ELF/PE is really minor. IIRC linux uses a zipped flat binary so why shouldn't it be possible to use a flat binary? I use flat binary myself...

Linux at one time used a flat binary I'm sure, but these days it uses the ELF format. It's compressed, with the decompressor code prepended.

Perhaps the biggest advantage of the ELF format early on in a kernel is being able to get the exact layout you want, including adding all kinds of extra sections, and being able to map the kernel code to read only pages in memory, while the data can be read/write.

Newer versions of binutils can do compression of individual sections of ELF binaries. I believe it is zlib based compression, but you'll have to check the documentation for specifics. It's something that must be compiled in, of course, and I believe it's still disabled by default, but I haven't looked at that in a while.

quok wrote: Linux at one time used a flat binary I'm sure, but these days it uses the ELF format. It's compressed, with the decompressor code prepended.

Actually my linux (2.6.26) kernel does not look very much like an elf (starts with EA 05 00 C0), so I don't think that's correct.

skyking wrote:

quok wrote: Linux at one time used a flat binary I'm sure, but these days it uses the ELF format. It's compressed, with the decompressor code prepended.

Actually my linux (2.6.26) kernel does not look very much like an elf (starts with EA 05 00 C0), so I don't think that's correct.

This is getting off topic, but look at the linker script that is used. For i386, this is arch/x86/kernel/vmlinux_32.lds.S, or for x86-64 it is arch/x86/kernel/vmlinux_64.lds.S. The bare kernel binary (vmlinux) is indeed an elf file. It is post-processed after linking, which if you did 'make bzImage' includes bzip2 compressing the kernel and adding setup and decompressor code to the front of the kernel. Check arch/x86/boot/Makefile for details.

quok wrote:

skyking wrote:

quok wrote: Linux at one time used a flat binary I'm sure, but these days it uses the ELF format. It's compressed, with the decompressor code prepended.

Actually my linux (2.6.26) kernel does not look very much like an elf (starts with EA 05 00 C0), so I don't think that's correct.

This is getting off topic, but look at the linker script that is used. For i386, this is arch/x86/kernel/vmlinux_32.lds.S, or for x86-64 it is arch/x86/kernel/vmlinux_64.lds.S. The bare kernel binary (vmlinux) is indeed an elf file. It is post-processed after linking, which if you did 'make bzImage' includes bzip2 compressing the kernel and adding setup and decompressor code to the front of the kernel. Check arch/x86/boot/Makefile for details.

Well, just because you have elf files in the build process does not make the end result an elf file (I've got the end result here). And for the advantage of using the information in the elf headers to determine where the kernel will be located is not only an advantage since it's requires more of the boot loader and the kernel. It's more than just loading the ELF sections at the correct location to take the advantages - the kernel has to be flexible enough to be able to reside and work on any location as well.