[ ERCB Home |
New |
Feature |
Brief |
DDJ |
Letters |
Links
]
Beyond the Official Rules
Review by Andrew Schulman
Copyright (C) Dr. Dobb's Journal, April, 1992
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.
Writing Reusable Code
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.
Revealing Chip Bugs
It must by now be difficult to write a reference manual for the Intel 80x86
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 80x86
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.
Windows Devices
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.
Turbo Pascal 6.0 Techniques and Utilities
Neil J. Rubenking
Ziff-Davis Press, 1991
1892 pages (with disk), $39.95
ISBN 1-56276-010-6
PC Magazine Programmer's Technical Reference:
The Processor and Coprocessor
Robert L. Hummel
Ziff-Davis Press, 1992
761 pages, $49.95
ISBN 1-56276-016-5
Writing Windows Device Drivers
Daniel A. Norton
Addison-Wesley, 1992
434 pages, $29.95
ISBN 0-201-57795-X
Electronic Review of Computer Books
Created 5/1/96 / Last modified 6/15/96 / webmaster@ercb.com