So, You Want to Write an Operating System

I’ve always been curious about how things work. When I was little, I annoyed my parents with millions of
questions. Why is the sky blue? How does water come out of the tap when you open it? Maybe I was born without the
mental switch that lets you be happy with using something, without trying to figure out how it works.

As I grew up, I became interested in writing software, first as a hobby, then as a professional career. Naturally,
unhappy with writing applications on top of a black box designed by someone else, I wanted to work on operating
system development, and advance the state of the art.

I had written real-time monolithic kernels for the

Motorola 68000
and the
Intel 386
as a hobby, without any new idea in
them. I started thinking about designing my own operating system around 1996. Before I looked on the internet, I thought
I was the only one with such a preposterous idea. After all, the bases were pretty well covered.

Windows had a lot of problems, but it got the job done. The power users, or the ones who wanted to feel special, had
BeOS, Linux and MacOS. The server space had all things Unix, and NT coming up to smooth things over. The embedded
space had lots of real-time kernels, none really special, but people made products with them that work in the end. Why
would’ve anyone wanted to invest time in OS development anymore? I looked online anyway.

I was shocked to find a LOT of projects.
Literally hundreds. I was thinking I should stop right then.
Certainly, out of those hundreds of projects, someone was already doing what I was thinking about, and there was no
point in duplicating the effort. I looked further and was surprised to see that all of them, except for a couple known to
OSAlert readers, were stuck at “dream stage” or “bootloader stage”. Most of the time, the creator was gone or idle,
replaced by another set of equally inactive people. Sometimes the sites were
flat out unmaintained for a couple of years
already. Online ghost ships.

Stuck in dream stage meant someone decided to create an
operating system that would run Windows,
Linux and MacOS applications all under one architecture, created a site, and explained how this is really a good idea that
nobody has done before. Nobody had seen the opportunity. Then, the person realized how complex the
dream was while being pointless, and left without a forwarding address.

Stuck in bootloader stage usually was expressed by a site starting with a goal such as, the next generation
microkernel-based operating system. The site offered a bootloader, the small piece of software responsible for loading
the kernel, for download. Nothing spectacular. It would read the kernel and jump into it, except there would be no kernel
to be found. Somehow the author thought that if they could write the bootloader, the kernel would be a piece of cake, or
something
. Then somehow disappeared.

In this context, the few exceptions were like Las Vegas, a city of lights in the middle of a desert. I’m thinking of
AtheOS and SkyOS.
Today you can add OpenBeOS to the list. I personally hope
we can add Syllabe to it soon.

How come they have a working system where others are stuck in bootloader land? Are they smarter? Do they
know something the others don’t? Well, considering AtheOS was written by one guy during weekends and leisure time
over the course of only four years, the smart part probably doesn’t hurt. Let it sink for a second: One guy.
Hobby. Four years. Full kernel. Quite a few drivers. Graphical interface. Applications. One guy.
Okay, let’s proceed.

Back to the story of my life. I decided to go ahead with my project. I met the right people for it in 1998. We decided
the idea was new enough to deserve a company to develop, market and support it. Probably it would be closed source,
as it is now. The goal from day one was well defined. Today, we have a full OS, graphical interface, telecom stack, and
real world applications, portable across several processor architectures. Around fifty people bang on it full-time. To
paraphrase
Joel Spolsky, our marketing department
goes out to say that it cures baldness and heart attacks. If you buy
two, neither is free but you get a really cool pen. All that really matters is that customers say it works.

Projects that work out to completion share common characteristics. They are in no way a recipe for success, but
they form a prerequisite.

If you’re thinking of starting, or working on, a new OS, not making decisions will leave you with a disaster. A site
without a forwarding address. The umpteenth bootloader. Yet another TakeThatLinus!OS that aims to take over the
mindshare of all open-source developers.

You can argue that you are going to work on it as a hobby, so I should shut up and go back to my company. What
the hell am I doing writing this on a Saturday, instead of making plans for my business, right? Once you make
these decisions, your project will be a lot more fun to work on. Taking out the frustration early on will make a much better
use of your free time, and if we’re lucky, we will be granted with a new project with the quality of AtheOS. It will be
pointless for most of humanity, but they don’t read OSAlert in the first place.

I will not offend you by mentioning commonplace ideas in this article. You already know you need lots of time, lots
of patience, lots of datasheets and books, and the capacity to debug with your hands tied in your back.

Choose your own camp

You need to decide early on what category you are in.

Are you a low-level hacker who wants to write a fully working OS
in assembler, because those damn C people don’t
see how much speed they lose?

Do you want to learn how kernels are written, by copying an existing design (unix, whatever?) or
make up your own
from a hodge-podge of concepts? That seems to be the trend lately. Or a convenient excuse.

Do you want to advance the state of the art? Create a new architecture with a lot of advantages nobody has seen
before?

Pick one, and stick to it. Software hates inconsistency. In the middle of the project, don’t decide to
rewrite
everything in C because assembly is a bit much to chew after all, or to publish papers on something everybody already
knows (like, say,
programming the PIC on x86) just to show the
world you can read a datasheet.

