Building Your Own Operating System? 102
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."
Re:Linux (Score:1)
The Operating System Says... BOOOOT! (Score:2, Funny)
input a "Please pull the string."
if a=1 print "The cow says... MOOO!"
if a=2 print "The duck says... QUAAACK!"
if a=3 print "The horse says... NEEEIGH!"
end if
Re:The Operating System Says... BOOOOT! (Score:3, Funny)
Re:The Operating System Says... BOOOOT! (Score:1, Offtopic)
if a=4 print "Three singing pigs say LA LA AL!"
Re:The Operating System Says... BOOOOT! (Score:1, Offtopic)
I worked up an alternate wording once that included "Four singing Bugs say YEAH, YEAH, YEAH!". It was mostly pop music based, Beatles and others. Too bad I forgot most of it.
Re:The Operating System Says... BOOOOT! (Score:2, Funny)
Damn, how'd that get in there?
offtopic, but... (Score:3, Interesting)
Its All The Same (Score:1)
The effect of complaining about SCO: Nothing (except community pride?)
Difference between the two: Nothing! (except the details?)
Amiga RKMs (Score:5, Informative)
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
Re:Amiga RKMs (Score:2)
Re:Amiga RKMs (Score:2)
RKRM_Devices.lha [wustl.edu] Part 1 of 4 of Amiga ROM Kernel [wustl.edu]
RKRM_Lib1.lha [wustl.edu] Part 2 of 4 of Amiga ROM Kernel [wustl.edu]
RKRM_Lib2.lha [wustl.edu] Part 3 of 4 of Amiga ROM Kernel Manuals [wustl.edu]
RKRM_Lib3.lha [wustl.edu] Part 4 of 4 of Amiga ROM Kernel Manuals [wustl.edu]
Here's a list for ya.. (Score:5, Informative)
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.
Re:Here's a list for ya.. (Score:4, Interesting)
Why? What experience do you gain from this? I only ask because every other tutorial or FAQ, that I have come across, strongly advises you not to do this-- especially as the first step.
Re:Here's a list for ya.. (Score:5, Interesting)
If you're writing a toy OS to learn the upper level OS concepts, then you're probably better off writing your 'OS' as an app that runs on top of your favorite existing OS. But if you're doing it to learn more about low level programming and the hardware/firmware you're running on, the bootloader is at least a portion you can get done before loosing interest, and it teaches its own lessons.
Also, if all you want is a baby utility OS/program, you can bootstrap the entire program into memory from a floppy (or bootable CD) bootsector, run it, and be done with it.
Lessons learned:
Re:Here's a list for ya.. (Score:3, Interesting)
Re:Here's a list for ya.. (Score:2)
I would recommend the same thing, for one simple reason...
If you write a bootloader, you already have written an OS. A bootloader takes a non-running system, and brings it to the level of some basic user-interaction capabilities. Something like Grub even includes a fairly functional shell...
I suppose it all depends on what you want to learn from the experience. If you care "where did the universe come from", write a bootloader. If you care "How can I get
Re:Here's a list for ya.. (Score:1, Flamebait)
On modern hardware, in fact, it's so fast that it's often faster than the speed of spelling.
B modern! Brake the Speling Barior!
Re:Here's a list for ya.. (Score:2)
Re:Here's a list for ya.. (Score:2)
Huh? SYSENTER/SYSEXIT are lightning fast, assuming you're not switching address spaces.
You are using SYSENTER/SYSEXIT, right? Plus an INT-based layer for backwards compatability?
Re:Here's a list for ya.. (Score:2)
Check out The benchmarks. [codemonkey.org.uk]
It still takes nearly 3x as long as SYSENTER on an Athlon. And an Athlon is slow to begin with. An EV6 was down near 80 clock cycles for system calls! That's about 5x less than the P4.
Re:Here's a list for ya.. (Score:2)
One good source (Score:3, Informative)
Re:One good source (Score:5, Informative)
But, again, he really just wants to know what the best college-level textbook is.
Google is your friend. (Score:4, Interesting)
As I suggested, google is your friend.
Google [google.com] gives you this first: http://mega-tokyo.com/osfaq2/ [mega-tokyo.com].
And this might be good for FS (Fat12) http://www.free2code.net/tutorials/other/20/os1.p
Re:Google is your friend. (Score:2)
Re:Google is your friend. (Score:2)
Easy Answer (Score:3, Funny)
Yup, I figure if you read everything there and then do the exact opposite you should pretty much be on your way to making a really nice OS.
Re:Easy Answer (Score:2)
The review of the Linux Mandrake installation GUI was a brilliant piece of journalism.
Re:Easy Answer (Score:2)
--
OS: duffbeer 7.03
Report:
The system's command interpreter seems to have a glitch. It interprets 'discussion' as meaning 'article', which is completely wrong. I'm currently trying to reproduce the bug by posting on Slashdot. I'll see if I can get it to do it again.
A College Course You can follow along with (Score:4, Informative)
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.
Re:A College Course You can follow along with (Score:3, Interesting)
How come? There's nothing preventing you from walking in to the lecture hall and listening to the prof give his lecture. People do this at my school all the time, it's called auditing. Some of my crazy friends even do the assignments, or help groups with their group work, even if they aren't enrolled in the course!
Re:A College Course You can follow along with (Score:1)
You can start by studying DOS (Score:4, Informative)
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)
Highly Recommended (Score:5, Informative)
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...
Getting started.... (Score:5, Informative)
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 [amazon.com] 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!
Re:Getting started.... (Score:1)
Turned out about the only reliable thing I had was the speaker, and I had to make do with a collection of short beeps, lon
Re:Getting started.... (Score:2)
It's under 512 bytes, which puts a considerable limit on its complexity (although you can use additional sectors if you wish to do more, provided you load them yourself with the firs
Richard Burgess's "Developing Your Own 32-Bit OS" (Score:5, Informative)
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.
Re:Richard Burgess's "Developing Your Own 32-Bit O (Score:2, Interesting)
Don't do it for Intel (Score:5, Insightful)
Why? Because on your first (and second, and third, and forth...) you're not going to want to learn all about the inner workings of the Intel architecture. Segmented memory. *shudder*
The 6502 is still small enough that you can wrap your head around it easily. 6502 emulators are plentiful. An operating system for a 6502-based machine would be small and simple, but still a useful tool.
Once you get your head around that, then try the 6510 - same instruction set, but up to 16MB of memory.
Finally, when you feel good with all that, try Intel, or Sparc, or PPC. My personal favorite processor to code for (assembly-language speaking) is Motorola's 68k.
Comment removed (Score:4, Insightful)
Re:Don't do it for Intel (Score:3, Interesting)
Re:Don't do it for Intel (Score:1)
Re:Don't do it for Intel (Score:3, Insightful)
Where have you been hiding for the last decade?
Segmented memory is the thing of the past, deeply hidden inside real mode. since the times of 386 x86 architecture can use flat memory model (up to 4GB of course) if programmer chooses to. The memory mapping, pages are used for memory virtualization, they are not mandatory.
Progra
Sigops (Score:5, Informative)
Good question (Score:2)
Gotta implement an I/O system...
A great book... (Score:3, Informative)
Re:A great book... (Score:3, Informative)
omg (Score:5, Funny)
Linus, is that you?
So that Ask Slashdot you posted some time ago finally made it through the submission queue?
Learn to write drivers instead (Score:2)
Learning to expand an existing OS, and there are plenty of small ones to choose from, will teach you much more than building your own one from
Minix might be a place to start (Score:1)
Re:Minix might be a place to start (Score:1)
insightful freaking idiot.
Tanenbaum and Minix (Score:2, Interesting)
The nice thing about Minix is it's very easy to make sweeping changes to the OS, recompile the kernel, and see what happens, and the book helps explain how it all works.
Really? (Score:1)
Who!?
Re:Really? (Score:2, Informative)
Linux Gazette article (Score:2, Interesting)
So You Wanna Create Your Own x86 Operating System? [linuxgazette.com]
Do something new! (Score:5, Insightful)
The benefits would be that porting the OS and all programs running on it to a new platform would consist of porting the virtual machine only.
Also, all code would be bounds-checked and stack-overflow protected, so a lot of today's security holes wouldn't be possible to create. With garbage collection, memory leaks would be a minor problem as well.
To get a lot for free, you could base it on IBM's JRVM [ibm.com], a virtual machine for Java, written in Java.
The drawback of not allowing C code to run natively is that there's a lot of software out there that'll be hard to support. This may be solvable, but I haven't given any thought to it so I don't know.
Re:Do something new! (Score:3, Informative)
Re:Do something new! (Score:1, Funny)
Btw, if you ever have access to a PICK machine, logon and type 'echo' without parameters - and see if you can fix your terminal
Re:Do something new! (Score:1)
'nuff said.
Re:Do something new! (Score:2)
Re:Do something new! (Score:2)
The only compromise with regards to referential transparency was use of the McCarthy amb operator.
I cannot recall the name right now but it was wrtten by John Henderson if I remember correctly.
Re:Do something new! (Score:2)
Which seems to cited by a lot of other papers, although I can't seem to find out more about it. I also found this list [google.com] and this thread [google.com] interesting. And there's also a paper [hawaii.edu] on an OS written in ML
Re:Do something new! (Score:2)
Re:Do something new! (Score:1)
"What do you want to do today while you wait for your computer to finish a simple task?"
And, if my intuition is correct, the JRVM may be an interesting intellectual exercise, but I bet it makes running a normal java program look like hand-optimized assembler by comparison.
The main drawback of not using C is that you don't get a language that maps down to machine code such that your program runs well. Mark my words: the interpreted programming language for professional appli
Re:Do something new! (Score:2)
An interpreted language doesn't have to be run by an interpreter. It can be run by a just-in-time compiler as well. A just-in-time compiler (JIT) does exactly what any other compiler would. The only difference is that it is lazy and compiles only the stuff needed to run the program, and it does so on demand.
After stuff has been compiled, you have the same code (assembly for your intel/amd/ppc/... chip) whether you compiled it using a JIT or a static c
Re:Do something new! (Score:1)
Peace & Blessings,
bmac
www.mihr.com for true peace & happiness
Re:Do something new! (Score:1)
Regarding the JRVM, it has no interpreter AFAIK, it only has a JIT. As I've never done anything with the JRVM except read about it, it might still suck in a lot of ways, but it is a compiler so at least a naive interpreter won't be the source of its potential suckiness.
Re:Do something new! (Score:1)
There's an interpreter that's been burning C's ass for years when it comes to speed. It's called the Forth VM.
Even when the code is good, I've rarely seen a compiled C proggy outpeform it's Forth equivalent in speed.
The upside is that most Forths can run in a Virtual Machine or standalone, without an OS.
Re:Do something new! (Score:1)
Sadly, most people at slashdot forget that just-in-time compilation is still *compilation*. Machine code is generated, so it is *not* interpreted.
Now that I did some googling, check out:
http://www.ussg.iu.edu/hypermail/linux/kernel/9 8 09
And now
The way to go (Score:1)
by Andrew S. Tanenbaum, Albert S. Woodhull
Very good book... Inspired Linus to write Linux based on Minix (the free OS that comes w the book)
You may wanna check the Intel website for the 3 x86 manuals (or for the 6 manuals from AMD 64)
uCOS (Score:2)
Operating Systems: Design and Implementation (Score:1)
Link to the book on amazon [amazon.com]
this can get you started (Score:2, Informative)
First step (Score:4, Informative)
Anyway, I'd recommend doing a google search for 386intel.txt [google.com]. 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 [intel.com] 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 [sourceforge.net] 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.
Re:First step (Score:1)
Re:First step (Score:2)
Point well taken.
I think the naysayers are those people who do not understand passion. In this case, it's a passion for understanding and controlling every minute detail of a machine, but anyone who is passionate about something - be it music, writing, mountain climbing or even font design or organic chemistry - can understand the motivation. I'm not really into performance cars, but I think I can understand the drive behind the hotrodders who try to tweak eve
MMURTL - Developing Your own 32 Bit OS (Score:2)
Re: (Score:2)
Looking at doing the same thing (Score:1)
Apple ][ (Score:1)
>CALL -151
This lead to the system monitor ROM. From here I discovered how to dump the content of the ROM with the hex address and an 'L' something like:
*FF00L
After a bunch of listings I found the address which was hard wired in the system as the first instruction to be executed when the computer was powered on; and from there basically reverse engineered the whole machine in order to get a feel for why
Follow OS Project course at my university (Score:2)
First things first (Score:2)
First, look at the various OSes already out there. There are a wide variety for various hardware and with various underlying archetectural philosophies. There's a lot more to an os than hacking together a bootloader et-al. For example, do you want it to be POSIXish? Micro,Mono,Exo kernel? None of the above? What is it's central theme? Persistant objects?, namespaces? files?
What is your primary interest? Do you want to get into the nuts and bolts of the hardware, the semantics of a system/OS, or both?
If