Book Review: DOS Internals

A Few Decades Late Book Reviews

DOS Internals, by Geoff Chappell
Addison-Wesley, March 1994; 768 pages, ISBN 0-201-60835-9; 39ドル.95

DOS Internals is a very unusual book. Written by an academic whose field isn’t computer science, it is a in-depth and highly analytical look at DOS, very thorough and detailed. Significant space is devoted to exploring to the way DOS interacts with Windows (a hot topic in 1994 when the book was published).

After a chapter or two, the reader inevitably starts wondering about the book’s title. While DOS Internals sounds nice enough, something like Why DOS Is Bad for You or simply DOS Bugs would have been much better represented the content and spirit of the book. Rather than explaining the internals of DOS in a coherent manner as the title might suggest, DOS Internals uses various bugs and misbehaviors of DOS as a springboard for explaining how a particular aspect of DOS works. This method is quite effective but not entirely comprehensive.

The writing style is wry, perhaps funny or perhaps strange, depending on the reader’s taste. At any rate, the book is engaging and surprisingly easy to read for a highly technical treatise. What is lacking is an explanation of author’s research methods; this is not to imply that the book’s contents are in any way untrustworthy or suspect, but knowing exactly how the author arrived at sometimes surprising conclusions would have been helpful.

The first part of the book is devoted to DOS memory management, loosely speaking. The first three chapters interlock and deal with system configuration (especially CONFIG.SYS), system footprint, and the startup sequence. The fourth chapter is devoted to DOS memory allocation, followed by a lengthy and highly informative chapter on program execution.

These five chapters examine various aspects of DOS implementation, with numerous sidebars and small digressions. There is no overarching narrative there, but the information is well presented and thoroughly explained.

The second part of the book is highly practical. Not satisfied with Microsoft’s standard response that "it can’t be done", the author explores how to write first TSRs and then device drivers in C. Only Microsoft C is considered, and it is questionable whether the method presented in the book is the most efficient or straightforward—but it does work.

The third part is ostensibly about extended memory management, but again manages to meander through many topics. The eighth chapter presents a highly detailed dissection of how HIMEM.SYS uses undocumented CPU features to access extended memory from real mode on 286 and 386 systems, explaining how and why these mechanisms work. Chapter 9 is then devoted to the infamous A20 line, with emphasis on how it is managed by DOS 5/6.

The next two chapters examine where extended memory comes from and how it is parceled out. This is followed by a look at HIMEM.SYS, using the published source code. Chapter 14 is about extending the XMS, i.e. hooking into the XMS handler chain. This is followed by a highly practical demonstration: a XMS monitor utility.

The last part of the book is devoted to disk management. Chapter 16 includes an in-depth explanation on how DOS manages disks, how drive letters are assigned, and disk-related IOCTLs. Emphasis is given to topic not covered in standard literature. Again this chapter is highly informative and detailed.

Chapter 17 (somewhat incongruously) deals with DOS errors, especially critical error handling. There simply doesn’t seem to have been a better place in the book for this. The final chapter synthesizes much of the material presented in the book and presents a XMS-based disk copy utility.

The final chapter of DOS Internals has a distinctly unfinished feel to it. The very last section mentions DoubleSpace, only to conclude that it is not worth paying much attention to as DoubleSpace does not significantly alter the DOS programming model. Somehow that doesn’t seem too relevant when discussing floppy disk copying via XMS.

The way the book is structured is somewhat unfortunate. There is a wealth of excellent reference material documenting various obscure interfaces, such as the various DOS/Windows communication channels or the SmartDrive control functions. The documentation sections are more or less randomly interspersed with expository material, which makes the book easier to read, but far harder to use as a reference.

For a book which came with a floppy disk containing source code, far too many pages are devoted to reprinting the disk’s contents. It is true that the source code is very heavy on comments and meant to be read, but simply duplicating the files is still a waste of paper.

Despite its flaws, DOS Internals is a brilliant book, guaranteed to bring new, often surprising facts to every DOS programmer. Although not all of the information presented in the book has immediate practical use, it is nevertheless very enlightening and explains many mysteries of DOS.

This entry was posted in Books, Development, DOS, Microsoft. Bookmark the permalink.

