
How to write a simple operating system - motxilo
http://mikeos.berlios.de/write-your-own-os.html
======
a-priori
While it's cool and all to write your own bootloader, this means you have to
deal with a lot of the really ugly bits of x86/PC architecture... like the A20
gate, for example (if you don't know what that is, count yourself lucky).

Instead, I suggest using GRUB to boot your kernel image. It leaves you in
32-bit mode and a relatively sane state. It's not hard to write a loader file
(in assembly) which contains the multiboot header and an entry point.
Presumably you'll want to set up a basic C runtime environment and call your C
"main" function.

<http://wiki.osdev.org/Bare_bones>

~~~
jacquesm
Writing your own bootloader is actually an excellent exercise in getting to
know the intricacies of the memory mapping on the PC architecture. After
you're done you can always decide to go for a read-made one but rolling your
own is definitely useful if you plan on writing your own OS.

NIH applies like always, but if you plan on taking control of the machine you
might as well begin at the beginning. Rolling your own BIOS would be a step
too far I think :)

~~~
a-priori
I suppose it depends what you want to get out of it. There's certainly
educational value in going as deep as you have the stomach for. But, for me at
least, learning the specifics of how to get a processor on the PC architecture
into a usable state gets tedious fast.

~~~
m_eiman
If I were to write a basic OS, I'd do it for one of the microcontroller kits
that are available, e.g. <http://www.pjrc.com/teensy/> or something similar
with an ARM7 cpu. Having a cleaner CPU architecture than x86 is bound to save
a lot of headache...

~~~
jacquesm
The biggest challenge I found was not to adapt to CPU architecture headaches
but to get to the point where the OS was self hosting its development. That
took considerably longer than I ever bargained for and at the time virtual
machines were pretty much non-existent so djgpp was used to bridge the gap. An
edit-compile-test cycle of several minutes + a hang or so quickly eats up the
days.

~~~
m_eiman
_An edit-compile-test cycle of several minutes + a hang or so quickly eats up
the days._

That's why the micros are an interesting option, they're running on real
hardware but can be flashed in seconds and debugged in realtime with a JTAG
cable. Very convenient. But on the other hand they tend not to have much
storage or network connectivity, so it depends on what you're interested in if
they're the right choice. Blinking LEDs and controlling step motors is always
fun, though!

~~~
leoc
<http://pandaboard.org/> and <http://beagleboard.org/> to the rescue I think,
though there's no free software that supports Pandaboard (OMAP 4430/Cortex-A9)
JTAG yet.

------
steveklabnik
I also have a bare bones OS project up on GitHub:

<https://github.com/xomboverlord/xomb-bare-bones>

It's a bit of a niche inside a niche: it explains how to set things up to
write an OS in D. This was extracted from the OS that my friends and I started
a while ago, that's now two of theirs' PhD research:

<https://github.com/xomboverlord/xomb>

------
senko
If you're into building custom OS' but not interested in doing the lowest
level bits (bootloader, fiddling page table bits, worrying about the processor
details, etc), using a pre-existing microkernel and building whatever you want
on top of it can be interesting.

I used my diploma thesis as an excuse to build a toy OS on top of a L4
(L4Ka::Pistachio) microkernel. It provides the basics, incl. IPC and VM
building blocks, and a straightforward C/C++ API, and you can do the rest
(there's also a number of things built on top of it that you could mix'n'match
- i just implemented most of my userspace stuff because that was what I was
interested in).

Some links (haven't been in touch for a few years, I don't know how up to date
they are):

L4Ka project: <http://os.ibds.kit.edu/1953.php> OKL3 (successor to Pistachio,
as far as I can tell): <http://wiki.ok-labs.com/> Iguana, a set of components
to be (re)used on top of L4:
[http://www.ertos.nicta.com.au/software/kenge/iguana-
project/...](http://www.ertos.nicta.com.au/software/kenge/iguana-
project/latest//) Misc L4 resources: <http://www.l4hq.org/projects/os/>

If anyone's interested, I could try to find my old code and put it on GitHub
(it's a combination of MIT and GPL licenced things).

~~~
wagerlabs
Please, do find!

------
Sapient
I found this invaluable when writing my own small OS.

<http://www.jamesmolloy.co.uk/tutorial_html/index.html>

He includes a lot of details, and seems to try to do things "The Right Way" as
much as possible. (Not that I am a good person to judge that)

~~~
Rusky
This is most definitely the best (existing) tutorial for getting started in
kernel development. It explains how to implement a small unix-like kernel,
focusing on interesting problems like virtual memory, multithreading and
system calls rather than fiddly details of the x86 architecture from 20+ years
ago.

------
alexwestholm
The project seems to be dead these days, but if you're interested in writing
OSes, take a look at the Flux OSKit:

<http://www.cs.utah.edu/flux/oskit/>

OSKit aims to be a set of libraries that dramatically lower the barrier to
entry on OS development.

------
Rusky
There is no reason to write your own x86 bootloader- it's just an exercise in
abstracting away the most brain-dead ISA on the planet.

What you should do instead is write the kernel and just load it with GRUB. It
allows you to immediately jump into the interesting stuff that makes your
kernel unique, makes it easy to test on real hardware without getting a second
machine, and makes it possible to dual-boot with it if/when you get that far.

I haven't tried this, but it might be fun to write a kernel for some other
system- some ARM device, maybe. Any kind of bootloader would be infinitely
less encumbered with x86's layer upon layer of compatibility stuff.

------
coderdude
This is where floppy disks come in handy. Burning an ISO to a CD for each
round of testing is a pain and wasteful. When I dabbled into this years ago I
was lucky enough to still have a floppy drive.

~~~
slug
well, you can always use virtual stuff, xen, virtualbox, qemu among others ?

~~~
coderdude
A great suggestion of course. I do admit that it didn't immediately spring to
mind (or rather, didn't spring to mind at all until I read your response).
Honest question: is it possible that you might run into difficulties getting
your low-level OS to function properly in a virtualization, or has the tech
come along enough to where this is essentially a non-issue?

~~~
Rusky
In my experience VirtualBox works okay for low-level stuff, but it's
impossible to debug with. qemu and bochs are much better tools since you can
actually debug your kernel.

------
paulgerhardt
Or another for AMD64:
[http://code.jeffkent.net/trac/shiny_moose/browser/trunk/kern...](http://code.jeffkent.net/trac/shiny_moose/browser/trunk/kernel)

