I really don't think you realize how difficult this is.

I mean, to be honest, I never made an OS and I most likely never will make one(at least not one that does anything useful).

To make an OS from scratch you'll need to know quite a bit about hardware for interrupts, how kernels work, how they manage memory, linkers, parsing, be very good at a programming language, and knowing Assembly is almost always a requirement to get some things done.

You'd need to know Assembly to write a bootloader, you'll need good coverage of hardware for interrupts(which are signals to the processing device on what it needs to do), how the kernel should work with driver software, if any, and the I/O stream will not be easy either. The booting process can vary, and a lot of the times it is off putting to people on the whole process because a lot of the work is constituted in hex, and Assembly is really complicated to even many good programmers.

I'm sure many people could fill the blanks even better, but the point is that if you plan on writing an operating system you hopefully are a really good programmer to say the least.

It's not impossible, and I've even been reading up/learning the process behind it, and it's extremely far fetched to the majority of basic computer programmers.

PS: You say you "like the idea of working on something for something i have done."

Unfortunately, using Notepad saves the enormous time and pain than making an operating system host a text editing program in memory to write code to run on the same platform you could have written the code in in the first place.

But, by all means, don't give up the idea of building an operating system. You never know. It's just such a big time killer to bother with the development of one to just use a text editor to write code to use on the same OS you neglected to make it on initially.

I agree with pointer2apointer, what is the point of this? If it is a learning excercise it's completely useless. You will probably never need to do anything that this involves in game programming, or programming in general. And it isn't a matter of time. It is excruciatingly complicated (From what I've read) And involves learning many different and extremely low level programming languages. Unless this is a requirement I don't recommend it, however you could still try and experiment with it.

I took an OS course in my degree based off the pintos academic kernel, and it was a beast. The task was broken into four main sections that spanned the entire semester (with teams of 5), was boatloads of work, and that was after the basic kernel had already been built: we added on to the existing infrastructure (well, virtual memory was empty before we touched it, but, yea). OS programming is a daunting task. If you have the right resources and a LOT of time, coupled with a very solid understanding of C and assembly, there's nothing saying it's impossible. It's some incredibly low-level debugging in many cases, and ultimately served to impress upon me how pleasant programming can be a few levels up from the metal.

1. Depends on your experience.
2. I don't really understand the question ("gdn logie"?) but I guess the answer will be the same as #1.
3. Sadly I have no information here. Perhaps Google knows?
4. I would choose C, for as much as possible.

1: how long did it take you to create what i have stated above?

2:how long would it take to implement a basic api(i read about one on the gdn logie maybe a week ago)?

3: can you share a link about using cds as bootable media(looked around, i could only find floppy disk an usb sadly)?

4: should i write the kernel in x86 asm or c - libraries( i know both)?

1. I've written some very small very basic kernels in the past which didn't even come close to what you're describing. You have to realize that OS development isn't like regular application development as you have to write a huge amount of boilerplate code before you can even start working on something remotely interesting. There will be no libraries available to you to develop your system with, if you want a standard library for developing applications on your custom system you will have to take the time to port an existing library to your platform, which can be a really serious amount of work in itself. The time it takes to develop your system will vastly depend on your programming expertise, your knowledge of the hardware platform you're developing for and the design of your kernel. You should also prepare for days or even weeks of digging through various obscure and sometimes horribly written hardware reference manuals.

2. This is pretty much the same as question 1?

3. Trust me, stick with floppies in the beginning, you don't want to prepare an entire CD image each time you do a kernel build. It will be a while before your system exceeds the 1.44MB you get in a standard 3,5 inch floppy, and you'll mainly be working in a virtual environment for easier debugging and for faster reboots, so you can just mount your floppy images in your virtual machine. If you want to move on to a physical machine you'll still want to stick with floppies as long as possible as they are perfectly rewritable and very easy to switch between machines (ie. your development machine and your target machine).

4. If you're going for x86 development you'll probably be stuck in real mode when your boot loader passes control over to your kernel, so you'll want to use ASM in this stage, unless you fancy using archaic C compilers which can compile 16-bit real-mode code. Once you're in protected mode or higher (ie. long mode) you can use C with a compiler of choice.
ASM and C are not the only options here though, any language which can compile down to native code could be used to develop an OS, although some additional setup could be required for some languages. I've personally used both C and C++ for OS development, but I've seen it done in other languages as well. Some even go as far as to only use a native language to get a lightweight VM set up so they can use managed code to develop the rest of their kernel.


Do not expect any actual results in your OS development endeavours in the first couple of months as it is definitely not an instant gratification discipline. The environment you will be working in will be extremely barebones, the options for debugging are extremely limited, there will be no system in place which protects you and your machine from yourself (I've heard stories of people destroying hardware, mostly monitors, by messing with hardware programming in a custom OS), there will be no descriptive error messages when something goes wrong (you should actually expect no error messages at all, or just random garbage dumps) and you just need a huge amount of dedication and patience to get something remotely useful up and running.

Also, don't expect there to be a lot of tutorials or well-explained reference materials to be lying around, communities like osdev.org can provide some basics, although the community itself can be quite harsh for newcomers. Also be aware of the fact that for some pieces of hardware there will be absolutely no reference material available at all, as a lot of hardware developers aren't keen on giving away documentation of their products to just anyone. Your safest bet is to develop for rather old hardware for which documentation has been published freely, or which have been properly reversed engineered by hardware enthusiasts.


It's definitely not impossible to write your own OS, but I would recommend you only do this if it's just for your personal interest and if you are really really really patient and really really really dedicated to get this system developed. There will be no commercial applications for your OS, nor should you expect anyone to show any real interest in it beside maybe some individuals in the OSDev hobbyist communities.

Even with plenty of time on your hands it's going to be very harsh and tough.

Try and answer some of these questions, and they will probably determine if you're able to complete this feat anytime soon:

1.Do you know in any good sense how GUIs work with OS kernels, how hardware interrupts work, how memory in kernels works, how kernels allocate user space for the user portion of programs to execute under a GUI or program/window structure for this process or purpose of using a text-editor?

If not, you'll need to:

1.Read up more on how operating systems work.

2.Read a LOT more on how kernels work.

3.Read how GUIs work.

4.Read more terminology involved in user space and kernel space, kernel architecture, and how kernels manage memory.

2.Do you know how the kernel communicates with the hardware?

If not, you'll need to:

1.Learn low-level programming, possibly Assembly, will help. Not to mention it can have other benefits(speed for one).

2.Learn about CPU hardware. A processor has a bunch of regions called registers.

You should read this if you're not familiar with some basic processor architecture: http://en.wikipedia.org/wiki/Processor_register

Multi-core processor designs through Assembly and other higher-level programming environments are going to be much more tedious than single-core ones for optimum development.

Point is, you need to know your computer anatomy before you can give useful life to an effective operating system, and learning computer anatomy is not so easy because each computer's anatomy can vary.

A first step: research your current computer's hardware, and then learn more specifically from there. Most importantly, though, would be the processor, input and output, and memory to start with in the learning process.

Also, I'd try and learn about your BIOS, booting options, how exactly you plan on booting the kernel, etc.

It's not a type-and-go process like writing code on an already built OS is with everything you need taken care of for you(especially the ugly stuff that would make many game programmers facepalm).

Hope I helped somewhat!