DOS 2.0 and 2.1

Hello, UNIX!

The PC/XT

IBM released Personal Computer DOS 2.0 on March 8, 1983 together with the IBM PC/XT. The world was a very different place from August 1981; rather than being a big unknown, the IBM PC was now a major force to be reckoned with. The PC/XT cemented IBM’s position in the market. Compared to the original IBM PC, the PC/XT added more RAM and, importantly, a built-in fixed disk.

Hard Disks and FAT

The development of DOS 2.0 was to a large degree driven by hardware advances, notably the need to manage fixed disks. Rather than developing a new file system (or perhaps borrowing an existing one from XENIX), Microsoft decided to simply extend FAT to fixed disks. Since FAT already used 12-bit cluster numbers, it could handle over 4,000 clusters; a single partition on the standard PC/XT 10MB fixed disk simply needed to use 4KB clusters.

Because the FAT filesystem was not dependent on the underlying disk geometry, adapting the existing code designed for floppies was remarkably simple. The FAT was made a few sectors larger, the root directory could store more entries, et voilà—DOS supported hard disks.

A New DOS

DOS 2.0 was the first version which had been developed entirely at Microsoft, with design objectives very different from those of 86-DOS. Since 1979, Microsoft had been licensing UNIX from AT&T and marketing it under the XENIX trademark. Microsoft’s programmers were exposed to UNIX concepts and ideas, with DOS 2.0 being very much a proof of the exposure.

The primary developers of DOS 2.0 were Paul Allen (who led the team), Mark Zbikowski, and Aaron Reynolds. The other team members were Nancy Panners, Chris Peters, and Mani Ulloa; only six people developed DOS 2.0. Tim Paterson had returned to SCP and wasn’t involved in the development of DOS 2.0.

The UNIX concepts implemented in DOS 2.0 were:

• Hierarchical directories
• Redirection (pipes)
• Background execution (daemons)

There was another new feature in DOS 2.0 which was not borrowed from UNIX and in the long run proved key for the PC market: installable device drivers.

Directories

There were two options for managing the larger fixed disk storage: either splitting the disk into several floppy-sized partitions (the CP/M approach) or a hierarchical directory structure (the UNIX approach). Microsoft decided to implement the latter solution; it was obvious that the directory option was scalable, unlike the partitioning approach.

The on-disk structures changed remarkably little, with the addition of a single attribute bit to indicate that a directory entry was itself a sub-directory. The impact on the OS and applications was far greater.

The CP/M style of file management through FCBs (File Control Blocks) could not be used with directories. Microsoft implemented UNIX-style handle-based file management where a file name with optional path is used to open a file, but all subsequent operations only use a file handle.

A regrettable decision was to use the backslash as a path separator in DOS. The forward slash, used as a path separator on UNIX, had been already used as a CP/M style command line option separator. The desire for backwards compatibility with soon to be entirely irrelevant 1.x versions of DOS thus created a huge forwards incompatibility with the rest of the computing world.

Redirection

The use of handles for file I/O enabled a greater degree of device independence. A newly started program received standard handles for input and output; the handles typically referred to the console (i.e. keyboard for input and graphics card for output) but could be redirected.

The input and/or output of a program could be taken from or directed to a file. The command processor (COMMAND.COM) extended to concept to implement piping, where the output of one program is used as input by another program.

While UNIX (where the concept was borrowed from) implements piping with actual pipes (in-memory buffers), DOS was not capable of executing two programs simultaneously. DOS simulated piping by redirecting the output of the first program to a temporary file, then feeding the file as input to the next program, and finally deleting the temporary file.

Background Execution

DOS 2.0 did not support anything like UNIX-style multitasking, but used the concept of TSRs (Terminate and Stay Resident) programs to approximate some of the functionality. The PRINT.COM utility was a print spooler somewhat similar to the UNIX lpr daemon.

PRINT.COM was able to run in the background and spool output to a printer. This capability was very useful with the slow printers of the time; users could continue working with their PC and did not have to wait for the printer to finish first.

The PRINT utility was one of many Microsoft’s controversial programs which used undocumented DOS interfaces. PRINT.COM was a TSR, a functionality which was initially not well documented. Even after Microsoft documented the calls required to write a TSR, safely using DOS services from within a TSR was still undocumented. Since DOS was not a re-entrant operating system, it was only safe to invoke a DOS service (usually through INT 21h) while no other DOS call was executing. PRINT.COM utilized knowledge of DOS internals to determine when it’s safe to call DOS services, and hooked a special DOS call which was invoked when DOS was idle (waiting for user input). It took Microsoft eight years (after the release of DOS 5.0) to document most of these calls.

Installable Drivers

Together with the original PC, IBM published very detailed documentation on the PC’s hardware and software. That quickly led to a multitude of various expansion boards and add-on hardware. Any new hardware not 100% compatible with IBM’s also needed software support, which often included modifying DOS one way or another.