15 Responses to Book Review: DOS Internals

  1. Wow, MS-DOS drivers in C! .. oh well too little too late. I was a big fan of the later “Windows 95 Undocumented” .. where they showed how to use DPMI in your programs, that was very cool, although useless as you couldn’t write any ‘medium/large/huge’ programs as the runtime would freak out being in a larger address space…

  2. michaln says:

    The only thing crazy about writing DOS drivers in C is that Microsoft was too clueless to support that from the beginning. I think their DOS guys were all assembler gurus and didn’t necessarily realize how much can be done in C, or their C compiler wasn’t quite good enough. And by the time Microsoft’s C compilers were capable enough and had good enough optimization (perhaps version 5.0), attention had shifted to OS/2 and Windows… and the Real World, stuck with DOS, had to suffer writing drivers in assembler for many more years 🙂

  3. Igor says:

    Hi. Where u can buy the book? Is there some sites maybe u can find as ebook or something? Can u share this one if not a problem?

  4. Michal Necasek says:

    I got mine on Amazon (used). I’m not aware of any ebook edition.

  5. Alex Czarnowski says:

    This book is brilliant indeed – as a matter of fact most of Undocumented series books back then were brilliant or at least presented material that couldn’t be found in single place before. I’ve found it harder to read than the rest of Undocumented series due to specific writing style but it makes the book even more outstanding from the rest published by AW.

    As for writing TSRs in C the knowledge required to do it has been available years before the book. Take a look inside Anti4Us antivirus – it’s been written using Quick C.

    At the end I wish this book together with Undocumented DOS were published few years earlier. I would spent a lot less time with debugger to analyze how MS software really works. On the other hand I would miss a lot without that experience.

  6. Michal Necasek says:

    The usual problem… by the time a technology is well understood, it is obsolete. In fact in-depth understanding is probably a sign of obsolescence 🙂

    But yes, writing TSRs in C probably goes back to the mid-1980s. It was always a bit of black art but then that wasn’t specific to the implementation language.

  7. Vlad Gnatov says:

    So, I’m re-reading this very fun book.

    >The second part of the book is highly practical. Not satisfied with Microsoft’s standard response that "it can’t be done", the author explores how to write first TSRs and then device drivers in C. Only Microsoft C is considered, and it is questionable whether the method presented in the book is the most efficient or straightforward—but it does work.

    Well, exchanging code and data segments plus re-calculating and fixing EXE’s relocations at runtime was certainly clever. The compilers that can rearrange the segments at build time like BorlandC or Watcom were not so cool, but, I guess, you can’t write a few exciting chapters about a few lines in Makefile.

    These chapters aren’t about writing drivers in C, which was known since DOS 3.3 times but never popular(*), but about quickly converting an existing C program into a non-resident driver or even converting the program into TSR and then converting result into a resident driver. It was achieved by emulating the normal DOS environment at the SYSINIT stage. Clever but complicated tech.

    *) I know at least two books that mention writing dos drivers in C, first is Lai “Writing MS-DOS Device Drivers 2ed” 1992, discovered a few years ago on archive.org, and second is some book written by Adams. I actually never read it, but I have seen the driver example for BorlandC from that book. It was still in USSR, so I think it was in 1990, maybe even in 89.

  8. Michal Necasek says:

    “Writing DOS Device Drivers in C” by Adams and Tondo, copyright 1990. The book was not at all well known to me back in the day. Also on archive.org.

  9. Vlad Gnatov says:

    I’m quite sure I got these files at softpanorama seminar so the fall of 90 is most likely. I should find some time and put softpanorama’s e-zine on archive.org.

  10. SweetLow says:

    This book was in my wish list and as now it is available on archive.org I read it. And I got exactly what I hoped for and the wait was worth it. And as usual after reading such retro books it pushed me to enhance some of my retro tools 🙂

    >What is lacking is an explanation of author’s research methods; this is not to imply that the book’s contents are in any way untrustworthy or suspect, but knowing exactly how the author arrived at sometimes surprising conclusions would have been helpful.

    This can be said of all of the author’s work in the IT field. He gives you the bunch of exact information and it is unknown HOW it can be possible 🙂

    P.S. I’m glad that I could clarify for Geoff Chappell one not so obvious fact (and it was the first and only my contact with him).

  11. Michal Necasek says:

    I tried to correct his article about the Win386 format (they clearly used the XENIX X.out linker) but I think it was too late already 🙁

  12. SweetLow says:

    Yes, his life result is fixed forever now.

  13. Vlad Gnatov says:

    > This book was in my wish list and as now it is available on archive.org I read it.
    You’re welcome.

    > This can be said of all of the author’s work in the IT field. He gives you the bunch of exact information and it is unknown HOW it can be possible
    I’m pretty sure that Mr. Chappell’s main research method was reverse-engineering.

    > Yes, his life result is fixed forever now.
    Sad news. He was barely older than me 🙁

  14. SweetLow says:

    >I’m pretty sure that Mr. Chappell’s main research method was reverse-engineering.
    Of course. But my sentence was about the VOLUME of this work.

  15. SweetLow says:

    P.P.S. Just the one fun fact about this book. When I was fixing the bug in recent versions of HIMEM.SYS (hangup with /A20CONTROL:OFF option) I studied the sources of HIMEM.SYS from DOS6.0, found the code for using external A20 Line Control handler and immediately used this for realization of “always_on” handler for modern systems.
    And what I saw after reading this book? Geoff Chappell found this thirty years ago without any sources…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.