If you wanted to learn to play a nice game of chess, you could, I suppose, get a copy of the rules of the game and stare at them good and hard until you became an expert player. I suspect, however, that you would do a lot better by only briefly examining the rules and then playing hundreds of games, thinking each time about why you lost and how you perhaps could have won.
You might also realize that others must have traveled this path before you, and that they must have written down some of what they learned. In other words, beyond the actual rules of the game, which can be spelled out precisely in just a few pages, there must be a much larger body of written material that spells out some of the complex implications of those simple rules. You know: Move your pawn in this way, and your king will suffer a general-protection violation in the next move; that sort of thing.
Visit your local bookstore, go to the sports and games section, and open up a few books on chess. They are not mere restatements of the rules of the game. Because the rules of chess occupy less than ten pages, no publisher in the world could get away with restating the official rules and then reissuing them in a flashy cover.
Now go to the store's section of computer books. (It is a commentary on the sad state of the world that this section will probably be much larger than the sports and games section!) Randomly select a few books on DOS or Windows programming. The chances are quite good that these will be mere restatements of Microsoft's DOS and Windows programming manuals, that is, of the official rules for the games of DOS and Windows programming.
All this is just a roundabout way of saying that computer books ought to convey some experience the author has had, some strategies he or she has developed, some tricks or a style, or some traps to watch out for. There is no point in writing books containing the official rules.
There is no point in buying or reading such books, either; that's what the manuals are for. Now, I know, the manuals stink. Of course they do! But, if what you mean by "stink" is "don't tell me what I need to know to write my program," then the manuals are sort of supposed to stink. The rules of chess tell you how the pieces move, not how to play the game. Likewise, if you want something that shows how the moves of programming can be used in combination, or what move to perhaps use in a given situation, then you need something other than a manual: either a knowledgeable, patient coworker who's been through it already, or a book whose author plays this same role.
This month, then, I would like to introduce you to a few new coworkers who may -- I know, I'm getting my metaphors totally confused here -- give you a few pointers the next time you sit down to play the Game of DOS or the Game of Windows.
I normally don't buy product-specific computer books with titles such as Using Microsoft Assembler 6.0A or Borland C++ 3.O for Programmers (programmers, as opposed to, say, aerobics instructors or district regional sales managers who might be using a C++ compiler). Such books are, of course, a perfect invitation to the "let's just reissue the manuals" syndrome I'm talking about.
I'm also no longer much of a Turbo Pascal programmer. (It was once all I used, until DDJ technical editor Ray Valdes told me about this language called C. ) Just the same, I bought Neil Rubenking's Turbo Pascal 6.0 Techniques and Utilities the moment it came out. I'd had several e-mail exchanges with Neil while he was working on the book, and it seemed like he was putting a hell of a lot of original material into it. Pretty unusual, when anyone with enough coordination to manage a handheld scanner seems to be able to "write" a book these days.
Rubenking (who is technical editor of PC Magazine) has written an absolutely superb book on advanced Turbo Pascal programming. This book is a model of how product-specific computer books ought to be written. There's nothing in here that Neil hasn't checked out himself, seemingly nothing that was just lifted from Borland's manuals. In addition to Turbo Pascal itself, Rubenking provides detailed coverage of the Turbo Vision application framework, the BASM assembler, and the third-party Object Professional library from Turbo-Power.
The main thrust of Rubenking's book is to show how the object-oriented aspects of Turbo Pascal can solve real-world programming problems. The best examples of this are the book's two lengthy discussions of "data structures that map DOS information" and "objects for access to DOS data." Using object-oriented methodology to tackle something grungy such as undocumented DOS internals? That's right. About 70 pages are devoted to showing how Turbo Pascal objects can put a consistent, reusable interface on some of the most inconsistent, non-reusable data structures around: undocumented DOS internals. Because undocumented DOS data structures change from one version of the DOS to the next, and because a program doesn't know what version it's dealing with until run time, code that works with undocumented DOS is usually sprinkled with version checks, fields in data structures treated as byte offsets rather than fields, and so on. Neil's book shows the right way to manage these structures; his code for Turbo Pascal is applicable to C++.
The emphasis in this book is always on library building, that is, on how to write reusable code. In addition to my favorite, the DOS-access objects, two other nice examples are a cellular-automation package and an arbitrary-precision math package. There is an entire chapter on performance, excellent discussions of using TResourceFile, and a good introduction to internationalization.
Neil's book made me once again feel that maybe I ought to be using Turbo Pascal.
It must by now be difficult to write a reference manual for the Intel 8Ox86 microprocessor family without restating what's appeared in countless previous books on the subject. Robert Hummel's new reference, The Processor and Co-processor, naturally has no choice but to repeat a lot of what's already available in other books on the Intel architecture. After all, what can you say about instructions such as LAR or FSAVE that isn't in Intel's manuals?
Well, it turns out that there's one quite important thing that Intel doesn't talk about in its manuals or any other public forum: BUGS! Yes, like any other piece of complex software, the microcode in the Intel microprocessors has bugs. While Intel does provide "errata" for these chip anomalies under a nondisclosure agreement, it is naturally reluctant to make such information widely available.
Hummel's book now does just that. Besides an entire chapter on "Bugs and Incompatibilities," many of the individual reference entries for the processor and coprocessor instructions contain notes on bugs and undocumented features.
The way in which these chip bugs are presented does seem a little odd at times. Intel gives these bugs "errata" numbers, but these numbers do not appear in Hummel's book. Thus, the two best-known bugs, Erratum 17 and Erratum 21, are of course described, but not under those names. In addition, the multiply bug found on some B1 steppings of the 80386 (including the one I'm using right now), does not seem to appear anywhere in the book. Incidentally, code to test for the multiply bug can be found in the excellent, but now sadly difficult-to-find book, Advanced 80386 Programming Techniques, by James L. Turley (Osborne/McGraw-Hill, 1988).
Hummel's book contains a handy program to test for the processor and coprocessor type. If you also need to check for individual step levels such as B1, check out Jeff Prosise's "Tutor" column in the February 11, 1992 issue of PC Magazine.
It's interesting to compare Hummel's book with Rakesh Agarwal's 8Ox86 Architecture and Programming (Prentice Hall, 1991), which I reviewed in the March 1991 issue of DDJ. Hummel's treatment of bugs, incompatibilities, and anomalies is nowhere to be found in Agarwal's book. On the other hand, while the individual instruction descriptions in Hummel and Agarwal both include an section on the "algorithm" used by the instruction, where Hummel might say "Algorithm: None," Agarwal will show three pages of dense pseudocode. There's actually something to be said for both approaches; Agarwal can be a little overwhelming at times.
One case where Hummel says "Algorithm: None," and Agarwal shows three pages of pseudocode happens to be the undocumented LOADALL instruction. While both books cover the form of this instruction found on the 80286, neither has it for the 80386. For that, you need to consult an amazing article, "The LOADALL Instruction," by Robert Collins (Tech Specialist, October 1991).
Besides the material on chip bugs and incompatibilities, other good sections of Hummel's book include discussions of the two different ways of doing floating-point emulation, and a chapter on mixing 16-bit and 32-bit code. I still think Agarwal's is the best book on this subject, but hard-core Intelophiles will definitely find Hummel's book, with its discussion of chip bugs, a worthwhile addition to their bookshelf.
One of the great, less-explored areas of Windows programming is the Microsoft Windows Device Driver Kit (DDK). The DDK should interest a much larger group of programmers than those actually responsible for writing Windows device drivers. When Windows programmers think they've stumbled across something that's undocumented, it often turns out they've simply come up against something that's in the DDK. The DDK contains some of the most interesting and powerful things in Windows. In addition to manuals and tools the DDK contains source code for most of the 16-bit and 32-bit device drivers in Windows: an amazing resource!
But those DDK manuals are really bad! (And at around $350 for the DDK, they're not cheap either.) The DDK manuals contain such pearls of technical writing as "Exit: Any allocated stuff associated with the application is freed." The term "termination" is never used when the words "nuke" and "crash" can be used instead. In other words, the programmers wrote this stuff. There's great information here, but it's so badly presented it almost makes you feel respect and gratitude for the Windows Software Development Kit (SDK) manuals. Well, almost.
The DDK manuals cry out for someone to present this information in a more mature (and cheaper!) form. Dan Norton's new book, Writing Windows Device Drivers, takes a first step toward this goal. I wish he had departed more from the DDK style (for example, like the DDK, he presents C prototypes for functions currently callable only from assembler), but it is good just having some of this information available in a more palatable form.
I did have one big problem with this book: it does not present a single sample program. A coupon in the back of the book can be used to order a disk of sample programs, and the DDK itself comes with tons of sample code, but Norton's book really needed to walk the reader through the process of creating both Windows device drivers and 32-bit virtual device drivers (VxDs). Norton seems to have thought too much of the reader who already owns the DDK, and not enough of the numerous Windows programmers who don't, and who will buy his book just to find out a little bit about what goes on in the netherworld of Windows.
Certainly, any programmer interested in learning more about what makes Windows tick ought to get Norton's book. Even with the problems I've cited, there's lots of good stuff here. For example, an appendix on "Device Driver Support Functions" presents a number of useful undocumented Windows API calls (such as the Get/SetSelectorBase/Limit functions) that can be called from both device drivers and normal Windows applications. Another section describes the useful undocumented system-timer calls in SYSTEM.DRV.
Copyright © 1992, Dr. Dobb's JournalWriting Reusable Code
Revealing Chip Bugs
Windows Devices