Making Utilities For Ms-dos
Making Utilities For Ms-dos

Making Utilities For Ms-dos

Available Only on StudyHippo
  • Pages: 9 (4355 words)
  • Published: November 5, 2018
Text preview

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 anothe

View entire sample
Join StudyHippo to see entire essay
View entire sample
Join StudyHippo to see entire essay

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 to service

the INT 21h API requests? How would it be able to locate the driver for a

logical drive it needs to access?

Many people have found out about DPBs in some way (possibly through disassembly

of DOS code). In the online community there is a very popular place for

information obtained through reverse engineering, called The MS-DOS Interrupt

List, maintained by Ralf Brown. This list is for everyone’s input, and the

people who reverse engineer Microsoft’s operating systems often send their

discoveries to Ralf Brown, who includes them into his list. The DPB format and

the INT 21h call used to get pointers to DPBs are also in Interrupt List. As a

result, many programmers, including me, have used this information in their

utilities without much thinking.

However, this is not a good thing to do. DPBs exist since the first release of

MS-DOS as IBM PC-DOS version 1.00, but the DPB format has changed three times

throughout the history. The first change occured in MS-DOS version 2.00, when

the hard disk support, the installable device drivers and the UNIX-like nested

directories were introduced. The second change occured in MS-DOS version 3.00,

when the array of Current Directory Structures (CDSs), a new internal structure,

was introduced to support local area networks and JOIN/SUBST commands. The third

change occured in MS-DOS version 4.00, when 32-bit sector addressing was

introduced and an oversight with storing the number of sectors in a File

Allocation Table (FAT) was fixed. The reader can see that each new major MS-DOS

version up to 4.00 introduced a change in the DPB format. And this is typical

with all MS-DOS undocumented internal structures.

Although one can probably ignore DOS versions earlier than 3.10, he still would

have to deal with two different DPB formats. And prior to DOS version 5.00,

where DPBs were finally documented, no one could be sure that a new DOS version

wouldn’t change the DPB format once again. In the first version of SteelBox, my

utility that needs to know about DPBs in order to do its work, I simply compared

the DOS version number obtained via INT 21h/AH=30h with 4.00. If the DOS version

was

View entire sample
Join StudyHippo to see entire essay