In developing the first version, the programmers had had two primary
goals: running translated CP/M-80 software and keeping MS-DOS small.
They had neither the time nor the room to include more sophisticated
features, such as those typical of Microsoft's UNIX-based multiuser,
multitasking operating system, XENIX. But when IBM informed Microsoft
that the next major edition of the PC would be the Personal Computer
XT with a 10- megabyte fixed disk, a larger, more powerful version of
MS-DOS--one closer to the operating system Microsoft had envisioned
from the start--became feasible.
There were three particular areas that interested Microsoft: a new,
hierarchical file system, installable device drivers, and some type of
multitasking. Each of these features contributed to version 2.0, and
together they represented a major change in MS-DOS while still
maintaining compatibility with version 1.0.
[...]
Ultimately, it was a hierarchical file system that found its way into
MS-DOS 2.0 and eventually convinced everyone that it was, indeed, the
better and more flexible solution to the problem of supporting a fixed
disk. The file system was logically consistent with the XENIX file
structure, yet physically consistent with the file access incorporated
in versions 1.x, and was based on a root, or main, directory under
which the user could create a system of subdirectories and sub-
subdirectories to hold files. Each file in the system was identified
by the directory path leading to it, and the number of subdirectories
was limited only by the length of the pathname, which could not exceed
64 characters.
In this file structure, all the subdirectories and the filename in a
path were separated from one another by backslash characters, which
represented the only anomaly in the XENIX/MS-DOS system of
hierarchical files. XENIX used a forward slash as a separator, but
versions 1.x of MS-DOS, borrowing from the tradition of DEC operating
systems, already used the forward slash for switches in the command
line, so Microsoft, at IBM's request, decided to use the backslash as
the separator instead. Although the backslash character created no
practical problems, except on keyboards that lacked a backslash, this
decision did introduce inconsistency between MS-DOS and existing UNIX-
like operating systems. And although Microsoft solved the keyboard
problem by enabling the user to change the switch character from a
slash to a hyphen, the solution itself created compatibility problems
for people who wished to exchange batch files.
Another major change in the file-management system was related to the
new directory structure: In order to fully exploit a hierarchical file
system, Microsoft had to add a new way of calling file services.
Versions 1.x of MS-DOS used CP/M-like structures called file control
blocks, or FCBs, to maintain compatibility with older CP/M-80
programs. The FCBs contained all pertinent information about the size
and location of a file but did not allow the user to specify a file in
a different directory. Therefore, version 2.0 of MS-DOS needed the
added ability to access files by means of handles, or descriptors,
that could operate across directory lines.
In this added step toward logical device independence, MS-DOS returned
a handle whenever an MS-DOS program opened a file. All further
interaction with the file involved only this handle. MS-DOS made all
necessary adjustments to an internal structure--different from an FCB-
-so that the program never had to deal directly with information about the file's location in memory. Furthermore, even if future versions of
MS-DOS were to change the structure of the internal control units,
program code would not need to be rewritten--the file handle would be
the only referent needed, and this would not change.
Putting the internal control units under the supervision of MS-DOS and
substituting handles for FCBs also made it possible for MS-DOS to
redirect a program's input and output. A system function was provided
that enabled MS-DOS to divert the reads or writes directed to one
handle to the file or device assigned to another handle. This
capability was used by COMMAND.COM to allow output from a file to be
redirected to a device, such as a printer, or to be piped to another
program. It also allowed system cleanup on program terminations.
[...]
At IBM's request, version 2.0 of MS-DOS also possessed the
undocumented ability to perform rudimentary background processing--an
interim solution to a growing awareness of the potentials of
multitasking.
Background print spooling was sufficient to meet the needs of most
people in most situations, so the print spooler, PRINT.COM, was
designed to run whenever MS-DOS had nothing else to do. When the
parent application became active, PRINT.COM would be interrupted until
the next lull. This type of background processing, though both limited
and extremely complex, was exploited by a number of applications, such
as SideKick.
