25 Jun 1995

DOS

Application programs running under DOS have full system privileges. They can access any storage, change the CPU control functions, and use any hardware device. This allows some programs to extend the DOS operating system with additional functions, but it also allows virus programs to damage the machine.

Although DOS 6.x is distributed on 4 or 5 disks, this space is filled with utility programs to compress data, perform backups, and check programs for virus infection. The DOS operating system itself is contained in a pair of hidden files named IBMBIO.SYS and IBMDOS.SYS (for IBM versions of DOS) or IO.SYS and MSDOS.SYS (for Microsoft versions of DOS).

DOS services are requested when an application program issues an INT 21 instruction. This instruction looks up the entry point of the DOS service manager in a hardware table and jumps to a routine in the IBMDOS (or MSDOS) module.

In other operating systems, an application must make a system call to request services. DOS application programs run with full privileges, so a program can do anything it wants if it has enough program logic to handle the hardware directly. DOS services provide, instead, a convenient set of useful services that programs request because they do not want to be bothered with details.

DOS=FAT File System

For example, the BIOS support for a hard disk (INT 13) provides raw access to the data. Through the BIOS every disk letter looks like one big file. DOS manages the File Allocation Table (FAT file system) that breaks the disk up into named files and subdirectories. Most of the DOS services offered to programs involve access to files on disk (open, close, read, write, rename, delete, make directory, remove directory, list directory).

A few programs will bypass the DOS services and interpret the FAT themselves. The Norton Disk Doctor and some of the Undelete utilities may examine and rebuild the FAT. Backup programs generally provide their own hardware level support for the hard disk and diskette so that they can avoid the DOS/BIOS limitations and do I/O asynchronously in the background. A good backup program will be writing the last block of data to diskette, compressing the current block, and reading the next block in from disk, all at the same time. This is not possible with standard DOS/BIOS services, but the hardware allows it and a clever program can access the hardware directly.

DOS also allocates storage in the user area. In addition to the first 640K, DOS can be configured to use the 386 memory management hardware to "fill in" unused areas in the middle 128K hardware address range (from C0000 to DFFFF using hex notation). This becomes the Upper Memory Blocks and is used to load drivers and other resident support routines.

The remaining DOS functions are housekeeping. For example, there are the services to query and set the time of day or date. DOS itself provides a minimal amount of function. It is possible to load other programs that provide additional services (video, mouse, network, compression, ...). DOS has been able to survive for fifteen years because it was so simple and could easily be extended by other programs.

Drivers and TSRs

DOS can be extended by device drivers, resident routines (TSRs), and shells. Device drivers are loaded first, using the DEVICE statements of the CONFIG.SYS file. Resident routines can be loaded at any time, but they are most commonly installed by statements in AUTOEXEC.BAT. A shell takes over the user interface and loads other programs. The most common example of a shell is Windows 3.1.

Add support for a CD-ROM, a network adapter, PCMCIA, disk cache, and a few other useful features. Soon the amount of space left for DOS programs becomes impossible. DOS did acquire a few tricks to extend its life. Putting most of the operating system in the first 64K after the one megabyte address helped a bit. Creating Upper Memory Blocks using the 386 memory management hardware to remap the unused 128K reserved for adapter cards helped a bit.

However, there is not enough room in DOS to load the Novell client, the Windows NT client, the TCP/IP protocol for the Internet, support for the COM line, SCSI adapter drivers, the CD-ROM file system, and all the other junk of modern life. A typical DOS user has to develop several different configurations, and reboot to select the correct configuration before loading certain programs. After doing this for a while, the user is ready to move on to a real operating system.

Conclusions

DOS depends on the BIOS, so it inherits the two limitations. Buffers must be in the 640K area. I/O operations are synchronous, so the CPU is completely tied up when any single disk is processing a request.

To keep the system small and simple, DOS lacks the sophisticated memory and program management that would be needed to load routines on demand. If a DOS program needs a service, then the support for that service must have been previously loaded. Children quickly learn that before they can play any DOS games that need to use the mouse, they must first load MOUSE.COM into memory.

Once support has been loaded, the only assured way to unload it is to reboot the system. If a user brings DOS up with only minimal support, then there is a chance that programs will not have the functions they need to run. Bring it up with all the drivers and routines loaded, and there may not be enough memory left to run a desired application. DOS users solve this problem by keeping dozens of specialized configurations around, each one optimized to run a different package. Rebooting DOS every time you want to change programs gets to be annoying and may eventually push the user to consider a real operating system.

Continue Back PCLT