Choose your audience

Who is your user? Not the fellow hackers you will hire for help on coding your dream. But who is the end user?

Billie, a middle-aged house wife with three kids, who does the accounting around the house, and also chats a little
bit online once in a while when everybody is at work and at school?

John, a thirty-something guy writing unix banking software for a living, currently using NetBSD on his desktop, switching
on a regular basis, trying out FreeBSD or Linux, because he needs the unix environment and will not mind a new OS as
long as he has gcc, nedit and windowmaker?

A person known as DaMan, a 21-year old sysadmin/programmer who compiles every new linux kernel on his company
servers, as soon as he hears they are out on the kernel mailing list? And who will be willing to try any new cool server OS,
as long as it has perl and vi?

Fellow hackers in the OS development community, who will eagerly read your papers about thread migration and
protection through artificially software reduced instruction sets?

Yourself, who will be the only one to ever see your OS?

Be honest about your goals

When you know your camp and your end user, the killer question is: can you do it? Be honest with yourself.
Give yourself credit – you will never know if you can write a fully debugged preemptive scheduler, until you have tried it, but
be realistic about how much you can do. Either you will decide it’s more fun to play cricket, or you will have a better idea of the profiles of people you need to enroll on your site. Either way you win.

My company is happily employing a guy best known in the open-source world for writing a mono-tasking OS all in
assembler. It was limited, and for x86 only, but hell, it worked, and it fulfilled the original goal. One day he told me he
received an email from a fan, who said something like: “I just want to know how to decompress the kernel, because I can’t
figure it out. But the rest, the writing the kernel thing, that’s easy. I just want to know about the unpacking”.

Right.

Publish your goals and your own capabilities with honesty. Smart people don’t like arrogant people anyway.

You are the god of your project

If you go the open-source route and enroll fellow hackers, they will come up with their 130 ideas they want in your
kernel, plus their 200 itches to be scratched (such as “semaphores suck!”), and their own idea of your project. If you let
people hack away merrily, you will end up with the opposite of efficient.

You create your project – you own it. Be sure that contributions are consistent with your vision. Don’t hesitate
to ask people to rewrite something so it fits your goals and your architecture.

Do not bait people on purpose, though. Make sure that as much as possible is written and published on your
site. You can’t bash somebody because he doesn’t know something is not in line with your thinking. If they’re good, they
will move on to another project. You don’t want to lose good people.

Version control is great and mandatory. Letting anybody commit code, no matter how focused and smart they are, is
the best way to have your project go in all directions and try to be a distributed server OS as well as a RTOS that
fits in 64K, at the same time. Be sure people send patches to you and you commit them when they are OK. After a
while, when you have grown to trust a few people like yourself, expand to a core team with commit privileges. Make people
own the task of integrating, validating and committing.

Conclusion

If we go back to AtheOS, the goal of learning and cloning was well defined. The target is the power desktop
developer-users who like to try out cool new things. Kurt, the creator, never claimed to dominate the world and has
been going at it piece by piece, slowly. He did most of it by himself,
not encouraging external contribution, enforcing
consistency.

Taking these decisions right away also helped me a lot.

If you’re engaging in such an adventure, I hope this helps take the frustration out and make it much more fun. In any
case, good luck, and I would love to hear comments on the article, as well as experience of anybody who already went
down that path, successfully or not.

About the author
Emmanuel Marty is the Chief Technical Officer of
NexWave Solutions, the supplier of a new software
architecture, OS services, and telecom stacks, for consumer electronics and telecom. He has been working with
computers since the age of 10. Currently aged 26, he lives in Montpellier, France, with his fiancee. He can
be reached at [email protected].

32 Comments

  1. 2002-08-05 6:10 am
  2. 2002-08-05 6:32 am
  3. 2002-08-05 6:41 am
  4. 2002-08-05 6:55 am
  5. 2002-08-05 7:12 am
  6. 2002-08-05 8:04 am
  7. 2002-08-05 8:45 am
  8. 2002-08-05 9:02 am
  9. 2002-08-05 9:07 am
  10. 2002-08-05 9:48 am
  11. 2002-08-05 10:47 am
  12. 2002-08-05 12:34 pm
  13. 2002-08-05 12:46 pm
  14. 2002-08-05 12:58 pm
  15. 2002-08-05 1:27 pm
  16. 2002-08-05 1:34 pm
  17. 2002-08-05 1:49 pm
  18. 2002-08-05 2:07 pm
  19. 2002-08-05 3:26 pm
  20. 2002-08-05 3:43 pm
  21. 2002-08-05 5:09 pm
  22. 2002-08-05 5:17 pm
  23. 2002-08-05 5:33 pm
  24. 2002-08-05 6:20 pm
  25. 2002-08-05 6:48 pm
  26. 2002-08-05 7:03 pm
  27. 2002-08-05 9:29 pm
  28. 2002-08-06 1:42 am
  29. 2002-08-06 5:32 am
  30. 2002-08-06 8:58 am
  31. 2002-08-06 8:31 pm
  32. 2002-08-07 8:48 am