Making Utilities For Ms-dos Essay Example
Making Utilities For Ms-dos Essay Example

Making Utilities For Ms-dos Essay Example

Available Only on StudyHippo
  • Pages: 4 (1042 words)
  • Published: November 5, 2018
  • Type: Case Study
View Entire Sample
Text preview

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 everyo


ne 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

View entire sample
Join StudyHippo to see entire essay

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

Get an explanation on any task
Get unstuck with the help of our AI assistant in seconds