Because DOS 1.x was not designed to be easily extensible, modifications were done by directly patching DOS in ways which typically only worked with a specific DOS version. When DOS 2.0 was in development, a need for a more controlled solution was recognized. DOS 2.0 included support for loadable drivers (usually with a .SYS extension) and introduced CONFIG.SYS, a simple text configuration file which could direct DOS to load drivers at start-up.

DOS 2.0 supported characters and block device drivers which interfaced directly with the operating system and could provide an IOCTL interface to specialized applications. The basic idea of drivers was taken from UNIX, but with a significant twist: binary driver interface. UNIX systems at the time required recompilation or at least re-linking of the kernel when a driver was added or removed. DOS on the other hand allowed hardware manufacturers to ship a single binary driver which worked across various versions and OEM releases of DOS.

The significance of loadable driver support in DOS cannot be overstated. Over the years, many extensions to DOS were implemented as drivers. The mechanism was relatively simple, yet powerful. Support for new network adapters, SCSI host adapters, CD-ROMs, etc. would have been much more difficult without loadable drivers.

DOS 2.0

When Personal Computer DOS 2.0 was released, IBM kept selling DOS 1.1 for customers with low-spec machines. DOS 2.0 itself was upwardly compatible with 1.1, but required about 12KB more RAM, which could make a big difference for systems with just 64KB or so of memory. For systems with more fully populated memory banks, DOS 2.0 was a significant upgrade.

DOS 2.0 supported 9-sector diskette formats, adding 180KB and 360KB capacities to the existing 8-sector 160KB/320KB formats. The change did not require any hardware update, IBM simply realized (after Tim Paterson pointed it out to them) that the 8-sector format was unnecessarily conservative and it was safe to use 9 sectors per track. This modification increased the storage capacity of existing media by 12.5%, and doubled the number of disk formats supported by DOS.

The increased storage capacity was applicable to both single-sided and double-sided drives. DOS 2.0 was shipped on 180KB disks to be compatible with the original PCs with single-sided drives. A new ‘supplemental’ disk was added, with development tools (LINK, DEBUG, and EXE2BIN) and BASIC demonstration programs, not significantly changed since version 1.1.

Disk Utilities

Several disk utilities were added or updated, chief among them being FDISK.COM, written by David Litton at IBM. At the time, FDISK was not part of DOS per se; fixed disks were somewhat hardware specific, as was partitioning. DOS only knew how to work with disks through the BIOS-provided INT 13h interface.

The early FDISK versions only managed fixed disks in terms of cylinders, even though the partition tables stored on the disk itself did not have any such limitation and partitions could theoretically start and end on any sector boundary. The multiple-of-cylinder limitation remained in many later tools for compatibility reasons, and caused quite a few headaches.

The FORMAT, SYS, CHKDSK, BACKUP, and RESTORE utilities were all updated to support fixed disks. With the FDISK, FORMAT, and SYS utilities, it was possible to make a fixed disk bootable and for the first time start DOS without a boot floppy.

The ASSIGN.COM utility was added for backwards compatibility with DOS 1.x application. Since DOS 1.x did not support directories, applications written for it could not access any data in subdirectories. The ASSIGN utility could create a virtual disk by assigning a drive letter to a directory. That way, DOS 1.x applications could be used.

IBM also added TREE.COM, a simple utility to display the tree-like directory structure. Note that the DIR /S command did not exist yet.

Updated COMMAND.COM

The interactive shell, COMMAND.COM, underwent significant changes. Support was added for UNIX-style environment variables and the SET command.

Several commands were added to work with directories: CD/CHDIR (change directory or display current directory), MD/MKDIR (create a new directory), and RD/RMDIR (remove a directory). The PATH command was used to set the search path for executable files. The VOL command could query volume labels, and the VERIFY command was used to control read-after-write verification.

The CLS command was added to clear the console, and CTTY could change the console (TTY or teletype) device for printer or serial port redirection. The PROMPT command could adjust the command prompt; the default was unchanged since DOS 1.1 (i.e. C>) but could be set to the now-classic C:\> with ‘PROMPT $P$G’. The ECHO command would simply print its arguments. The VER command displayed the COMMAND.COM version.

The batch language was significantly overhauled in DOS 2.0. Besides the ability to use environment variables, branching was now supported with the IF command. EXIST, ERRORLEVEL, NOT, FOR, GOTO, and SHIFT were added to enhance the batch file capabilities.

Finally, the EXIT command was added to terminate batch files and nested COMMAND.COM instances.

Other Enhancements

DOS 2.0 added dynamic memory management; indeed DOS 1.x did not support dynamic memory allocation or deallocation.

Support was added for volume labels implemented through a new attribute bit.

