Beginner Mistakes

The idea to "write your own OS" brought you here. This Wiki is about giving you help, pointers, and references in your undertaking.

However, it is quite common that newcomers make certain mistakes, or have common misconceptions about what is involved in the topic. That is not bad - many others made these beginner mistakes before, and many will do so in the future. This page is about making sure you know what you're about, before digging into the provided information.

What this is NOT

This may look like a set of tutorials to copy & paste, plus a forum to ask your questions whenever you get stuck. This is not so. We fully expect you to carry your own weight, and be an experienced programmer of user-space applications before you set out to write your own OS. We also expect you to have read about OS design, and that you have studied relevant documentation of your platform of choice. Do not expect this Wiki, or the forum, to be some kind of complete guide to my own OS, let alone a guide to programming skills in general.

What you find here is documentation left behind by those who came before you, who found out about these things by reading technical documentation, available source code, and forum postings as well as by trial & error programming. Some of it was written so those people could look it up again later, some of it so that we could point to a Wiki article instead of explaining a subject all over again.

What you find here are little hints and roadsigns that might help you on your path. It's not a complete map to Oz. Nor should it be.

If you don't already have a good idea what a stack is, or how to use a debugger, we won't go out of our way to explain it to you. Visit those two pages; you will see that they mostly deal with OS specifics, not a general introduction to the topic. That is not a flaw, that's by design. If you are looking for general programming enlightenment, you should rather visit general programming sites like StackOverflow and become a developer first before you aspire to become an OS developer.

This Wiki will not be expanded into a beginner's handbook, because that is not its purpose. It is for answering the advanced questions that arise when people feel they're ready for the plunge into kernel space programming.

Is there a tutorial on..?

Because this place can not and does not cater for beginner developers, the question for some other place that does provide a tutorial, good explanations or easy to understand reading is often requested. However, they do not exist. Difficult subjects can not be described with light prose, just like there are enough things that are too complicated for a monkey to properly learn. If you have trouble reading official documentation, this would be a good time to practice.

In fact, the vast majority of tutorials currently out there are known to be broken in at least one way, so you are generally better off not trusting them in the first place.

Scope

Deadlines

Whether for university, hobby, or commercial uses, operating system development takes time. The Linux kernel took over one year of very dedicated work to get into a semblance of usefulness, and all Linus Torvalds did was mimic existing and well-documented behaviour to get an already-existing userspace to run on it. Moreover, for every project as successful as Linux, there are literally hundreds of projects that consumed a man-year or more of work without ever getting as far as hosting a functional shell.

