Operating System Theory

Developing Your Own 32-Bit Operating System/Book and Cd-Rom

Format: Paperback
Author: Richard A. Burgess
ReleaseDate: March, 1995
Publisher: Sams Pub
Rating:

Not an educational textbook
But my guess would be that these same reviewers must have ulterior motives . Some reviewers may fall back on the sorry excuse that this book is intended for educational purposes (because it does not examine a system being used by IT professionals).. . because this book is, by no means, and educational textbook.

What Burgess does, throughout the book, is basically dump code in your lap. There is no discussion of background theory, which is an absolute necessity when dealing with complicated topics like Intel Protected Mode and the 8259 Programmable Interrupt Controller (PIC). Instead, what he does is throw a bunch of source code at you (to pad the book's size) and then expect you to sift through everything line-by-line, with the expectation that you already know how PIC interrupt control words work, and that you understand how x386 segment descriptors work.

There are a number of books on the Linux Kernel that do not suffer from these shortcomings. Specifically, the book by Bovet and Cesati does an amazing job of explaining all the little details (and don't think that this doesn't make a big difference, the devil is in the details). Check out Bovet's explanation of how Linux uses protected mode memory on Intel, it's well done.

You can tell that PHDs like Bovet actually take pride in their work (unlike some two-dollar ex-technical school instructor who just expects you to learn by osmosis).

Instructional text books are about lowering the learning threshold. The goal is to make a subject as easy to understand as possible. Burgess has not done that in this book. He hands you his code and then expects you to do the requisite foot-work. In this sense, this book is more of a poorly documented journal rather than something that an engineer would use to learn from.

Documentation? Ha, that's a good one. If you're lucky, you might get cryptic one-line comments. The author admits, in certain points in the book, that his lack of documentation came back to haunt him (i. e. "I went back months later, only to realize that I forgot what I had done"). If Burgess worked for me writing software, I would have fired him.

The reality of this book is that Burgess wrote an operating system because he had nothing better to do (he was retired). Retired people are like that; let's climb a mountain because it's there (what else am I going to do? Build a ship in a bottle? Watch TV?). However, once he completed the first cut, I suspect that he lost heart and decided to get a life. This book is his attempt to re-coup on the time he spent writing his own OS. Unfortunately, that's really all this book is. He took what he had and haphazardly crammed it into book format.

A wonderful book (and a show of tunnel vision on behalf
) The primary value of this book in my opinion is educational. of some of the reviewers here, carping about assembler, lack of "C wrappers" and Open Source. It is not written in order to unseat the Evil Bill, nor to bless that section of the Open Source constituency that is composed of peabrained "radicals" with yet another toy platform in their endless quest of boundless ego inflation; mental soft-cocks will have to find other means of compensation of their latent inadequacies. (Btw, to those exceedingly smart on that page: any OS -- be it Bill's Windows or Linux or whatever else -- on some level is written in assembly, there's simply no other way to deal with the hardware, so learn first, and babble second, not the other way around. It's said, that to someone having a hammer, everything looks like a nail -- something for the 15 year-old linuxista half-wits, thinking they're great coz they know the word "C wrappers", to contemplate. )

Who cares about any C wrappers in an educational book? Any moron can write C wrappers, the point is not to boost one's ego by producing yet another piece of crud boastfully called an operating system to list with five zillion similar, thoroughly ignored pieces on the google OS list; the point, rather, is to master that which usually goes beneath those wrappers! If one misses these damn wrappers, one is welcome to waste one's time writing them oneself instead of posting absurd drivel on amazon knocking down a great book. (Btw, I work with Linux a lot, so it's not a disparagement of linux or open source per se; these are simply different things. I think this is clear, but just in case I thought I'd clarify that. )

If you want to learn how an OS is written -- specifically, practically, on a real processor, with real code, if you want to master assembly (not on some toy "utilites", but real, complex and highly functional code) -- get this book; if you work through it, you'll be a guru, and that will help you in your work no matter what it is, whether you want to build something on top of this OS, or deal with some other OS, Linux or whatever.

This totally unique in its approach book is simply outstanding, no two ways about it.

Haste makes waste
e. The one thing that seems to stand out in my mind is how the code seems to be thrown together without any regard for long term maintenance (i. assembly code isn't wrapped in C, most of the kernel is in x86 assembly code, doesn't seem to be any sort of structural design underpinning the different components, etc. ). This is evident by the fact that the author often admits that he had problems remembering what he had done. If an overall design blueprints/metaphors had existed, he wouldn't have had this problem.

I assume that the author decided he would tackle his OS project and then get on with his life. In other words, let's get this done and then never, NEVER, look back (history seems to have verified this: the author wrote the OS in the early 1990s and then left MMURTL at the station with bus fair in the mid 1990s). There was no home-page on the internet, nor promoter outside of SAMs publishing.

MMURTL did not take off. The hundreds of hours that the author spent building tools and wading around in the dark have been, for all intensive purposes, lost. All that remains is a jumbled book, as a testimony to one man's urge to climb a mountain "because it's there. "

Had Richard involved other people and Open-Sourced his creation, the man-power necessary to take MMURTL out of its confusing infantile state may have been available. Instead, Richard decided to build MMURTL utilizing a software team consisting of one person, and the rest is history.

Those readers who want to dig into OS internals should defer to Linux. Unlike MMURTL, Linux is a "live" system (which admins actually use) with all the features you would expect in an enterprise OS. Linux has a sane design, does a sufficient job of isolating hardware specifics, and information/support can be located at dozens of web-sites. Best of all, Linus and his cast of thousands have wrapped the assembly code and given it a structural underpinning.

At the end of the day, this book is a nice concept whose execution never really followed through. There may be one or two useful snippets of code, but I wouldn't invest 6 months of my life to become a MMURTL fanatic. History and evolution were the judges and Linux is the winner.