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

This helpful guide is designed to build upon an intermediate programmer's knowledge and explain how to design and develop a feature rich, full operating system. Among the topics discussed are tasking models, memory management, hardware interfaces, systems programming, and much more.

User review
What you need to Consider
There is something that one needs to consider before purchasing a book of this type: for what platform was it designed. This particular book is an excellent and comprehensive guide to creating your own 32-bit operating system. The catch is the 32 bit part. The operating system which one is taught to build will be designed to run on the 386 and 486 platforms. These systems are not as widely used today as they once were. Today's platform is the 64-bit, which was virtually unheard of in the 1980's to early 90's when this book was written. This book does teach you the basics, and will whet your appetite to program better things. For this, I highly recommend the book.

User review
I like it!
I bought this book used, have it in my hot little hands, and no, guys, it's not for sale. I have to admit that I haven't read very far into it, but I love what I see so far. Which is to say, Burgess writes a lot like me, giving more of a personal journal than a textbook.

Some reviewers seem to think that this approach disqualifies the book. It doesn't. Burgess wasn't _TRYING_ to write a textbook -- he says that up front. To complain because it isn't one misses the point entirely.

Another reviewer didn't like MMURTL because it's not competitive with Windows.

Huh?

Yet others didn't like it because it's not Linux. What can I say? For some people, Linux _IS_ their religion.

Let's get it straight: Burgess never claimed to be writing the next great commercial OS, the successor to Windows or Linux. He never claimed to be writing an OS that had only C or C wrappers; he never claimed that he was writing an OS that would be portable across platforms. He gave his goals at the very outset: To learn to write OS's by doing it; to eschew backwards compatibility to other versions, other OS's, or other designs. And to put in only the things he needed. He delivers all those things in spades. Anyone who doesn't like those goals, bought the wrong book and should have read the flyleaf first.

One reviewer has said that he didn't like Burgess' assembly language style or quality. I can't comment on that -- haven't gotten that far yet. But be assured that if I also don't like it, I won't write a bad review. What I'll do is what Burgess has urged us to do from the get-go, which is to change it and personalize it to taste.

User review
Lots of reviewers missing the point

The thing most of the reviews seem to be missing is that this was written in 1995 (when Linux didn't even -function-) and OSS was in reality, barely off the ground. Most reviews carp about how this os/book is a `no show` - that's not really the point. It shows all of the bits necessary to write an OS from scratch.

Apparently, few of the readers have actually worked in industry.

User review
Not an educational textbook
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). But my guess would be that these same reviewers must have ulterior motives ,,.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.

User review
Haste makes waste
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.e. 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.