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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
BTW, I think even DOS 1.x had INT 27h for TSRs, but it was rarely used before DOS 2.x.
Yes and no. If Ralf Brown’s Interrupt List is to be believed (and it usually is), INT 27h was implemented in COMMAND.COM in DOS 1.x rather than in the DOS kernel itself.
I can’t find any occurrence of INT 27h in either PC DOS 1.0 or 1.1. It only shows up in PC DOS 2.0, in PRINT.COM and GRAPHICS.COM.
“with a notable exception of the Japanese market.”
Yea, I wonder why EGA was designed to have 350 lines instead of 400 lines. Of course, it certainly don’t help that MS screwed up the protected mode transition badly, as it would have provided hardware abstraction and more memory for the Japanese fonts.
CRTs with higher horizontal frequency were more expensive, and video memory was not cheap either.
It’s interesting that PC-DOS 2.0 didn’t support the PCjr, because I found this code in the PC-DOS 2.0 COMMAND.COM, which appears to be a ROM scan that would only occur on a PCjr. Perhaps the engineers working on PC-DOS 2.0 had originally tried to include PCjr support? I’d investigate further, except that PCjr emulation isn’t currently on my to-do list (and I’ve never owned a PCjr).
0905:352C 06 PUSH ES
0905:352D 56 PUSH SI
0905:352E 57 PUSH DI
0905:352F 51 PUSH CX
0905:3530 50 PUSH AX
0905:3531 53 PUSH BX
0905:3532 B800F0 MOV AX,F000
0905:3535 8EC0 MOV ES,AX
0905:3537 26 ES:
0905:3538 803EFEFFFD CMP BYTE PTR [FFFE],FD
0905:353D 7408 JZ 3547
0905:353F F8 CLC
0905:3540 5B POP BX
0905:3541 58 POP AX
0905:3542 59 POP CX
0905:3543 5F POP DI
0905:3544 5E POP SI
0905:3545 07 POP ES
0905:3546 C3 RET
0905:3547 B800C0 MOV AX,C000
0905:354A 8EC0 MOV ES,AX
0905:354C 33FF XOR DI,DI
0905:354E 26 ES:
0905:354F 813D55AA CMP WORD PTR [DI],AA55
0905:3553 740A JZ 355F
0905:3555 058000 ADD AX,0080
0905:3558 3D00F0 CMP AX,F000
0905:355B 72ED JB 354A
0905:355D EBE0 JMP 353F
0905:355F 26 ES:
0905:3560 8A5D02 MOV BL,[DI+02]
0905:3563 32FF XOR BH,BH
0905:3565 D1E3 SHL BX,1
0905:3567 D1E3 SHL BX,1
0905:3569 83C37F ADD BX,+7F
0905:356C 81E380FF AND BX,FF80
0905:3570 BF0600 MOV DI,0006
0905:3573 26 ES:
0905:3574 8A0D MOV CL,[DI]
0905:3576 47 INC DI
0905:3577 32ED XOR CH,CH
0905:3579 0BC9 OR CX,CX
0905:357B 7504 JNZ 3581
0905:357D 03C3 ADD AX,BX
0905:357F EBD7 JMP 3558
0905:3581 8BF2 MOV SI,DX
0905:3583 46 INC SI
0905:3584 F3 REPZ
0905:3585 A6 CMPSB
0905:3586 7407 JZ 358F
0905:3588 03F9 ADD DI,CX
0905:358A 83C703 ADD DI,+03
0905:358D EBE4 JMP 3573
0905:358F 803C3F CMP BYTE PTR [SI],3F
0905:3592 7405 JZ 3599
0905:3594 803C20 CMP BYTE PTR [SI],20
0905:3597 75EF JNZ 3588
0905:3599 2E CS:
0905:359A 8C06B12D MOV [2DB1],ES
0905:359E 2E CS:
0905:359F 893EAF2D MOV [2DAF],DI
0905:35A3 F9 STC
0905:35A4 EB9A JMP 3540
The reason why PC DOS 2.0 didn’t support the PCjr was (IMO) very simple: PC DOS 2.0 was released in March 1983; PC DOS 2.1 was released in November 1983, at the same time Peanut (aka PCjr) was announced. It’s probably a given that PCjr prototypes existed when DOS 2.0 was under development. At the same time it can’t have been finalized in early 1983, so even if IBM didn’t mind announcing support for unannounced hardware (which they most certainly did), it would have been technically very imprudent.
Very interesting find though!
Yuhong Bao: EGA was 350 lines because MDA was also 350 lines, I believe. And, EGA was intended to be backwards compatible with both CGA and MDA – on a CGA monitor, you’d get the CGA modes with 8×8 fonts plus 16-color versions of the CGA modes available, on a MDA monitor you’d get the same 9×14 font as you did on MDA plus a 640×350 (not 720×350) monochrome mode, and on an EGA monitor you’d get the CGA modes (but with an 8×14 font for text instead of 8×8, based on the MDA 9×14 font) and 640×350 color modes.
How many directories in MS.DOS 2.0?
How deep? How many in a root directory? How many in a non-root directory? I’m sorry but I don’t really understand the question.
In DOS 2.0, if you typed Format and didn’t specify the drive, it would default to the boot drive – with no warning – meaning it would reformat your hard drive on a PC/XT. 2.1 fixed that.
How many directories in MS.DOS 2.0? both in root directory and non-root directory. Obviously DOS 2.0 has limit to how much directories you can create..that’s question.
The number of root directory entries is defined by FORMAT; given that FORMAT was customized by OEMs, the limitations are not hardcoded into DOS per se.
On a standard 180K DOS 2.0 disk there are 64 root directory entries. That makes 4 sectors for the root directory, another 4 for the two FATs, and one boot sector, which means all the control structures fit on the first 9-sector track.
DOS 2.0 has no trouble working with 360K disks formatted by DOS 3.x with 112 root directory entries. Hard disks are yet another story, for example a DOS 2.0 30 MB hard disk gets formatted with 1024 root directory entries.
DOS does not limit the number of entries in a single directory, except by the amount of available disk space. The nesting depth is limited but only indirectly; there is a limit (around 64 characters) on the total path length.
Did Nancy Panners grow up in Pawtucket, RI?
I have no information on that, sorry…
OK, Ill take a stab at that:
How many directories in DOS 2.0?
On a floppy the number of directories in the root was limited by the size of the FAT Table, which was 2 sectors, limiting you to 63 directories, if you had no files, and 60 if it was the boot disk. If you made a directory, and then put directories in it, you were limited to the size of the disk, i.e. 318 directories. If you created a batch file, that created a directory and changed to it, you were limited by path size, which would get you down to 252 levels, before it would start to get REALLY crazy.
It could not display the directory you were in, but you still could create and change another 4 directories, before you would get a undecipherable error.
On a hard disk, with 6 sectors in the root filesystem, you could create 189 directories.
Keep in mind that
In a DOS 2.0 disk, you need 1 entry for the Label, and 3 entries for the system files, 2 for the hidden files, and 1 for command.com, if it was a boot disk.
The path, was limited by the size of a DOS string to 255 characters, but with an carriage return at the end, so its 254, hence a path cannot be longer than 254 chars, and if you access a file with a single character filename, it cannot be more than 253, chars. When printing to the screen, command.com would print garbage or nothing, past 249 characters.
A sub-directory always took 1 sector, or on a hard disk 1 cluster, so your only limit wold be disk space. One of the first misuses of the IBM network was to fill the network drive with directories. Once that was accomplished, it was just a matter of deleting them all, and noting what the limitations of DOS were.
Minor inaccuracies: On a DOS 2.0 and later drive, the number of root directory entries is stored in the BPB. There is no hardcoded limit per se, but DOS does not make it easy to change the number when formatting.
A subdirectory always takes up at least one cluster, but on several common floppy formats one cluster equals one sector.