Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Programming Software IT Technology

Building Your Own Operating System? 102

Posted by Cliff from the go-your-own-road dept.
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."
This discussion has been archived. No new comments can be posted.

Building Your Own Operating System? More

Building Your Own Operating System?

Comments Filter:
  • "I have dreams of writing a toy operating system..."

    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

  • offtopic, but... (Score:3, Interesting)

    by ru-486 ( 73117 ) on Wednesday February 04, 2004 @10:58PM (#8186444)
    Slashdot needs more items like this! Reminds me of the pre-SCO days...
    • The effect of building an OS from scratch in 2003: Nothing (except personal pride?)

      The effect of complaining about SCO: Nothing (except community pride?)

      Difference between the two: Nothing! (except the details?)

  • Amiga RKMs (Score:5, Informative)

    by Mr. Darl McBride ( 704524 ) on Wednesday February 04, 2004 @11:01PM (#8186463)
    Get your hands on the Amiga ROM Kernel Manuals -- both "Libraries and Devices" and "Includes and Autodocs." I&A has the headers for most everything, and the libraries explain the workings pretty well. The Amiga OS was very simple and elegant. Understanding the base (ignore the GUI) will be enlightening.

    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

  • Here's a list for ya.. (Score:5, Informative)

    by QuantumG ( 50515 ) <qg@biodome.org> on Wednesday February 04, 2004 @11:01PM (#8186464) Homepage Journal
    • Learn asm
    • Get used to rebooting your machine or figure out how to get Bochs to compile with the debugger enabled
    • Write a bootloader (I know Grub rocks, but you need the experience)
    • Write a keyboard driver
    • Write a video driver
    • Write a scheduler
    • Write a shell
    • Write a filesystem driver
    • Write a network driver
    • Try to port gcc to your OS
    • Write yet another revolutionary GUI
    • Write everything else

    • 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)

      by edalytical ( 671270 ) on Wednesday February 04, 2004 @11:40PM (#8186680)
      Write a bootloader

      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)

        by Satan's Librarian ( 581495 ) * <mike@codevis.com> on Thursday February 05, 2004 @04:22AM (#8186979) Homepage
        Actually, depending on what you are looking to get out of the experience and how determined you are, it's a *very* small piece of code that you can learn quite a bit about the PC by writing.

        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:

        • Assembler language
        • BIOS interrupts
        • BIOS memory architecture
        • Disk structure and I/O
        • How a PC boots
        • How to get lilo back quickly and easily if you install XP onto a partition after linux.
        • Why you should backup your partition table and MBR sector before writing a buggy program to it.
      • It checks your tool chain, takes about 4 hours (assuming you know assembly, but not the machine's boot process), it gives you ground from which to start other stuff, it let's you say you're building 'from the ground up', and it gives you confidence by doing something easy.
      • Why? What experience do you gain from this?

        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
    • 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.

      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!
    • Actually, a Pentium 4 has ridiculously slow system calls. Athlons have system calls twice as slow as classic Pentiums, and the P4 is much worse.

      • 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?

        • Eh? What do you mean by "lightening fast?"
          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.
    • Nah. If you really want something revolutionary, write your kernel in a safe language. That way, everything can safely be in kernel space, and you don't need system calls at all!

  • One good source (Score:3, Informative)

    by nerd65536 ( 692353 ) on Wednesday February 04, 2004 @11:02PM (#8186474) Homepage
    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.

  • Google is your friend. (Score:4, Interesting)

    by linuxkrn ( 635044 ) <gwatson@lRASPinuxlogin.com minus berry> on Wednesday February 04, 2004 @11:03PM (#8186485)
    I did this years ago. Had a quick boot floppy with a dumb OS that did almost nothing. But it was still cool "just for fun."

    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.ph p [free2code.net]

  • Easy Answer (Score:3, Funny)

    by Quarters ( 18322 ) on Wednesday February 04, 2004 @11:05PM (#8186492)
    Just read OSNews The average discussion over there is populated by people with plenty of baseless opinions on OS design and very little actual practical knowledge.

    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.

    • What do you mean?

      The review of the Linux Mandrake installation GUI was a brilliant piece of journalism.
      • Bug report
        --
        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)

    by thedanc ( 449477 ) on Wednesday February 04, 2004 @11:07PM (#8186504)
    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.

  • You can start by studying DOS (Score:4, Informative)

    by HotNeedleOfInquiry ( 598897 ) on Wednesday February 04, 2004 @11:09PM (#8186518)
    It's still widely used in embedded systems and there's at least one version (freedos) that's open source. There's lots of FAT disk driver code around and acually getting something to work is not that hard.

    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)

    by eviltypeguy ( 521224 ) on Wednesday February 04, 2004 @11:22PM (#8186590)
    I would highly recommend the book:

    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/books /d evelopers-handbook/

    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)

    by Satan's Librarian ( 581495 ) * <mike@codevis.com> on Wednesday February 04, 2004 @11:27PM (#8186618) Homepage
    If you want to learn from a simpler operating system than Linux, Dissecting DOS [amazon.com] was an excellent book in its time.

    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!

    • Bootstraps are not simple . If you are extremely lucky it may go well, but more likely not. I got involved in one once - the worst thing is trying to get debugging info when almost nothing is up and running yet - especially NOT the display. And there was no BIOS either, I was running with an eprom plugged in and replacing the normal BIOS chip - nothing on it except the code I wrote.

      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
      • Uhm - first off, I was referring to the Operating System bootstrap code on a PC. Typically the software I referred to is on the first sector of a floppy disk or on the MBR/Partition table sector of the hard disk. This is what people refer to as the 'boot sector' or bootstrap code when referring to writing an operating system.

        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)

    by mosel-saar-ruwer ( 732341 ) on Wednesday February 04, 2004 @11:28PM (#8186625)

    Richard Burgess's "Developing Your Own 32-Bit Operating System":

    http://www.accu.org/bookreviews/public/reviews/d/d 000481.htm [accu.org]

    http://www.sensorypublishing.com/mmurtl.html [sensorypublishing.com]

    Used to be published by SAMS, but they no longer list it. Now available as an online download.

    • I used that book. I would mod you up but no modding and posting. :( I made a mini "OS" which just went to PM, switched tasks, and did a little screen writing before going back to DOS. It wasn't a real OS but rather a program that uses PM. ButI learned all I needed to know from kindergarten, er that book. And I still have it.

  • Don't do it for Intel (Score:5, Insightful)

    by Dimwit ( 36756 ) * on Wednesday February 04, 2004 @11:37PM (#8186671)
    Don't really do it for any modern architecture. Visit 6502.org [6502.org] and look at the sample operating systems they have there.

    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)

      by account_deleted ( 4530225 ) on Thursday February 05, 2004 @12:02AM (#8186786)
      Comment removed based on user account deletion
      • There are also plenty of nice Z80 emulators. That way you don't need to reboot a machine every time and you have easier code stepping capabilities.
      • Wrote my own multithreading OS for an embedded 6502. Task switches beautifully fast because only 2 or 3 registers to save. Most instructions = 1 cloxycle. Basically RISC before RISC existed.
    • 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*

      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)

    by edalytical ( 671270 ) on Wednesday February 04, 2004 @11:56PM (#8186754)
    Sigops [uiuc.edu] 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.
  • I just implemented the world's cheesiest threading system on a nonexistent computer. (It's a simple simulation I wrote.) It was hard yet fun. Maybe I'll get around to posting code some time.

    Gotta implement an I/O system...

  • A great book... (Score:3, Informative)

    by BigZaphod ( 12942 ) on Thursday February 05, 2004 @12:06AM (#8186806) Homepage
    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.

  • omg (Score:5, Funny)

    by Anonymous Coward on Thursday February 05, 2004 @12:07AM (#8186809)
    I have dreams of writing a toy operating system...

    Linus, is that you?

    So that Ask Slashdot you posted some time ago finally made it through the submission queue?
  • For the love of dog, we need more people writing drivers than we do writing OSes. Hook up with one of the interesting weird OS projects, like Contiki [dunkels.com], and write some stuff for that. See if you can workout why the web downloader fails on some C64s. Or add support for the extra RAM in an RR-Net cart [jschoenfeld.de]. Or if Contiki isn't your style, add support for the ECS [intellivisionlives.com] to IntyOS [intyos.free.fr]

    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 [cs.vu.nl] was designed to be small and easy to understand and there is a book called Operating Systems Design and Implementation [amazon.com] which explains the inner workings in practical terms. NOTE I have the first edition of this book not the second. You can get the code for it and have a book which explains what the code is doing should be easy to play with and help you understand what is going on.

  • Tanenbaum and Minix (Score:2, Interesting)

    by james b ( 31361 )
    I really enjoyed Tanenbaum's Operating Systems: Design and Implementation. The whole book is basically a tour of Minix with lots of OS theory along the way. It's very *NIX oriented - signals and system calls etc, but there's some discussion of other ways of doing things.

    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.

    /james
  • "I have dreams of writing a toy operating system, as I know some people have already done in college."

    Who!?

    • Re:Really? (Score:2, Informative)

      by NSash ( 711724 )
      Many colleges (including mine) offer Comp Sci. courses in which you design an operating system. It's not that uncommon.

  • Linux Gazette article (Score:2, Interesting)

    by DrMorris ( 156226 )
    You may want to read an article in Linux Gazette:
    So You Wanna Create Your Own x86 Operating System? [linuxgazette.com]

  • Do something new! (Score:5, Insightful)

    by Walles ( 99143 ) <`johan.walles' `at' `gmail.com'> on Thursday February 05, 2004 @07:47AM (#8187945)
    Write it in an interpreted language. Have the interpreter run itself. I'm dead serious.

    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)

      by sl3xd ( 111641 ) *
      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

      • Re:Do something new! (Score:1, Funny)

        by Anonymous Coward
        Later versions of PICK OS were written in C. It is still being used by very stupid companies, and there's still commercial support for it. It should have been dead for decades (originally, PICK was created in the 1960's) but alas...

        Btw, if you ever have access to a PICK machine, logon and type 'echo' without parameters - and see if you can fix your terminal :)
    • I second that motion. I don't know how hard it would be using an interpreted language, but I would definately look into using something other than C. Think of how cool it would be if your OS was written in Haskell or OCaml or Erlang or prolog. If you pick one of those, you're pretty much guarenteed to be breaking new ground in OS research.
      • In the 1980's an OS was written in a lazy functional language which used lazy streams for I/O.

        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.
        • Wow. After a little googling, I found a Peter Henderson, who wrote a paper...

          Peter Henderson. Purely functional operating systems. In J. Darlington, P. Henderson, and D. A. Turner, editors, Functional programming and its applications, pages 177--192. Cambridge University Press, 1982.

          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

          • Oh yeah, Peter Henderson. That paper is a classic but more because it was the first project to do a lot fo the work on lazy streams and IO. That and a old paper by Kahn which dates from 1972. Noweadays that approach is pretty much dead, Monads have taken over everything.
    • And I'll give you the slogan:

      "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
      • Regarding your performance worries, you are wrong.

        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

        • Yes, you are absolutely right, but my problem is that I adhere to the old-school definition of "interpreted". And if, as per that def, you are interpreting the interpreter, you will be bogged down very quickly.

          Peace & Blessings,
          bmac
          www.mihr.com for true peace & happiness
          • In that case, you were right.

            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.

      • Umm...WRONG.

        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.
        • Sorry, man, that's just *not* possible. You must be referring, as another poster did, to a just-in-time compiler. If it is a true interpreter, it is impossible to compete with a compiled program, unless the compiled program is written *very* badly.

          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 .2/0446.html

          And now
  • Operating Systems: Design and Implementation (Second Edition)
    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)

    by Phaid ( 938 )
    One of my favorite projects in my sophomore operating systems class at university was to implement various little toy programs on Jean Labrosse's uCOS [microcross.com] realtime operating system to illustrate various OS features like IPC and multitasking.. We did things like implement a "horse race" with two "horse" threads moving across the screen and an "announcer" thread which displayed positions, all synchronized by semaphores and communicating through mailboxes. Nothing earth shattering, but since the code for each th
  • Operating Systems: Design and Implementation (Second Edition) by Andrew S. Tanenbaum, Albert S. Woodhull
    Link to the book on amazon [amazon.com]
  • There is an excellent article [linuxgazette.com] 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.

  • First step (Score:4, Informative)

    by Permission Denied ( 551645 ) on Thursday February 05, 2004 @11:21AM (#8189447) Journal
    People here are recommending all sorts of books and websites specifically catered to this project. When I did it, I knew of no such resources.

    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.

    • Hey, I'm just a user and I understand. After all, why should I compose a new song or write a new book when there are already so many songs and books out there?
      • Hey, I'm just a user and I understand.

        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

  • There used to be a book called Developing Your own 32 Bit Operating System that went out of print but it's be rereleased as MMURTL [sensorypublishing.com]. You can order it in PDF or dead tree format. Also you might want to check out my site. I've got a bunch of links to osdev resources.

  • Comment removed based on user account deletion
  • If anyone knows where you can find info on the PocketPC chips, any and all of them, for iPaq's and HP's old Jornada, That would be appreciated.
  • When I got my Apple ][ it had onboard 16K of ROM. Somewhere in that manual was a funky command:

    >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

  • If you want to learn about implementing operating systems, you could follow Operating Systems Project [cs.hut.fi] course just started at my university [www.hut.fi]. All the materials, exercises and documentation (ignore the bits about ordering handouts, needed manuals are provided in PostScript and PDF) are in English and available to anyone but you'll miss the lecturing course [cs.hut.fi] that takes place at the moment and which is intended to be taken at the same time (they use Tanenbaum's Modern Operating Systems, 2nd ed.) and you won't get

  • 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

Slashdot Top Deals

Arithmetic is being able to count up to twenty without taking off your shoes. -- Mickey Mouse

Close