DOS OEM Adaptation Kit (OAK) contains commented source code for some MS-DOS
modules and include files and .OBJ files made from some other modules.
Let’s summarize what we’ve seen so far. MS-DOS, like any other operating system,
has internal structures. Every computer science textbook would teach you not to
rely on an operating system’s internals. In MS-DOS, the internal structures are
undocumented. Microsoft’s own utilities do rely on them. By reverse engineering
these utilities, looking at the MS-DOS source code, and thinking the problem
through one can come to the conclusion that there is absolutely no safe way of
using the MS-DOS internal structures. The only proper way of using them is not
using them at all.
Not later than I have come to this conclusion, my SteelBox development project
returned me back to the reality. No matter how bad it is to use of the MS-DOS
internals, utility developers like me have to do it because they have no other
choice. Now I’m almost sure that this is precisely why Microsoft uses the MS-DOS
internals itself. Before we go any further, I need to clarify one important
detail.
Once a programmer asked Microsoft to document the INT 2Fh/AH=11h interface,
generally known as the network redirector interface. Microsoft responded:
The INT 2fh interface to the network is an undocumented interface. Only INT 2fh,
function 1100h (get installed state) of the network services is documented.
Some third parties have reverse engineered and documented the interface (i.e.,
“Undocumented DOS” by Shulman [sic], Addison-Wesley), but Microsoft provides
absolutely no support for programming on that API, and we do not guarantee that
the API will exist in future versions of MS-DOS.
This sounds like Microsoft saying, “Here’s where you get the info, but you
better not use it.” (Schulman et al., Undocumented DOS, 495). Some people might
think that Microsoft has internal confidential documents describing the MS-DOS
internals much better than Andrew Schulman’s Undocumented DOS, but there are
indications that the MS-DOS source code is the only “document” Microsoft has
(I’ll address this issue in a few paragraphs). Perhaps the Microsoft’s
programmers themselves use the same documentation as third parties.
So far we have seen that MS-DOS is not a perfect operating system, and it gives
utility developers no other choice but to use its undocumented version-dependent
internals. The reader might ask, “what can we do about it?” First of all, some
of the former undocumented DOS functionality was documented in DOS version 5.00.
The reason for that probably was that some INT 21h functions that were used by
DOS external commands like PRINT don’t actually deal with any DOS internals at
all, and Microsoft had simply underestimated the usefulness of these functions
originally. Microsoft has even documented the DPBs. However, Microsoft’s
documentation says that the DPBs are available only in DOS versions 5.00 and
later, but the reader should remember that the DPB format has changed several
times throughout the history. So in this case Microsoft even restricted
themselves in the ability of making changes in MS-DOS by documenting the DPBs.
However, there are still a lot of undocumented internals in MS-DOS. It should be
noted that documenting them is out of question. This would make it impossible to
make significant changes in MS-DOS, thereby stalling its enhancement. In
Undocumented DOS Andrew Schulman suggests that Microsoft could make an add-in to
MS-DOS that would provide “clean” documented services that would eliminate the
need for the use of DOS internals. Once Microsoft actually did this, when it
introduced the IFSFUNC utility in MS-DOS version 4.00. This utility converted
the “dirty” and extremely version-dependent redirector interface into a device-
driver-like interface. However, this utility was removed from MS-DOS versions
5.00 and later (I’ll explain why in a few paragraphs).
Fortunately, the ill-fated IFSFUNC utility was not the only effort to enhance
MS-DOS. In Microsoft Windows versions 3.00 through 3.11, there is a component
called Win386. It has got its name from Windows/386, its ancestor. In early beta
releases of Microsoft’s Chicago operating system this component was called
DOS386. When Chicago was renamed into Windows 95, this component was given
uninteresting name VMM32. Finally, the beta release of Microsoft C/C++ Compiler
version 7.00 included this component from Microsoft Windows under the name
MSDPMI. I think that the best name for this component is DOS386, so I’ll call it
this way.
Probably the reader would ask, “What this component is?” DOS386 is a
multitasking protected-mode operating system. A close inspection of DOS386
reveals that it has almost nothing to do with Windows, and has a lot to do with
DOS (that’s why I prefer the name DOS386 over Win386). Two of DOS386’s
subcomponents, DOSMGR and IFSMGR, are perhaps the heaviest users of DOS
internals. These modules know a lot about the internals of MS-DOS, and they
provide their own interfaces which in fact can help an utility avoid using DOS
internals. For example, let’s return to our SteelBox utility.
This utility needs to access a file from inside an INT 21h call. Most DOS
programmers know that DOS INT 21h API is non-reentrant. It means that no INT 21h
calls can be made while an INT 21h call is already being serviced. Therefore, an
utility like SteelBox would have to play tricks with DOS internals with all the
consequences. On the other hand, DOS386’s IFSMGR subcomponent provides an
interface that replaces INT 21h. Unfortunately, IFSMGR is documented only in the
Windows 95 Device Development Kit (DDK), and I don’t have a copy of it yet.
However, it is quite possible that the IFSMGR’s interface is reentrant. If it is,
all problems with SteelBox would be immediately solved, and it won’t contain a
single undocumented DOS call. Keep in mind, however, that DOS386 is relatively
new, and perhaps its current version doesn’t provide all the desired
functionality. But certainly DOS386 is definitely a good foundation for a new
operating system.
Although I definitely don’t want to overblame Microsoft, I have to say some
unpleasant truth about this company. In their run for profit, people at
Microsoft violates some principles of free enterprize. In other words, they try
to make a monopoly. One of the unfair things Microsoft does is called
discriminatory documentation. Although the source code for MS-DOS, Microsoft
Network, and other Microsoft products is supposedly unavailable to anyone,
Microsoft has made the source code of some utilities available to selected
vendors (Schulman et al., Undocumented DOS, 495).
Another example is the deliberate incompatibility of some Microsoft products
with Digital Research’s DR-DOS. Some programs, including Microsoft Windows
version 3.10 beta and Microsoft C Compiler version 6.00, contain special code
with sole purpose of making them incompatible with DR-DOS and other DOS
workalikes. Although I’m definitely not a supporter of DOS workalikes, I think
that Microsoft should use fair methods of competition.
Finally, there is a big problem with Microsoft’s packaging of MS-DOS and DOS386.
The most important problem with DOS386 is that it’s currently available to users
only as Win386 in Microsoft Windows. Furthermore, the usual Windows technical
documentation (except the DDK) doesn’t even mention the existence of Win386,
because it’s actually not a part of Windows. As a result, an amasing number of
programmers don’t even know about DOS386 (or Win386), and many of those how do
greatly underestimate its tremendous importance.
Now Windows 95 comes into play. In this package, MS-DOS, DOS386, and Windows are
thrown into one melting-pot. First of all, the integration of MS-DOS and DOS386
is a very good step. Given the volatility of DOS internals, the DOSMGR
subcomponent of DOS386 (which, remember, is perhaps the heaviest user of DOS
internals) cetainly should be tied to one specific DOS version. However, the tie
between DOS/DOS386 and Windows is largely artificial. Try a simple experiment.
Rename KRNL386.EXE file in your WINDOWS\SYSTEM directory into something else,
and put something else (COMMAND.COM fits nicely) into that directory under the
name KRNL386.EXE. And then try to run Windows. But instead of running Windows,
this would load and activate Win386 without loading Windows. And there is no
magic in this simple experiment. KRNL386.EXE is the first module of Windows, and
Win386 runs it when it completes its initialization. By putting something else
in place of KRNL386.EXE, one can break the artificial tie between Windows and
DOS386.
At some point of time Microsoft probably throught of making a version of DOS386
which would not be tied to Windows. There was an utility called MSDPMI in the
beta release of Microsoft C/C++ Compiler version 7.00, which was that very
DOS386 without Windows. But now Microsoft is abandoning MS-DOS and everything
else that is not Windows. Microsoft tries to persuade users that Windows 95
doesn’t contain a DOS component, but this is not true. It is simply tied into
Windows.
Now let’s summarize the above. Microsoft is ignoring the minority users who
don’t like Windows and who want to use MS-DOS and DOS386 without Windows,
because Microsoft cares only about its profit. One person cannot stop them doing
that. Therefore, we, the programmers, should unite. If I call Microsoft alone,
no one would listen to me. But if thousands of us do it together, we might
achieve something. If you have any questions or suggestions about creating an
association of programmers against Microsoft, please send E-mail to Michael
Sokolov at gq696@cleveland.freenet.edu.
Bibliography
Brown, Ralf. The MS-DOS Interupt List. Not published on paper, available online
for free.
Chappell, Geoff. DOS Internals. New York: Addison-Wesley Publishing Company,
1994.
Microsoft Corporation. Microsoft Windows Device Development Kit. Computer
software. Redmond: Microsoft, 1990.
Pietrek, Matt. Windows Internals: The Implementation of the Windows Operating
Environment. New York: Addison-Wesley Publishing Company, 1993.
Schulman, Andrew. , Ralf Brown, David Maxey, Raymond J. Michels, Jim Kyle.
Undocumented DOS: A Programmer’s Guide to Reserved MS-DOS Functions and Data
Structures. New York: Addison-Wesley Publishing Company, 1994.
Schulman, Andrew. , David Maxey, Matt Pietrek. Undocumented Windows: A
Programmer’s Guide to Reserved Microsoft Windows API Functions. New York:
Addison-Wesley Publishing Company, 1992.