Therefore, plan a reasonable road map of what you want to get done. Do not assume that in 3 months your OS will have a GUI and voice recognition, because operating system development does not contain any RAD tools in it at all. In fact, it is completely void of them. (void. It's a joke. Get it?)

Commercial OSDev

There really is no such topic. OSDev will probably never land you a job. (As shown in the "Jobs" section of the forum.)

Also, don't get your mind set that by building such a great OS that you'll be rich. If anything, history has shown us that the best operating systems never receive any commercial success, while the ones that have a near total lack of design and inspiration do, because of clever business moves and being in the right place, in the right time, with the right cover-up.

Assuming It Will Go Nowhere

In contrast to above, some people assume their OS will go nowhere. For this reason, their projects have ugly code, don't take important aspects into account and in general rely on ugly hacks. Worst of all, they take decisions that don't allow usability and extensibility. This way, their assumption becomes a self-fulfilling prophecy.

In reality, while the chances of getting your OS running outside of your test machines are low, there are enough advanced OS projects that started from this very community.

Avoid Ignorance

Beginners often ask "What is the easiest way to do X?" rather than "What is the best, proper, correct way to do X?". This is dangerous as the newcomer doesn't invest time into understanding the superior way to implement something, but instead picks a conceptually simpler method copied from a tutorial. Indeed, the simpler route is often too simple and ends up causing more problems in the long run, because the beginner is ignorant of the superior alternative and doesn't know when it is better to switch. What's so bad about taking the hard route instead?

Common examples include being too lazy to use a Cross-Compiler, not understanding Real Mode, Unreal Mode, Protected Mode and Long Mode and jumping far too fast from one to the other without understanding how to gather all of the vital configuration and use all of its capabilities fully first (specially detecting basic capabilities with the BIOS during boot and initialization), relying on BIOS calls or DOS services that are not standard, not learning to write hardware drivers in your own OS and under Windows and Linux for greatest convenience and to open test capabilities globally, using flat binaries instead of ELF or not learning about executable, archive, graphics, document and other file formats and compression algorithms, and so on. Experienced developers use the superior alternatives for a reason, which you might not understand yet. Experienced developers are able to use the inferior method in some cases, but that's because they can carefully analyse whether it is appropriate, and they know when not to use it. As a beginner or intermediate developer you will likely not know these methods and technologies well enough to reason whether the inferior solution is good enough for you. Remember that if you oppose a method, you should know it well enough to know everything that is wrong (and right) with it. Either way, laziness and ignorance only leads to trouble down the road. When in doubt, pick what appears to be the conservative choice rather than the simpler.

Design

GUI Design

It will likely take you several years, starting from scratch, to get to the point where you actually do anything GUI-related. And, the looks of a GUI are secondary at best, as they can easily be changed retroactively; what really decides the usability of a GUI is the functionality, and that isn't expressed in mock-up graphics. If your aim is creating a better look instead of a better OS, consider implementing an X Window Manager instead of a whole OS.

Memory usage

I want to use less than a couple of kilobytes for my OS!

Sorry, that's probably impossible. An OS using such little memory will be almost unusable. Forget about filesystem drivers, disk drivers, usb drivers, etc. If you want to develop something small, just make a simple bootloader, not an OS.

OS Emulation

My OS will be able to run programs from Windows, Mac OS, Linux, and even PDP-11 programs!!!

I'm sorry to burst your bubble, but it probably won't. Emulating even just a single system takes years of work, especially when it's proprietary, such as Windows or Mac OS (Linux is probably the easiest out of the four.). Wine, despite being in development since 1993 and being written in userspace, has still got problems with many programs.

So instead of focusing on emulating other systems, focus on your own. Design it, develop it, and be friends with it.

Naming

Naming is usually the last problem to be solved, even while we all wish for a cool name to our cool concept. Since the "coolness" of a name is a matter of taste, we cannot help you finding it. Moreover, if you tie your project name to a certain feature, you might discover somewhere down the road that no concept is perfect and that you might want to change what you initially thought a key feature. Nothing would be more stupid not to evolve just because you 'want to stick to a name'...

A lot of good information on naming can be found in this thread. Simply put, naming your operating system <name>OS (JackOS, FredOS, etc) may seem like a good idea, until you get a second project member. A good idea (courtesy of Solar) is to choose a codename (like Longhorn, Chicago, etc) and then make up a better name closer to release time.

Programming Languages

Some languages are well suited to write a kernel, others are less so. Read the page about using some language other than C.

Kernel Image

Booting Problems

Especially in early stages and with a self-built bootloader, the reason is frequently that too few sectors are fetched from disk. Either adjust the amount of sectors you fetch from disk, or have the boot loader / second stage loader parse the file system.

Teamwork

The number one beginner mistake seen in the Announcements forum. They usually come in one of two forms, although they have quite a bit of overlap:

Community Projects

Don't overestimate your chances of getting people interested in your project. Even the more successful projects usually consist of one, perhaps two people actually working on the code. And that is not due to a lack of need.

Brooks' Law states that the more people on a project, the longer it takes. The only way around this is to split the project into parts that you get people working on and only on that part. Good luck.

Recruiting

There are some things you need for standing a chance (and avoid being painfully told that you are a failure):

1. If you have no established codebase, people will not join because they can see you lack experience and expect the project to fail.
2. If you lack a (worked out) design, people will not join you because they can't see how your OS is more interesting than their own design.
3. If your reputation doesn't precede you, especially the more experienced people will be very wary of you and lack the trust to join.
4. If you don't have project management skills, the few rare people that do join will quit shortly because they are discussing stuff and do not get to code.

People that join nevertheless are usually worse programmers than the people for which this list was composed.