Geoff Chappell - Software Analyst
Many DOS programmers will have found that some tasks simply cannot be programmed using only the information contained in technical references. DOS has a secret side and programmers who know it can perform seemingly impossible tricks. It is intrinsic to the notions of secrets, however, that access to them is not easy, so to quite a few programmers, even serious DOS experts, a 700-page book titled Undocumented DOS will seem like manna from heaven.
Programmers who need to know about unlisted functions, mysterious structures and flags or just more detail on how DOS accomplishes its normal work have had to rely on the scattered, vague and often contradictory material published thus far - an unhappy situation indeed, which this book sets out to remedy.
For the most part, Undocumented DOS confines its scope to the central components of DOS. To DOS programmers, DOS is the Int 21h interface when seen from inside their programs and the command processor outside. System resources are examined from DOS’s perspective to see how the information gained may be put to good use in applications.
However, the book is a lot more than a list of undocumented DOS functions and examples of their use. The readers (assumed to be fairly knowledgeable and treated as such throughout the book) is guided through programming techniques not often touched upon. Assembly language is used sparingly, the opportunity being taken to show how almost every topic (even TSR programming) can be implemented in a high-level language.
Still, whatever its objectives and style, a book on this subject, claiming to give detailed descriptions of DOS’s undocumented functions and structures, is open to assessment on its comprehensiveness and the reliability of the information it contains.
The book’s annotated list of undocumented DOS functions is an extract from the very much larger Interrupt List, well-known to the on-line community and described in the book as the one truly definitive, absolutely reliable list of DOS calls. The full list is supplied in a hyper-text version on one of the 1.2MB disks which accompany the book.
An objective assessment of the list’s completeness is a little tricky, since the subject is to some extent open-ended. In those cases in which DOS calls other programs, it may simply be impossible to deduce everything about such calls from the code in DOS alone. Quite reasonably, the greatest effort has been concentrated on DOS’s core and readers must expect to see the word unknown when the book touches on matters outside its primary scope.
Against this, it must be remarked that there are several complete omissions even from the Int 21h interface and that the easy majority of unknowns can be resolved by inspection of only the DOS kernel and programs supplied with it as standard (particularly SHARE and IFSFUNC). Although only some contributing authors raise the matter of disassembly, it has certainly taken place. How else can it be known for instance that the unknown argument of Int 2Fh function 122Fh is required in register DX? Why else are those fields in the Swappable Data Area which are incremented or decremented in the DOS code described as ‘unknown flag or counter’ rather than just unknown?
That the book should mention the Swappable Data Area at all, much less attempt to detail it and illustrate its effective use in TSRs, is very welcome and demonstrates that Undocumented DOS is more comprehensive than anything which has gone before. Also welcome is a discussion of the SEGDEBUG interface and documentation on network redirectors, a topic said to be mysterious even within Microsoft. Even so, the information given on redirectors is better viewed as exploratory, for it is too vague to be much help in writing a serious installable file system - it misses the attribute word at offset 0Ch in the IFS driver header, for instance.
Of course, omissions and incompleteness are not likely to cause harm. The authors are commendably frank about the limits to their knowledge and imbue a proper sense of caution. DOS features which are largely unknown are not going to be incorporated into tomorrow’s software without further investigation by developers and the book does a good job of pointing the way, even providing a script-driven utility for spying on interrupt communications.
Much more concern must be given to the reliability of some descriptions of DOS’s inner workings. Descriptions of memory allocation strategy and of actions taken to open a file contain errors of fact (although they may be popular misconceptions). According to the book, when DOS opens a file, it searches for a free entry in the handle table belonging to the current process and then for a free System File Table. In fact, it looks through the SFTs first - a difference which is not trivial, being the source of a DOS bug not mentioned in the book. Similarly, the distinction between a device driver and file need not be delayed as the book asserts: DOS’s pathname parsing routine will search the device driver chain in some circumstances (the source of a bug which is mentioned in the book) and this is even shown in another chapter by the conversion of A:CON to A:/CON.
Pehaps it is unfair to labour such points, given a generally fine book, but precisely because Undocumented DOS will be regarded as a standard reference for its subject matter, it is important to note it has lapses in reliability. This is nowhere more apparent than the several bugs which afflict the DEVLOD program for loading device drivers from the command line. In short, because its author does not seem to understand the reason behind one of the fields in DOS’s List Of Lists, using DEVLOD to load ANSI.SYS from the command line has the possibly undesirable result that Ctrl-C and Ctrl-Break will not be effective when programs have their standard input redirected from a file. For much the same reason, combined with a misuse of undocumented function 32h, the ability of DEVLOD to load block device drivers in the presence of SUBSTed drives is suspect, despite claims. Thus, on a system with hard disk partitions C: and D: and a drive E substituted for a directory on drive C, using DEVLOD to load a block device driver (as drive F) is very unpleasant for drive D and is not a success for F: either.
More subtle is the construction of double-checks based on observations that are not supported by careful analysis. The clearest example is the run-time determination of System File Table size to allow verification against the size known from the DOS version number. The book assumes that the SFTs will be ordered AUX then CON, but this need not be true, for the arrangement can be manipulated by software using only documented DOS functions (though a good reason may be hard to produce).
Such problems aside, however, Undocumented DOS is a serious, responsible study which succeeds on the whole in demonstrating the safe use of DOS’s secret side to expand programming horizons.
Title: Undocumented DOS
Author: Andrew Schulman, et al