The classic MORE.COM command was added to take advantage of the new piping capability. Its most typical use was perhaps ‘TYPE foo.txt | MORE’, to paginate the output of the TYPE command. SORT.EXE was another UNIX-style command, typically used together with the piping capability to sort the output of other commands.

The PRINT.COM command mentioned earlier was added to provide print spooling and background printing.

Disk and Advanced BASIC were both updated to version 2.0.

ANSI.SYS, the only loadable device driver shipped with Personal Computer DOS 2.0, was added to provide ANSI terminal emulation.

Easter Egg

The RECOVER.COM command  contains an interesting hidden message. If the user presses Ctrl+W when prompted to “press any key” to start file recovery, the following message is printed: “Chris Peters helped with the new dos! Microsoft rules ok”. Chris Peters was one of the above mentioned DOS 2.0 developers, and later became a Microsoft VP.

Chris Peters was also credited with determining by trial and error that a DOS user will not be able to replace a floppy in the drive in less than two seconds. Thus DOS assumes that if a disk is accessible and less than two seconds elapsed since the last operation on the same drive, the disk has not been changed and cached information may be re-used. This was an important optimization for systems with no floppy change line support.

The same RECOVER.COM utility was also shipped with DOS 2.1, with the same Easter egg.

DOS 2.1

On November 1st, 1983 IBM released the PCjr, ultimately a flop and IBM’s first notable misstep of the PC era. Because the PCjr’s hardware was significantly different from the PC and PC/XT, a new version (2.1) of DOS was needed—and in fact the PCjr could not run older DOS versions at all, while in general newer PCs could run older DOS versions, though that limited them to the feature set supported by the specific DOS version. Conversely DOS 2.1 could be used even on the first generation PCs, with the caveat of increased memory requirements.

There’s not much to be said about DOS 2.1. It was released only about seven months after version 2.0 and its primary raison d’être was PCjr support. There were no new utilities and no significant enhancements to the existing ones. Real changes had to wait until the next version, DOS 3.0.

IBM Compatibles and Other DOS Machines

At the same time, Microsoft DOS 2.x was gaining significant traction among OEMs of both IBM PC compatible computers (COMPAQ, Zenith) and 8086-based systems capable of running DOS but not PC compatible (Tandy 2000, Hewlett-Packard HP150).

The latter category did not have staying power. DOS was not a complete enough operating system, which meant that far too many applications bypassed it and accessed the hardware directly. That made life very difficult for vendors of incompatible systems, and within a few years those machines all but completely disappeared, with a notable exception of the Japanese market.

On the other hand, the PC compatible clone business was booming, or perhaps rather exploding. MS-DOS was a significant enabler of the clone market. Microsoft could go to OEMs and offer them the same DOS IBM was using—well, almost. IBM wrote several of the utilities shipped with PC DOS and those were not available to OEMs. As a consequence, OEMs had to develop their own versions of tools like FDISK.

Clones also typically did not come with BASIC built into their ROM, and at the time of DOS 2.0, BASIC was considered an integral part of a PC compatible system. However, that was something Microsoft could easily help with; OEMs could license GW-BASIC, an implementation of Microsoft BASIC which was loaded from disk and did not require any ROM BASIC.

At the time, Microsoft did not sell DOS as a retail product and only licensed DOS through OEMs. Microsoft furnished vendors of PC compatibles with the so-called OAK, or OEM Adaptation Kit. The kit contained source code for IBMBIO.COM (or IO.SYS) and object files for IBMDOS.COM (or MSDOS.SYS). Also provided was source code for several disk-related utilities like FORMAT. It was up to OEMs to modify the MS-DOS source code to work with their systems.

Microsoft was quickly becoming the de facto standard provider of 16-bit microcomputer operating systems, largely thanks to IBM’s choice of DOS for the PC.

Internationalization

IBM was initially not selling the PC outside the North American market and was therefore not very interested in internationalization. But Microsoft’s OEM customers, some of them based in Europe and Japan, certainly were.

MS-DOS version 2.01 included internationalization support with the new COUNTRY statement in CONFIG.SYS. IBM did not want the new feature in PC DOS 2.10,  but Microsoft eventually merged MS-DOS 2.01 and PC DOS 2.1 into MS-DOS 2.11. The 2.11 version was shipped by numerous OEMs and was the mainstay of early PC compatibles.

Microsoft later released MS-DOS 2.25 specifically for the Far East market, with improved support for double-byte characters. MS-DOS 2.25 also shipped with utilities compatible with DOS 3.0.

References

Undocumented DOS, 2nd Ed., Andrew Schulman et al, Addison-Wesley, 1993. ISBN 0-201-63287-X
The MS-DOS Encyclopedia, edited by Ray Duncan, Microsoft Press, 1987. ISBN 1-55615-049-0
Advanced MS-DOS Programming, Ray Duncan, Microsoft Press, 1986. ISBN 1-55615-157-8