Slashdot Mirror
Building Your Own Operating System?
sonictooth asks: "I have dreams of writing a toy operating system, as I know some people have already done in college. Unfortunately, I don't have that opportunity. I was wondering what books (as there are so many) and methods people [have used], either in college or on their own. Amazon is littered with books from varying authors, Tanenbaum in particular, and there are both positive and negative reviews of his books. Does anyone recommend a simple book to walk you through the early stages, and then explain the more complex theories later on."
Now, these books don't make for a how-to, and you don't get the source for the core OS with them, but if you start by learning the exec interface, then look over the exec headers, you'll quickly develop a thorough understanding of a simple multitasking kernel. From there, you can glom onto the basic device library with the library book, then the headers again, and repeat for the trackdisk library. Jump into console and other libraries as your interest dictates. Don't worry about learning these things in a linear fashion -- going with your interest first is critical for learning something as complex and intricately interconnected as the workings of an OS.
After seeing how some of these work together, if you've got your head on straight with C, implementing your own equivalent on the PC should be easy. Grab MS-DOS, which leaves protected mode entirely open to you, and build your own system on top of that. No need to start with your own bootstrapper if you can do it with a little DOS code. That way you have BIOS services for the parts you haven't written yet, and can replace bits a little at a time as your interest dictates. Make a simple OS shell first, using mostly wrappers, then drill down until it's time to start making your own device drivers.
From here, I went on to acquire the IP rights behind UNIX and develop from there, but you can take your own route.
~Darl
Congratulations you've got yet another monolithic kernel based hobby OS that no-one is interested in but you.
If you want something remotely interesting, try seperating as much of that junk in the kernel as you can into userland. Pentiums now have system calls that are 5 to 10 times faster than they used to be. Think about writing applications that communicate using shared memory pages. If one app writes a page and then instructs the kernel to map that page into another process, the kernel can do that rediculously fast. That's 4k (or more if you're using bigger pages) that has transfered from one process to another in the space of a single system call.
How we know is more important than what we know.
One good source isn't a book at all: The source code for the Linux kernel. You could also take a look at FreeBSD and any other open source OS. Looking at something that works should give you an idea of what you need to do in your own OS.
Install Ubuntu in Android
I'm taking an Operating Systems course right now. You could follow along with it (or a similar course at any university.) Obviously you'll miss the lectures, but read along in the book and you'll get the same content. (BTW, the book for this class is by Silberschatz; ISBN 0471250600. I only gave Tanenbaum's OS book a quick look over, but so far I like the style of this book more than Tanenbaum's writing that I saw in his Computer Organization book.)
The course starts you off with a very basic skeleton. From there, we'll add most of the parts of a basic OS in several individual programming projects. The class website is at http://www.cs.umd.edu/class/spring2004/cmsc412/ (won't work in IE) It has everything on it you should need to follow along.
My favorite books are:
DOS Technical Reference by IBM
DOS Internals by Chappell
Dissecting DOS by Podanoffsky (I believe he wrote a DOS as well)
"Eve of Destruction", it's not just for old hippies anymore...
I would highly recommend the book:
s /d evelopers-handbook/
The Design and Implementation of the 4.4 BSD Operating System
by Marshall Kirk McKusick
Keith Bostic
Micahel J. Karels
and John S. Quarterman
(ISBN 0201549794)
It's really a great book about a mature operating system and will give you some great technical insights into the hows and whys behind operating systems in my opinion.
Additionally, most *BSD distributions are a great study because their code tends to be very well organized and they come with *LOTS* of documentation.
Even reading the FreeBSD developer's handbook here:
http://www.freebsd.org/doc/en_US.ISO8859-1/book
or the KernelNewbies site here:
http://www.kernelnewbies.org/
May be of benefit to you.
Additionally, I hope you have a high level of reading comprehension. Be prepared to take several trips to your local library or bookstore and spend hours perusing texts to better understand the ins and outs, and quirks of hardware.
But lastly, even after you do all of the above, the best way to learn is to do! Install a copy of Boch's or if you're a little richer, buy VMWare or VirtualPC (VirtualPC's emulation tends to be better than VMWare's although a bit slower). Get brave and setup and old pc and install all kinds of different OS's on it. That's the best way in my opinion to learn...
Assuming you want to go bottom-up in designing the system and you're using a PC, the first things you'll need are a decent grip on x86 assembler and PC architecture. Then, you need to learn the BIOS interrupts/services, since that's about all that'll be available to you.
I'd think one of the first things you might want to write is a bootstrap routine.The Undocumented PC had a pretty good description of bootstrapping as I recall. Basically, the bootsector of the boot device (first sector on a floppy, the MBR/partition table on hard disk, etc.) gets loaded to 0:7c00 in real mode and gets executed - what you do from there is up to you. Some *really* old video games for PC's came as boot disks and did just that - in a sense, they provided their own simple operating systems.
After that, you'll get into the more fun stuff - filesystems, memory management, task switching, compilers, linkers and loaders, device drivers, etc. That's where you'll want to be reading your Tanenbaum book, a stack of others, and probably peeking at Linux and other open source operating systems to see how it's really done.
Good luck!
I write code.
Richard Burgess's "Developing Your Own 32-Bit Operating System": Used to be published by SAMS, but they no longer list it. Now available as an online download.
Sigops How to Write an Operating System. This is a series that will walk you trough writing your own os. You'll have your own Hello World OS after you read the first chapter and you'll be multitasking by chapter five.
Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
I have a book titled "Developing Your Own 32-bit Operating System" although i suspect it is out of print. You might try looking for it, though. The book takes you step-by-step through building an OS for x86. It's amazingly complete including all the source code. The guy even wrote his own compiler, if I remember right. Wonderful book.
Hexy - a strategy game for iPhone/iPod Touch
There is an excellent article by Krishnakumar, at least to get you through the bootloader part. Though he didn't write the next part(s), you can gather them from other sources.
Anyway, I'd recommend doing a google search for 386intel.txt. This is Intel's documentation for the 386 chip, including systems programming stuff. This is the file Linus used. The modern version of this documentation is available here for the Pentium III, split up in three. You'll need all three, but the third in the series is most relevant.
After you get booting, you'll need some documentation for various devices when writing drivers. I used "The Indespensible PC Hardware Book" by Messner and it was pretty good. I guess there are also good websites available and you can always look at how Linux or *BSD does it.
Anyway, you might be able to skip the Intel documentation if you use someone else's bootloader, but I don't recommend this. One of the points of this project should be to understand the machine inside and out from boot, so write your own bootloader and object code loader. Once it can run your C code, you'll get a feeling of satisfaction, which should be another of this project's goals.
I used an older version of VMWare for testing, but I highly recommend bochs nowadays. Bochs seems designed exactly for this stuff, so you can run a debugger right away and you don't need to go through the older debugging route which was to write a serial port driver as soon as possible and get a remote debugger working over that (easiest way to do remote debugging in VMWare and real hardware).
I'd recommend nasm for the assembler bits. It can do 16-bit code for the bootloader and it can spit out unadorned object code so you don't have to bother with parsing ELF and extracting what you need (although you'll need to do this eventually when you get to C, but you can at least delay that until after you start booting).
One last thing - ignore the naysayers. It seems lots of people thought it important to post that you shouldn't be doing this but should instead be contributing some drivers to another project or something like that. Whenever someone in the open source community says this, they're almost always non-developers. Most of us write code on our own time because we find it satisfying and this is one of the most satisfying projects you can undertake. This project is also a kind of "coming-of-age" experience (for lack of a better word), like writing your own compiler or creating a GUI API or window manager. Users won't understand. That's OK. We understand.
There are actual 'professional' OSes that do exactly this. (Or at least something close enough to be worth mentioning.) One such OS is called 'Pick', which is essentially BASIC, IIRC... It's also a multi-dimensional database, providing its actual 'usefulness'. The nice thing about Pick is that as long as the OS is ported to the platform you intend to run it on, every Pick program will run identically on every platform. So you're guaranteed that you won't have to do anything when your company decides it's moving from IBM to HP, for instance. Great stuff for mainframe work
-- Sometimes you have to turn the lights off in order to see.
Many colleges (including mine) offer Comp Sci. courses in which you design an operating system. It's not that uncommon.