Читать реферат по английскому: "Making Utilities For MSDOS Essay Research Paper" Страница 1

(Назад) (Cкачать работу)

Making Utilities For MS-DOS Essay, Research Paper

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

Похожие работы