Making Utilities for MS-DOS


Michael Sokolov
English 4
Mr. Siedlecki
February 1, 1996

Making Utilities for MS-DOS

These days, when computers play an important role in virtually all aspects of
our life, the issue of concern to many programmers is Microsoft\'s hiding of
technical documentation. Microsoft is by far the most important system software
developer. There can be no argument about that. Microsoft\'s MS-DOS operating
system has become a de facto standard (IBM\'s PC-DOS is actually a licensed
version of MS-DOS). And this should be so, because these systems are very well
written. The people who designed them are perhaps the best software engineers in
the world.

But making a computer platform that is a de facto standard should imply a good
deal of responsibility before the developers who make applications for that
platform. In particular, proper documentation is essential for such a platform.
Not providing enough documentation for a system that everyone uses can have
disastrous results. Think of it, an operating system is useless by itself, its
sole purpose is to provide services to applications. And who would be able to
develop applications for an operating system if the documentation for that
system is confidential and available only to the company that developed it?
Obviously, only the company that has developed that operating system will be
able to develop software for it. And this is a violation of the Antitrust Law.

And now I start having a suspicion that this is happening with Microsoft\'s
operating systems. It should be no secret to anyone that MS-DOS contains a lot
of undocumented system calls, data structures and other features. Numerous books
have been written on this subject (see bibliography). Many of them are vital to
system programming. There is no way to write a piece of system software, such as
a multitasker, a local area network, or another operating system extension,
without knowing this undocumented functionality in MS-DOS. And, sure enough,
Microsoft is using this functionality extensively when developing operating
system extensions. For example, Microsoft Windows, Microsoft Network, and
Microsoft CD-ROM Extensions (MSCDEX) rely heavily on the undocumented internals
of MS-DOS.

The reader can ask, "Why do they leave functionality undocumented?" To answer
that question, we should look at what this "functionality" actually is. In MS-
DOS, the undocumented "functionality" is actually the internal structures that
MS-DOS uses to implement its documented INT 21h API. Any operating system must
have some internal structures in which it keeps information about disk drives,
open files, network connections, alien file systems, running tasks, etc. And MS-
DOS (later I\'ll call it simply DOS) has internal structures too. These
structures form the core of undocumented "functionality" in MS-DOS. This
operating system also has some undocumented INT 21h API functions, but they
serve merely to access the internal structures.

These internal structures are extremely version-dependent. Each new major MS-DOS
version up to 4.00 introduced a significant change to these structures.
Applications using them will always be unportable and suffer compatibility
problems. Every computer science textbook would teach you not to mingle with
operating system internals. That\'s exactly why these internal structures are
undocumented.

This bring another question, "Why does Microsoft rely on these structures in its
own applications?" To answer this question, we should take a look at an
important class of software products called utilities. Utilities are programs
that don\'t serve end users directly, but extend an operating system to help
applications serve end users. To put it another way, utilities are helper
programs. Perhaps the best way to learn when you have to mingle with DOS
internals is to spend some time developing an utility for MS-DOS. A good example
is SteelBox, an utility for on-the-fly data encryption. This development project
have made me think about the use of DOS internals in the first place and it has
inspired me to write this paper.

Utilities like SteelBox, Stacker, DoubleSpace, new versions of SmartDrive, etc.
need to do the following trick: register with DOS as device drivers, get request
packets from it, handle them in a certain way, and sometimes forward them to the
driver for another DOS logical drive. The first three steps are rather
straightforward and do not involve any "illicit" mingling with MS-DOS internals.
The problems begin in the last step. MS-DOS doesn\'t provide any documented
"legal" way to find and to call the driver for a logical drive. However, MS-DOS
does have internal structures, called Disk Parameter Blocks (DPBs) which contain
all information about all logical drives, including the pointers to their
respective drivers. If you think of it, it becomes obvious that MS-DOS must have
some internal structures like DPBs. Otherwise how would it be able