PCjs Machines
Home of the original IBM PC emulator for browsers.
The MS-DOS Encyclopedia
Section I: The Development of MS-DOS
To many people who use personal computers, MS-DOS is the key that
unlocks the power of the machine. It is their most visible connection
to the hardware hidden inside the cabinet, and it is through MS-DOS
that they can run applications and manage disks and disk files.
In the sense that it opens the door to doing work with a personal
computer, MS-DOS is indeed a key, and the lock it fits is the Intel
8086 family of microprocessors. MS-DOS and the chips it works with
are, in fact, closely connected--so closely that the story of MS-DOS
is really part of a larger history that encompasses not only an
operating system but also a microprocessor and, in retrospect, part of
the explosive growth of personal computing itself.
Chronologically, the history of MS-DOS can be divided into three
parts. First came the formation of Microsoft and the events preceding
Microsoft's decision to develop an operating system. Then came the
creation of the first version of MS-DOS. Finally, there is the
continuing evolution of MS-DOS since its release in 1981.
Much of the story is based on technical developments, but dates and
facts alone do not provide an adequate look at the past. Many people
have been involved in creating MS-DOS and directing the lines along
which it continues to grow. To the extent that personal opinions and
memories are appropriate, they are included here to provide a fuller
picture of the origin and development of MS-DOS.
Before MS-DOS
The role of International Business Machines Corporation in Microsoft's
decision to create MS-DOS has been well publicized. But events, like
inventions, always build on prior accomplishments, and in this respect
the roots of MS-DOS reach farther back, to four hardware and software
developments of the 1970s: Microsoft's disk-based and stand-alone
versions of BASIC, Digital Research's CP/M-80 operating system, the
emergence of the 8086 chip, and a disk operating system for the 8086
developed by Tim Paterson at a hardware company called Seattle
Computer Products.
Microsoft and BASIC
On the surface, BASIC and MS-DOS might seem to have little in common,
but in terms of file management, MS-DOS is a direct descendant of a
Microsoft version of BASIC called Stand-alone Disk BASIC.
Before Microsoft even became a company, its founders, Paul Allen and
Bill Gates, developed a version of BASIC for a revolutionary small
computer named the Altair, which was introduced in January 1975 by
Micro Instrumentation Telemetry Systems (MITS) of Albuquerque, New
Mexico. Though it has long been eclipsed by other, more powerful makes
and models, the Altair was the first "personal" computer to appear in
an environment dominated by minicomputers and mainframes. It was,
simply, a metal box with a panel of switches and lights for input and
output, a power supply, a motherboard with 18 slots, and two boards.
One board was the central processing unit, with the 8-bit Intel 8080
microprocessor at its heart; the other board provided 256 bytes of
random-access memory. This miniature computer had no keyboard, no
monitor, and no device for permanent storage, but it did possess one
great advantage: a price tag of $397.
Now, given the hindsight of a little more than a decade of
microcomputing history, it is easy to see that the Altair's
combination of small size and affordability was the thin edge of a
wedge that, in just a few years, would move everyday computing power
away from impersonal monoliths in climate-controlled rooms and onto
the desks of millions of people. In 1975, however, the computing
environment was still primarily a matter of data processing for
specialists rather than personal computing for everyone. Thus when 4
KB memory expansion boards became available for the Altair, the
software needed most by its users was not a word processor or a
spreadsheet, but a programming language--and the language first
developed for it was a version of BASIC written by Bill Gates and Paul
Allen.
Gates and Allen had become friends in their teens, while attending
Lakeside School in Seattle. They shared an intense interest in
computers, and by the time Gates was in the tenth grade, they and
another friend named Paul Gilbert had formed a company called Traf-O-
Data to produce a machine that automated the reading of 16-channel, 4-
digit, binary-coded decimal (BCD) tapes generated by traffic-
monitoring recorders. This machine, built by Gilbert, was based on the
Intel 8008 microprocessor, the predecessor of the 8080 in the Altair.
Although it was too limited to serve as the central processor for a
general-purpose computer, the 8008 was undeniably the ancestor of the
8080 as far as its architecture and instruction set were concerned.
Thus Traf-O-Data's work with the 8008 gave Gates and Allen a head
start when they later developed their version of BASIC for the Altair.
Paul Allen learned of the Altair from the cover story in the January
1975 issue of Popular Electronics magazine. Allen, then an employee
of Honeywell in Boston, convinced Gates, a student at Harvard
University, to develop a BASIC for the new computer. The two wrote
their version of BASIC for the 8080 in six weeks, and Allen flew to
New Mexico to demonstrate the language for MITS. The developers gave
themselves the company name of Microsoft and licensed their BASIC to
MITS as Microsoft's first product.
Though not a direct forerunner of MS-DOS, Altair BASIC, like the
machine for which it was developed, was a landmark product in the
history of personal computing. On another level, Altair BASIC was also
the first link in a chain that led, somewhat circuitously, to Tim
Paterson and the disk operating system he developed for Seattle
Computer Products for the 8086 chip.
From paper tape to disk
Gates and Allen's early BASIC for the Altair was loaded from paper
tape after the bootstrap to load the tape was entered into memory by
flipping switches on the front panel of the computer. In late 1975,
however, MITS decided to release a floppy-disk system for the Altair--
the first retail floppy-disk system on the market. As a result, in
February 1976 Allen, by then Director of Software for MITS, asked
Gates to write a disk-based version of Altair BASIC. The Altair had no
operating system and hence no method of managing files, so the disk
BASIC would have to include some file-management routines. It would,
in effect, have to function as a rudimentary operating system.
Gates, still at Harvard University, agreed to write this version of
BASIC for MITS. He went to Albuquerque and, as has often been
recounted, checked into the Hilton Hotel with a stack of yellow legal
pads. Five days later he emerged, yellow pads filled with the code for
the new version of BASIC. Arriving at MITS with the code and a request
to be left alone, Gates began typing and debugging and, after another
five days, had Disk BASIC running on the Altair.
This disk-based BASIC marked Microsoft's entry into the business of
languages for personal computers--not only for the MITS Altair, but
also for such companies as Data Terminals Corporation and General
Electric. Along the way, Microsoft BASIC took on added features, such
as enhanced mathematics capabilities, and, more to the point in terms
of MS-DOS, evolved into Stand-alone Disk BASIC, produced for NCR in
1977.
Designed and coded by Marc McDonald, Stand-alone Disk BASIC included a
file-management scheme called the FAT, or file allocation table that
used a linked list for managing disk files. The FAT, born during one
of a series of discussions between McDonald and Bill Gates, enabled
disk-allocation information to be kept in one location, with "chained"
references pointing to the actual storage locations on disk. Fast and
flexible, this file-management strategy was later used in a stand-
alone version of BASIC for the 8086 chip and eventually, through an
operating system named M-DOS, became the basis for the file-handling
routines in MS-DOS.
M-DOS
During 1977 and 1978, Microsoft adapted both BASIC and Microsoft
FORTRAN for an increasingly popular 8-bit operating system called
CP/M. At the end of 1978, Gates and Allen moved Microsoft from
Albuquerque to Bellevue, Washington. The company continued to
concentrate on programming languages, producing versions of BASIC for
the 6502 and the TI9900.
During this same period, Marc McDonald also worked on developing an 8-
bit operating system called M-DOS (usually pronounced "Midas" or "My
DOS"). Although it never became a real part of the Microsoft product
line, M-DOS was a true multitasking operating system modeled after the
DEC TOPS-10 operating system. M-DOS provided good performance and,
with a more flexible FAT than that built into BASIC, had a better
file-handling structure than the up-and-coming CP/M operating system.
At about 30 KB, however, M-DOS was unfortunately too big for an 8-bit
environment and so ended up being relegated to the back room. As Allen
describes it, "Trying to do a large, full-blown operating system on
the 8080 was a lot of work, and it took a lot of memory. The 8080
addresses only 64 K, so with the success of CP/M, we finally concluded
that it was best not to press on with that."
CP/M
In the volatile microcomputer era of 1976 through 1978, both users and
developers of personal computers quickly came to recognize the
limitations of running applications on top of Microsoft's Stand-alone
Disk BASIC or any other language. MITS, for example, scheduled a July
1976 release date for an independent operating system for its machine
that used the code from the Altair's Disk BASIC. In the same year,
Digital Research, headed by Gary Kildall, released its Control
Program/Monitor, or CP/M.
CP/M was a typical microcomputer software product of the 1970s in that
it was written by one person, not a group, in response to a specific
need that had not yet been filled. One of the most interesting aspects
of CP/M's history is that the software was developed several years
before its release date--actually, several years before the hardware
on which it would be a standard became commercially available.
In 1973, Kildall, a professor of computer science at the Naval
Postgraduate School in Monterey, California, was working with an 8080-
based small computer given him by Intel Corporation in return for some
programming he had done for the company. Kildall's machine, equipped
with a monitor and paper-tape reader, was certainly advanced for the
time, but Kildall became convinced that magnetic-disk storage would
make the machine even more efficient than it was.
Trading some programming for a disk drive from Shugart, Kildall first
attempted to build a drive controller on his own. Lacking the
necessary engineering ability, he contacted a friend, John Torode, who
agreed to handle the hardware aspects of interfacing the computer and
the disk drive while Kildall worked on the software portion--the
refinement of an operating system he had written earlier that year.
The result was CP/M.
The version of CP/M developed by Kildall in 1973 underwent several
refinements. Kildall enhanced the CP/M debugger and assembler, added a
BASIC interpreter, and did some work on an editor, eventually
developing the product that, from about 1977 until the appearance of
the IBM Personal Computer, set the standard for 8-bit microcomputer
operating systems.
Digital Research's CP/M included a command interpreter called CCP
(Console Command Processor), which acted as the interface between the
user and the operating system itself, and an operations handler called
BDOS (Basic Disk Operating System), which was responsible for file
storage, directory maintenance, and other such housekeeping chores.
For actual input and output--disk I/O, screen display, print requests,
and so on--CP/M included a BIOS (Basic Input/Output System) tailored
to the requirements of the hardware on which the operating system ran.
For file storage, CP/M used a system of eight-sector allocation units.
For any given file, the allocation units were listed in a directory
entry that included the filename and a table giving the disk locations
of 16 allocation units. If a long file required more than 16
allocation units, CP/M created additional directory entries as
required. Small files could be accessed rapidly under this system, but
large files with more than a single directory entry could require
numerous relatively time-consuming disk reads to find needed
information.
At the time, however, CP/M was highly regarded and gained the support
of a broad base of hardware and software developers alike. Quite
powerful for its size (about 4KB), it was, in all respects, the
undisputed standard in the 8-bit world, and remained so until, and
even after, the appearance of the 8086.
The 8086
When Intel released the 8-bit 8080 chip in 1974, the Altair was still
a year in the future. The 8080 was designed not to make computing a
part of everyday life but to make household appliances and industrial
machines more intelligent. By 1978, when Intel introduced the 16-bit
8086, the microcomputer was a reality and the new chip represented a
major step ahead in performance and memory capacity. The 8086's full
16-bit buses made it faster than the 8080, and its ability to address
one megabyte of random-access memory was a giant step beyond the
8080's 64 KB limit. Although the 8086 was not compatible with the
8080, it was architecturally similar to its predecessor and 8080
source code could be mechanically translated to run on it. This
translation capability, in fact, was a major influence on the design
of Tim Paterson's operating system for the 8086 and, through
Paterson's work, on the first released version of MS-DOS.
When the 8086 arrived on the scene, Microsoft, like other developers,
was confronted with two choices: continue working in the familiar 8-
bit world or turn to the broader horizons offered by the new 16-bit
technology. For a time, Microsoft did both. Acting on Paul Allen's
suggestion, the company developed the SoftCard for the popular Apple
II, which was based on the 8-bit 6502 microprocessor. The SoftCard
included a Z80 microprocessor and a copy of CP/M-80 licensed from
Digital Research. With the SoftCard, Apple II users could run any
program or language designed to run on a CP/M machine.
It was 16-bit technology, however, that held the most interest for
Gates and Allen, who believed that this would soon become the standard
for microcomputers. Their optimism was not universal--more than one
voice in the trade press warned that industry investment in 8-bit
equipment and software was too great to successfully introduce a new
standard. Microsoft, however, disregarded these forecasts and entered
the 16-bit arena as it had with the Altair: by developing a stand-
alone version of BASIC for the 8086.
At the same time and, coincidentally, a few miles south in Tukwila,
Washington, a major contribution to MS-DOS was taking place. Tim
Paterson, working at Seattle Computer Products, a company that built
memory boards, was developing an 8086 CPU card for use in an S-100 bus
machine.
86-DOS
Paterson was introduced to the 8086 chip at a seminar held by Intel in
June 1978. He had attended the seminar at the suggestion of his
employer, Rod Brock of Seattle Computer Products. The new chip sparked
his interest because, as he recalls, "all its instructions worked on
both 8 and 16 bits, and you didn't have to do everything through the
accumulator. It was also real fast--it could do a 16-bit ADD in three
clocks."
After the seminar, Paterson--again with Brock's support--began work
with the 8086. He finished the design of his first 8086 CPU board in
January 1979 and by late spring had developed a working CPU, as well
as an assembler and an 8086 monitor. In June, Paterson took his system
to Microsoft to try it with Stand-alone BASIC, and soon after,
Microsoft BASIC was running on Seattle Computer's new board.
During this period, Paterson also received a call from Digital
Research asking whether they could borrow the new board for developing
CP/M-86. Though Seattle Computer did not have a board to loan,
Paterson asked when CP/M-86 would be ready. Digital's representative
said December 1979, which meant, according to Paterson's diary, "we'll
have to live with Stand-alone BASIC for a few months after we start
shipping the CPU, but then we'll be able to switch to a real operating
system."
Early in June, Microsoft and Tim Paterson attended the National
Computer Conference in New York. Microsoft had been invited to share
Lifeboat Associates' ten-by-ten foot booth, and Paterson had been
invited by Paul Allen to show BASIC running on an S-100 8086 system.
At that meeting, Paterson was introduced to Microsoft's M-DOS, which
he found interesting because it used a system for keeping track of
disk files--the FAT developed for Stand-alone BASIC--that was
different from anything he had encountered.
After this meeting, Paterson continued working on the 8086 board, and
by the end of the year, Seattle Computer Products began shipping the
CPU with a BASIC option.
When CP/M-86 had still not become available by April 1980, Seattle
Computer Products decided to develop a 16-bit operating system of its
own. Originally, three operating systems were planned: a single-user
system, a multiuser version, and a small interim product soon
informally christened QDOS (for Quick and Dirty Operating System) by
Paterson.
Both Paterson (working on QDOS) and Rod Brock knew that a standard
operating system for the 8086 was mandatory if users were to be
assured of a wide range of application software and languages. CP/M
had become the standard for 8-bit machines, so the ability to
mechanically translate existing CP/M applications to run on a 16-bit
system became one of Paterson's major goals for the new operating
system. To achieve this compatibility, the system he developed
mimicked CP/M-80's functions and command structure, including its use
of file control blocks (FCBs) and its approach to executable files.
At the same time, however, Paterson was dissatisfied with certain
elements of CP/M, one of them being its file-allocation system, which
he considered inefficient in the use of disk space and too slow in
operation. So for fast, efficient file handling, he used a file
allocation table, as Microsoft had done with Stand-alone Disk BASIC
and M-DOS. He also wrote a translator to translate 8080 code to 8086
code, and he then wrote an assembler in Z80 assembly language and used
the translator to translate it.
Four months after beginning work, Paterson had a functioning 6 KB
operating system, officially renamed 86-DOS, and in September 1980 he
contacted Microsoft again, this time to ask the company to write a
version of BASIC to run on his system.
IBM
While Paterson was developing 86-DOS, the third major element leading
to the creation of MS-DOS was gaining force at the opposite end of the
country. IBM, until then seemingly oblivious to most of the
developments in the microcomputer world, had turned its attention to
the possibility of developing a low-end workstation for a market it
knew well: business and business people.
On August 21, 1980, a study group of IBM representatives from Boca
Raton, Florida, visited Microsoft. This group, headed by a man named
Jack Sams, told Microsoft of IBM's interest in developing a computer
based on a microprocessor. IBM was, however, unsure of microcomputing
technology and the microcomputing market. Traditionally, IBM relied on
long development cycles--typically four or five years--and was aware
that such lengthy design periods did not fit the rapidly evolving
microcomputer environment.
One of IBM's solutions--the one outlined by Sams's group--was to base
the new machine on products from other manufacturers. All the
necessary hardware was available, but the same could not be said of
the software. Hence the visit to Microsoft with the question: Given
the specifications for an 8-bit computer, could Microsoft write a ROM
BASIC for it by the following April?
Microsoft responded positively, but added questions of its own: Why
introduce an 8-bit computer? Why not release a 16-bit machine based on
Intel's 8086 chip instead? At the end of this meeting--the first of
many--Sams and his group returned to Boca Raton with a proposal for
the development of a low-end, 16-bit business workstation. The venture
was named Project Chess.
One month later, Sams returned to Microsoft asking whether Gates and
Allen could, still by April 1981, provide not only BASIC but also
FORTRAN, Pascal, and COBOL for the new computer. This time the answer
was no because, though Microsoft's BASIC had been designed to run as a
stand-alone product, it was unique in that respect--the other
languages would need an operating system. Gates suggested CP/M-86,
which was then still under development at Digital Research, and in
fact made the initial contact for IBM. Digital Research and IBM did
not come to any agreement, however.
Microsoft, meanwhile, still wanted to write all the languages for
IBM--approximately 400 KB of code. But to do this within the allotted
six-month schedule, the company needed some assurances about the
operating system IBM was going to use. Further, it needed specific
information on the internals of the operating system, because the ROM
BASIC would interact intimately with the BIOS.
The turning point
That state of indecision, then, was Microsoft's situation on Sunday,
September 28, 1980, when Bill Gates, Paul Allen, and Kay Nishi, a
Microsoft vice president and president of ASCII Corporation in Japan,
sat in Gates's eighth-floor corner office in the Old National Bank
Building in Bellevue, Washington. Gates recalls, "Kay and I were just
sitting there at night and Paul was on the couch. Kay said, `Got to do
it, got to do it.' It was only 20 more K of code at most--actually, it
turned out to be 12 more K on top of the 400. It wasn't that big a
deal, and once Kay said it, it was obvious. We'd always wanted to do a
low-end operating system, we had specs for low-end operating systems,
and we knew we were going to do one up on 16-bit."
At that point, Gates and Allen began looking again at Microsoft's
proposal to IBM. Their estimated 400 KB of code included four
languages, an assembler, and a linker. To add an operating system
would require only another 20 KB or so, and they already knew of a
working model for the 8086: Tim Paterson's 86-DOS. The more Gates,
Allen, and Nishi talked that night about developing an operating
system for IBM's new computer, the more possible--even preferable--the
idea became.
Allen's first step was to contact Rod Brock at Seattle Computer
Products to tell him that Microsoft wanted to develop and market SCP's
operating system and that the company had an OEM customer for it.
Seattle Computer Products, which was not in the business of marketing
software, agreed and licensed 86-DOS to Microsoft. Eventually, SCP
sold the operating system to Microsoft for $50,000, favorable language
licenses, and a license back from Microsoft to use 86-DOS on its own
machines.
In October 1980, with 86-DOS in hand, Microsoft submitted another
proposal to IBM. This time the plan included both an operating system
and the languages for the new computer. Time was short and the
boundaries between the languages and the operating system were
unclear, so Microsoft explained that it needed to control the
development of the operating system in order to guarantee delivery by
spring of 1981. In November, IBM signed the contract.
Creating MS-DOS
At Thanksgiving, a prototype of the IBM machine arrived at Microsoft
and Bill Gates, Paul Allen, and, primarily, Bob O'Rear began a
schedule of long, sometimes hectic days and total immersion in the
project. As O'Rear recalls, "If I was awake, I was thinking about the
project."
The first task handled by the team was bringing up 86-DOS on the new
machine. This was a challenge because the work had to be done in a
constantly changing hardware environment while changes were also being
made to the specifications of the budding operating system itself.
As part of the process, 86-DOS had to be compiled and integrated with
the BIOS, which Microsoft was helping IBM to write, and this task was
complicated by the media. Paterson's 86-DOS--not counting utilities
such as EDLIN, CHKDSK, and INIT (later named FORMAT)--arrived at
Microsoft as one large assembly-language program on an 8-inch floppy
disk. The IBM machine, however, used 5-1/4-inch disks, so Microsoft
needed to determine the format of the new disk and then find a way to
get the operating system from the old format to the new.
This work, handled by O'Rear, fell into a series of steps. First, he
moved a section of code from the 8-inch disk and compiled it. Then, he
converted the code to Intel hexadecimal format. Next, he uploaded it
to a DEC-2020 and from there downloaded it to a large Intel fixed-disk
development system with an In-Circuit Emulator. The DEC-2020 used for
this task was also used in developing the BIOS, so there was
additional work in downloading the BIOS to the Intel machine,
converting it to hexadecimal format, moving it to an IBM development
system, and then crossloading it to the IBM prototype.
Defining and implementing the MS-DOS disk format--different from
Paterson's 8-inch format--was an added challenge. Paterson's ultimate
goal for 86-DOS was logical device independence, but during this first
stage of development, the operating system simply had to be converted
to handle logical records that were independent of the physical record
size.
Paterson, still with Seattle Computer Products, continued to work on
86-DOS and by the end of 1980 had improved its logical device
independence by adding functions that streamlined reading and writing
multiple sectors and records, as well as records of variable size. In
addition to making such refinements of his own, Paterson also worked
on dozens of changes requested by Microsoft, from modifications to the
operating system's startup messages to changes in EDLIN, the line
editor he had written for his own use. Throughout this process, IBM's
security restrictions meant that Paterson was never told the name of
the OEM and never shown the prototype machines until he left Seattle
Computer Products and joined Microsoft in May 1981.
And of course, throughout the process the developers encountered the
myriad loose ends, momentary puzzles, bugs, and unforeseen details
without which no project is complete. There were, for example, the
serial card interrupts that occurred when they should not and,
frustratingly, a hardware constraint that the BIOS could not
accommodate at first and that resulted in sporadic crashes during
early MS-DOS operations.
In spite of such difficulties, however, the new operating system ran
on the prototype for the first time in February 1981. In the six
months that followed, the system was continually refined and expanded,
and by the time of its debut in August 1981, MS-DOS, like the IBM
Personal Computer on which it appeared, had become a functional
product for home and office use.
Version 1
The first release of MS-DOS, version 1.0, was not the operating system
Microsoft envisioned as a final model for 16-bit computer systems.
According to Bill Gates, "Basically, what we wanted to do was one that
was more like MS-DOS 2, with the hierarchical file system and
everything...the key thing [in developing version 1.0] was my saying,
`Look, we can come out with a subset first and just go upward from
that.'"
This first version--Gates's subset of MS-DOS--was actually a good
compromise between the present and the future in two important
respects: It enabled Microsoft to meet the development schedule for
IBM and it maintained program-translation compatibility with CP/M.
Available only for the IBM Personal Computer, MS-DOS 1.0 consisted of
4000 lines of assembly-language source code and ran in 8 KB of memory.
In addition to utilities such as DEBUG, EDLIN, and FORMAT, it was
organized into three major files. One file, IBMBIO.COM, interfaced
with the ROM BIOS for the IBM PC and contained the disk and character
input/output system. A second file, IBMDOS.COM, contained the DOS
kernel, including the application-program interface and the disk-file
and memory managers. The third file, COMMAND.COM, was the external
command processor--the part of MS-DOS most visible to the user.
To take advantage of the existing base of languages and such popular
applications as WordStar and dBASE II, MS-DOS was designed to allow
software developers to mechanically translate source code for the 8080
to run on the 8086. And because of this link, MS-DOS looked and acted
like CP/M-80, at that time still the standard among operating systems
for microcomputers. Like its 8-bit relative, MS-DOS used eight-
character filenames and three-character extensions, and it had the
same conventions for identifying disk drives in command prompts. For
the most part, MS-DOS also used the same command language, offered the
same file services, and had the same general structure as CP/M. The
resemblance was even more striking at the programming level, with an
almost one-to-one correspondence between CP/M and MS-DOS in the system
calls available to application programs.
New Features
MS-DOS was not, however, a CP/M twin, nor had Microsoft designed it to
be inextricably bonded to the IBM PC. Hoping to create a product that
would be successful over the long term, Microsoft had taken steps to
make MS-DOS flexible enough to accommodate changes and new directions
in the hardware technology--disks, memory boards, even
microprocessors--on which it depended. The first steps toward this
independence from specific hardware configurations appeared in MS-DOS
version 1.0 in the form of device-independent input and output,
variable record lengths, relocatable program files, and a replaceable
command processor.
MS-DOS made input and output device-independent by treating peripheral
devices as if they were files. To do this, it assigned a reserved
filename to each of the three devices it recognized: CON for the
console (keyboard and display), PRN for the printer, and AUX for the
auxiliary serial ports. Whenever one of these reserved names appeared
in the file control block of a file named in a command, all operations
were directed to the device, rather than to a disk file. (A file
control block, or FCB, is a 37-byte housekeeping record located in an
application's portion of the memory space. It includes, among other
things, the filename, the extension, and information about the size
and starting location of the file on disk.)
Such device independence benefited both application developers and
computer users. On the development side, it meant that applications
could use one set of read and write calls, rather than a number of
different calls for different devices, and it meant that an
application did not have to be modified if new devices were added to
the system. From the user's point of view, device independence meant
greater flexibility. For example, even if a program had been designed
for disk I/O only, the user could still use a file for input or direct
output to the printer.
Variable record lengths provided another step toward logical
independence. In CP/M, logical and physical record lengths were
identical: 128 bytes. Files could be accessed only in units of 128
bytes and file sizes were always maintained in multiples of 128 bytes.
With MS-DOS, however, physical sector sizes were of no concern to the
user. The operating system maintained file lengths to the exact size
in bytes and could be relied on to support logical records of any size
desired.
Another new feature in MS-DOS was the relocatable program file. Unlike
CP/M, MS-DOS had the ability to load two different types of program
files, identified by the extensions .COM and .EXE. Program files
ending with .COM mimicked the binary files in CP/M. They were more
compact than .EXE files and loaded somewhat faster, but the combined
program code, stack, and data could be no larger than 64 KB. A .EXE
program, on the other hand, could be much larger, because the file
could contain multiple segments, each of which could be up to 64 KB.
Once the segments were in memory, MS-DOS then used part of the file
header, the relocation table, to automatically set the correct
addresses for each of the different program segments.
In addition to supporting .EXE files, MS-DOS made the external command
processor, COMMAND.COM, more adaptable by making it a separate
relocatable file just like any other program. It could therefore be
replaced by a custom command processor, as long as the new file was
also named COMMAND.COM.
Performance
Everyone familiar with the IBM PC knows that MS-DOS eventually became
the dominant operating system on 8086-based microcomputers. There were
several reasons for this, not least of which was acceptance of MS-DOS
as the operating system for IBM's phenomenally successful line of
personal computers. But even though MS-DOS was the only operating
system available when the first IBM PCs were shipped, positioning
alone would not necessarily have guaranteed its ability to outstrip
CP/M-86, which appeared six months later. MS-DOS also offered
significant advantages to the user in a number of areas, including the
allocation and management of storage space on disk.
Like CP/M, MS-DOS shared out disk space in allocation units. Unlike
CP/M, however, MS-DOS mapped the use of these allocation units in a
central file allocation table--the FAT--that was always in memory.
Both operating systems used a directory entry for recording
information about each file, but whereas a CP/M directory entry
included an allocation map--a list of sixteen 1 KB allocation units
where successive parts of the file were stored--an MS-DOS directory
entry pointed only to the first allocation unit in the FAT and each
entry in the table then pointed to the next unit associated with the
file. Thus, CP/M might require several directory entries (and more
than one disk access) to load a file larger than 16 KB, but MS-DOS
retained a complete in-memory list of all file components and all
available disk space without having to access the disk at all. As a
result, MS-DOS's ability to find and load even very long files was
extremely rapid compared with CP/M's.
Two other important features--the ability to read and write multiple
records with one operating-system call and the transient use of memory
by the MS-DOS command processor--provided further efficiency for both
users and developers.
The independence of the logical record from the physical sector laid
the foundation for the ability to read and write multiple sectors.
When reading multiple records in CP/M, an application had to issue a
read function call for each sector, one at a time. With MS-DOS, the
application could issue one read function call, giving the operating
system the beginning record and the number of records to read, and MS-
DOS would then load all of the corresponding sectors automatically.
Another innovative feature of MS-DOS version 1.0 was the division of
the command processor, COMMAND.COM, into a resident portion and a
transient portion. (There is also a third part, an initialization
portion, which carries out the commands in an AUTOEXEC batch file at
startup. This part of COMMAND.COM is discarded from memory when its
work is finished.) The reason for creating resident and transient
portions of the command processor had to do with maximizing the
efficiency of MS-DOS for the user: On the one hand, the programmers
wanted COMMAND.COM to include commonly requested functions, such as
DIR and COPY, for speed and ease of use; on the other hand, adding
these commands meant increasing the size of the command processor,
with a resulting decrease in the memory available to application
programs. The solution to this trade-off of speed versus utility was
to include the extra functions in a transient portion of COMMAND.COM
that could be overwritten by any application requiring more memory. To
maintain the integrity of the functions for the user, the resident
part of COMMAND.COM was given the job of checking the transient
portion for damage when an application terminated. If necessary, this
resident portion would then load a new copy of its transient partner
into memory.
Ease of Use
In addition to its moves toward hardware independence and efficiency,
MS-DOS included several services and utilities designed to make life
easier for users and application developers. Among these services were
improved error handling, automatic logging of disks, date and time
stamping of files, and batch processing.
MS-DOS and the IBM PC were targeted at a nontechnical group of users,
and from the beginning IBM had stressed the importance of data
integrity. Because data is most likely to be lost when a user responds
incorrectly to an error message, an effort was made to include concise
yet unambiguous messages in MS-DOS. To further reduce the risks of
misinterpretation, Microsoft used these messages consistently across
all MS-DOS functions and utilities and encouraged developers to use
the same messages, where appropriate, in their applications.
In a further attempt to safeguard data, MS-DOS also trapped hard
errors--such as critical hardware errors--that had previously been
left to the hardware-dependent logic. Now the hardware logic could
simply report the nature of the error and the operating system would
handle the problem in a consistent and systematic way. MS-DOS could
also trap the Control-C break sequence so that an application could
either protect against accidental termination by the user or provide a
graceful exit when appropriate.
To reduce errors and simplify use of the system, MS-DOS also
automatically updated memory information about the disk when it was
changed. In CP/M, users had to log new disks as they changed them--a
cumbersome procedure on single-disk systems or when data was stored on
multiple disks. In MS-DOS, new disks were automatically logged as long
as no file was currently open.
Another new feature--one visible with the DIR command--was date and
time stamping of disk files. Even in its earliest forms, MS-DOS
tracked the system date and displayed it at every startup, and now,
when it turned out that only the first 16 bytes of a directory entry
were needed for file-header information, the MS-DOS programmers
decided to use some of the remaining 16 bytes to record the date and
time of creation or update (and the size of the file) as well.
Batch processing was originally added to MS-DOS to help IBM. IBM
wanted to run scripts--sequences of commands or other operations--one
after the other to test various functions of the system. To do this,
the testers needed an automated method of calling routines
sequentially. The result was the batch processor, which later also
provided users with the convenience of saving and running MS-DOS
commands as batch files.
Finally, MS-DOS increased the options available to a program when it
terminated. For example, in less sophisticated operating systems,
applications and other programs remained in memory only as long as
they were active; when terminated, they were removed from memory. MS-
DOS, however, added a terminate-and-stay-resident function that
enabled a program to be locked into memory and, in effect, become part
of the operating-system environment until the computer system itself
was shut down or restarted.
The Marketplace
When IBM announced the Personal Computer, it said that the new machine
would run three operating systems: MS-DOS, CP/M-86, and SofTech
Microsystem's p-System. Of the three, only MS-DOS was available when
the IBM PC shipped. Nevertheless, when MS-DOS was released, nine out
of ten programs on the InfoWorld bestseller list for 1981 ran under
CP/M-80, and CP/M-86, which became available about six months later,
was the operating system of choice to most writers and reviewers in
the trade press.
Understandably, MS-DOS was compared with CP/M-80 and, later, CP/M-86.
The main concern was compatibility: To what extent was Microsoft's new
operating system compatible with the existing standard? No one could
have foreseen that MS-DOS would not only catch up with but supersede
CP/M. Even Bill Gates now recalls that "our most optimistic view of
the number of machines using MS-DOS wouldn't have matched what really
ended up happening."
To begin with, the success of the IBM PC itself surprised many
industry watchers. Within a year, IBM was selling 30,000 PCs per
month, thanks in large part to a business community that was already
comfortable with IBM's name and reputation and, at least in
retrospect, was ready for the leap to personal computing. MS-DOS, of
course, benefited enormously from the success of the IBM PC--in large
part because IBM supplied all its languages and applications in MS-DOS
format.
But, at first, writers in the trade press still believed in CP/M and
questioned the viability of a new operating system in a world
dominated by CP/M-80. Many assumed, incorrectly, that a CP/M-86
machine could run CP/M-80 applications. Even before CP/M-86 was
available, Future Computing referred to the IBM PC as the "CP/M
Record Player"--presumably in anticipation of a vast inventory of CP/M
applications for the new computer--and led its readers to assume that
the PC was actually a CP/M machine.
Microsoft, meanwhile, held to the belief that the success of IBM's
machine or any other 16-bit microcomputer depended ultimately on the
emergence of an industry standard for a 16-bit operating system.
Software developers could not afford to develop software for even two
or three different operating systems, and users could (or would) not
pay the prices the developers would have to charge if they did.
Furthermore, users would almost certainly rebel against the
inconvenience of sharing data stored under different operating-system
formats. There had to be one operating system, and Microsoft wanted
MS-DOS to be the one.
The company had already taken the first step toward a standard by
choosing hardware independent designs wherever possible. Machine
independence meant portability, and portability meant that Microsoft
could sell one version of MS-DOS to different hardware manufacturers
who, in turn, could adapt it to their own equipment. Portability
alone, however, was no guarantee of industry-wide acceptance. To make
MS-DOS the standard, Microsoft needed to convince software developers
to write programs for MS-DOS. And in 1981, these developers were a
little confused about IBM's new operating system.
An operating system by any other name...
A tangle of names gave rise to one point of confusion about MS-DOS.
Tim Paterson's "Quick and Dirty Operating System" for the 8086 was
originally shipped by Seattle Computer Products as 86-DOS. After
Microsoft purchased 86-DOS, the name remained for a while, but by the
time the PC was ready for release, the new system was known as MS-DOS.
Then, after the IBM PC reached the market, IBM began to refer to the
operating system as the IBM Personal Computer DOS, which the trade
press soon shortened to PC-DOS. IBM's version contained some
utilities, such as DISKCOPY and DISKCOMP, that were not included in
MS-DOS, the generic version available for license by other
manufacturers. By calling attention to these differences, publications
added to the confusion about the distinction between the Microsoft and
IBM releases of MS-DOS.
Further complications arose when Lifeboat Associates agreed to help
promote MS-DOS but decided to call the operating system Software Bus
86. MS-DOS thus became one of a line of trademarked Software Bus
products, another of which was a product called SB-80, Lifeboat's
version of CP/M-80.
Finally, some of the first hardware companies to license MS-DOS also
wanted to use their own names for the operating system. Out of this
situation came such additional names as COMPAQ-DOS and Zenith's Z-DOS.
Given this confusing host of names for a product it believed could
become the industry standard, Microsoft finally took the lead and, as
developer, insisted that the operating system was to be called MS-DOS.
Eventually, everyone but IBM complied.
Developers and MS-DOS
Early in its career, MS-DOS represented just a small fraction of
Microsoft's business--much larger revenues were generated by BASIC and
other languages. In addition, in the first two years after the
introduction of the IBM PC, the growth of CP/M-86 and other
environments nearly paralleled that of MS-DOS. So Microsoft found
itself in the unenviable position of giving its support to MS-DOS
while also selling languages to run on CP/M-86, thereby contributing
to the growth of software for MS-DOS's biggest competitor.
Given the uncertain outcome of this two-horse race, some other
software developers chose to wait and see which way the hardware
manufacturers would jump. For their part, the hardware manufacturers
were confronting the issue of compatibility between operating systems.
Specifically, they needed to be convinced that MS-DOS was not a
maverick--that it could perform as well as CP/M-86 as a base for
applications that had been ported from the CP/M-80 environment for use
on 16-bit computers.
Microsoft approached the problem by emphasizing four related points in
its discussions with hardware manufacturers:
■ First, one of Microsoft's goals in developing the first version of
MS-DOS had always been translation compatibility from CP/M-80 to
MS-DOS software.
■ Second, translation was possible only for software written in 8080
or Z80 assembly language; thus, neither MS-DOS nor CP/M-86 could
run programs written for other 8-bit processors, such as the 6800
or the 6502.
■ Third, many applications were written in a high-level language,
rather than in assembly language.
■ Fourth, most of those high-level languages were Microsoft products
and ran on MS-DOS.
Thus, even though some people had originally believed that only CP/M-
86 would automatically make the installed base of CP/M-80 software
available to the IBM PC and other 16-bit computers, Microsoft
convinced the hardware manufacturers that MS-DOS was, in actuality, as
flexible as CP/M-86 in its compatibility with existing--and
appropriate--CP/M-80 software.
MS-DOS was put at a disadvantage in one area, however, when Digital
Research convinced several manufacturers to include both 8080 and 8086
chips in their machines. With 8-bit and 16-bit software used on the
same machine, the user could rely on the same disk format for both
types of software. Because MS-DOS used a different disk format, CP/M
had the edge in these dual-processor machines--although, in fact, it
did not seem to have much effect on the survival of CP/M-86 after the
first year or so.
Although making MS-DOS the operating system of obvious preference was
not as easy as simply convincing hardware manufacturers to offer it,
Microsoft's list of MS-DOS customers grew steadily from the time the
operating system was introduced. Many manufacturers continued to offer
CP/M-86 along with MS-DOS, but by the end of 1983 the technical
superiority of MS-DOS (bolstered by the introduction of such products
as Lotus 1-2-3) carried the market. For example, when DEC, a longtime
holdout, decided to make MS-DOS the primary operating system for its
Rainbow computer, the company mentioned the richer set of commands and
"dramatically" better disk performance of MS-DOS as reasons for its
choice over CP/M-86.
Version 2
After the release of PC-specific version 1.0 of MS-DOS, Microsoft
worked on an update that contained some bug fixes. Version 1.1 was
provided to IBM to run on the upgraded PC released in 1982 and enabled
MS-DOS to work with double-sided, 320 KB floppy disks. This version,
referred to as 1.25 by all but IBM, was the first version of MS-DOS
shipped by other OEMs, including COMPAQ and Zenith.
Even before these intermediate releases were available, however,
Microsoft began planning for future versions of MS-DOS. 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.
The File System
Primary responsibility for version 2.0 fell to Paul Allen, Mark
Zbikowski, and Aaron Reynolds, who wrote (and rewrote) most of the
version 2.0 code. The major design issue confronting the developers,
as well as the most visible example of its difference from versions
1.0, 1.1, and 1.25, was the introduction of a hierarchical file system
to handle the file-management needs of the XT's fixed disk.
Version 1.0 had a single directory for all the files on a floppy disk.
That system worked well enough on a disk of limited capacity, but on a
10-megabyte fixed disk a single directory could easily become
unmanageably large and cumbersome.
CP/M had approached the problem of high-capacity storage media by
using a partitioning scheme that divided the fixed disk into 10 user
areas equivalent to 10 separate floppy-disk drives. On the other hand,
UNIX, which had traditionally dealt with larger systems, used a
branching, hierarchical file structure in which the user could create
directories and subdirectories to organize files and make them readily
accessible. This was the file-management system implemented in XENIX,
and it was the MS-DOS team's choice for handling files on the XT's
fixed disk.
Partitioning, IBM's initial choice, had the advantages of familiarity,
size, and ease of implementation. Many small-system users--
particularly software developers--were already familiar with
partitioning, if not overly fond of it, from their experience with
CP/M. Development time was also a major concern, and the code needed
to develop a partitioning scheme would be minimal compared with the
code required to manage a hierarchical file system. Such a scheme
would also take less time to implement.
However, partitioning had two inherent disadvantages. First, its
functionality would decrease as storage capacity increased, and even
in 1982, Microsoft was anticipating substantial growth in the storage
capacity of disk-based media. Second, partitioning depended on the
physical device. If the size of the disk changed, either the number or
the size of the partitions must also be changed in the code for both
the operating system and the application programs. For Microsoft, with
its commitment to hardware independence, partitioning would have
represented a step in the wrong direction.
A hierarchical file structure, on the other hand, could be independent
of the physical device. A disk could be partitioned logically, rather
than physically. And because these partitions (directories) were
controlled by the user, they were open-ended and enabled the
individual to determine the best way of organizing a disk.
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.
Installable Device Drivers
At the time Microsoft began developing version 2.0 of MS-DOS, the
company also realized that many third-party peripheral devices were
not working well with one another. Each manufacturer had its own way
of hooking its hardware into MS-DOS and if two third-party devices
were plugged into a computer at the same time, they would often
conflict or fail.
One of the hallmarks of IBM's approach to the PC was open
architecture, meaning that users could simply slide new cards into the
computer whenever new input/output devices, such as fixed disks or
printers, were added to the system. Unfortunately, version 1.0 of MS-
DOS did not have a corresponding open architecture built into it--the
BIOS contained all the code that permitted the operating system to run
the hardware. If independent hardware manufacturers wanted to develop
equipment for use with a computer manufacturer's operating system,
they would have to either completely rewrite the device drivers or
write a complicated utility to read the existing drivers, alter them,
add the code to support the new device, and produce a working set of
drivers. If the user installed more than one device, these patches
would often conflict with one another. Furthermore, they would have to
be revised each time the computer manufacturer updated its version of
MS-DOS.
By the time work began on version 2.0, the MS-DOS team knew that the
ability to install any device driver at run time was vital. They
implemented installable device drivers by making the drivers more
modular. Like the FAT, IO.SYS (IBMBIO.COM in PC-DOS) became, in
effect, a linked list--this time, of device drivers--that could be
expanded through commands in the CONFIG.SYS file on the system boot
disk. Manufacturers could now write a device driver that the user
could install at run time by including it in the CONFIG.SYS file. MS-
DOS could then add the device driver to the linked list.
By extension, this ability to install device drivers also added the
ability to supersede a previously installed driver--for example, the
ANSI.SYS console driver that supports the ANSI standard escape codes
for cursor positioning and screen control.
Print Spooling
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.
Loose Ends and a New MS-DOS
Hierarchical files, installable device drivers, and print spooling
were the major design decisions in version 2.0. But there were dozens
of smaller changes, too.
For example, with the fixed disk it was necessary to modify the code
for automatic logging of disks. This modification meant that MS-DOS
had to access the disk more often, and file access became much slower
as a result. In trying to find a solution to this problem, Chris
Peters reasoned that, if MS-DOS had just checked the disk, there was
some minimum time a user would need to physically change disks. If
that minimum time had not elapsed, the current disk information in
RAM--whether for a fixed disk or a floppy--was probably still good.
Peters found that the fastest anyone could physically change disks,
even if the disks were damaged in the process, was about two seconds.
Reasoning from this observation, he had MS-DOS check to see how much
time had gone by since the last disk access. If less than two seconds
had elapsed, he had MS-DOS assume that a new disk had not been
inserted and that the disk information in RAM was still valid. With
this little trick, the speed of file handling in MS-DOS version 2.0
increased considerably.
Version 2.0 was released in March 1983, the product of a surprisingly
small team of six developers, including Peters, Mani Ulloa, and Nancy
Panners in addition to Allen, Zbikowski, and Reynolds. Despite its
complex new features, version 2.0 was only 24 KB of code. Though it
maintained its compatibility with versions 1.x, it was in reality a
vastly different operating system. Within six months of its release,
version 2.0 gained widespread public acceptance. In addition, popular
application programs such as Lotus 1-2-3 took advantage of the
features of this new version of MS-DOS and thus helped secure its
future as the industry standard for 8086 processors.
Versions 2.1 and 2.25
The world into which version 2.0 of MS-DOS emerged was considerably
different from the one in which version 1.0 made its debut. When IBM
released its original PC, the business market for microcomputers was
as yet undefined--if not in scope, at least in terms of who and what
would dominate the field. A year and a half later, when the PC/XT came
on the scene, the market was much better known. It had, in fact, been
heavily influenced by IBM itself. There were still many MS-DOS
machines, such as the Tandy 2000 and the Hewlett Packard HP150, that
were hardware incompatible with the IBM, but manufacturers of new
computers knew that IBM was a force to consider and many chose to
compete with the IBM PC by emulating it. Software developers, too, had
gained an understanding of business computing and were confident they
could position their software accurately in the enormous MS-DOS
market.
In such an environment, concerns about the existing base of CP/M
software faded as developers focused their attention on the fast-
growing business market and MS-DOS quickly secured its position as an
industry standard. Now, with the obstacles to MS-DOS diminished,
Microsoft found itself with a new concern: maintaining the standard it
had created. Henceforth, MS-DOS had to be many things to many people.
IBM had requirements; other OEMs had requirements. And sometimes these
requirements conflicted.
Hardware Developers
When version 2.0 was released, IBM was already planning to introduce
its PCjr. The PCjr would have the ability to run programs from ROM
cartridges and, in addition to using half-height 5-1/4-inch drives,
would employ a slightly different disk-controller architecture.
Because of these differences from the standard PC line, IBM's
immediate concern was for a version 2.1 of MS-DOS modified for the new
machine.
For the longer term, IBM was also planning a faster, more powerful PC
with a 20-megabyte fixed disk. This prospect meant Microsoft needed to
look again at its file-management system, because the larger storage
capacity of the 20-megabyte disk stretched the size limitations for
the file allocation table as it worked in version 2.0.
However, IBM's primary interest for the next major release of MS-DOS
was networking. Microsoft would have preferred to pursue multitasking
as the next stage in the development of MS-DOS, but IBM was already
developing its IBM PC Network Adapter, a plug-in card with an 80188
chip to handle communications. So as soon as version 2.0 was released,
the MS-DOS team, again headed by Zbikowski and Reynolds, began work on
a networking version (3.0) of the operating system.
Meanwhile...
The international market for MS-DOS was not significant in the first
few years after the release of the IBM PC and version 1.0 of MS-DOS.
IBM did not, at first, ship its Personal Computer to Europe, so
Microsoft was on its own there in promoting MS-DOS. In 1982, the
company gained a significant advantage over CP/M-86 in Europe by
concluding an agreement with Victor, a software company that was very
successful in Europe and had already licensed CP/M-86. Working closely
with Victor, Microsoft provided special development support for its
graphics adaptors and eventually convinced the company to offer its
products only on MS-DOS. In Japan, the most popular computers were Z80
machines, and given the country's huge installed base of 8-bit
machines, 16-bit computers were not taking hold. Mitsubishi, however,
offered a 16-bit computer. Although CP/M-86 was Mitsubishi's original
choice for an operating system, Microsoft helped get Multiplan and
FORTRAN running on the CP/M-86 system, and eventually won the
manufacturer's support for MS-DOS.
In the software arena, by the time development was underway on the 2.x
releases of MS-DOS, Microsoft's other customers were becoming more
vocal about their own needs. Several wanted a networking capability,
adding weight to IBM's request, but a more urgent need for many--a
need not shared by IBM at the time--was support for international
products. Specifically, these manufacturers needed a version of MS-DOS
that could be sold in other countries--a version of MS-DOS that could
display messages in other languages and adapt to country-specific
conventions, such as date and time formats.
Microsoft, too, wanted to internationalize MS-DOS, so the MS-DOS team,
while modifying the operating system to support the PCjr, also added
functions and a COUNTRY command that allowed users to set the date and
time formats and other country-dependent variables in the CONFIG.SYS
file.
At about the same time, another international requirement appeared.
The Japanese market for MS-DOS was growing, and the question of
supporting 7000 Kanji characters (ideograms) arose. The difficulty
with Kanji is that it requires dual-byte characters. For English and
most European character sets, one byte corresponds to one character.
Japanese characters, however, sometimes use one byte, sometimes two.
This variability creates problems in parsing, and as a result MS-DOS
had to be modified to parse a string from the beginning, rather than
back up one character at a time.
This support for individual country formats and Kanji appeared in
version 2.01 of MS-DOS. IBM did not want this version, so support for
the PCjr, developed by Zbikowski, Reynolds, Ulloa, and Eric Evans,
appeared separately in version 2.1, which went only to IBM and did not
include the modifications for international MS-DOS.
Different customers, different versions
As early as version 1.25, Microsoft faced the problem of trying to
satisfy those OEM customers that wanted to have the same version of
MS-DOS as IBM. Some, such as COMPAQ, were in the business of selling
100-percent compatibility with IBM. For them, any difference between
their version of the operating system and IBM's introduced the
possibility of incompatibility. Satisfying these requests was
difficult, however, and it was not until version 3.1 that Microsoft
was able to supply a system that other OEMs agreed was identical with
IBM's.
Before then, to satisfy the OEM customers, Microsoft combined versions
2.1 and 2.01 to create version 2.11. Although IBM did not accept this
because of the internationalization code, version 2.11 became the
standard version for all non-IBM customers running any form of MS-DOS
in the 2.x series. Version 2.11 was sold worldwide and translated into
about 10 different languages. Two other intermediate versions provided
support for Hangeul (the Korean character set) and Chinese Kanji.
Software Concerns
After the release of version 2.0, Microsoft also gained an
appreciation of the importance--and difficulty--of supporting the
people who were developing software for MS-DOS.
Software developers worried about downward compatibility. They also
worried about upward compatibility. But despite these concerns, they
sometimes used programming practices that could guarantee neither.
When this happened and the resulting programs were successful, it was
up to Microsoft to ensure compatibility.
For example, because the information about the internals of the BIOS
and the ROM interface had been published, software developers could,
and often did, work directly with the hardware in order to get more
speed. This meant sidestepping the operating system for some
operations. However, by choosing to work at the lower levels, these
developers lost the protection provided by the operating system
against hardware changes. Thus, when low-level changes were made in
the hardware, their programs either did not work or did not run
cooperatively with other applications.
Another software problem was the continuing need for compatibility
with CP/M. For example, in CP/M, programmers would call a fixed
address in low memory in order to request a function; in MS-DOS, they
would request operating-system services by executing a software
interrupt. To support older software, the first version of MS-DOS
allowed a program to request functions by either method. One of the
CP/M-based programs supported in this fashion was the very popular
WordStar. Since Microsoft could not make changes in MS-DOS that would
make it impossible to run such a widely used program, each new version
of MS-DOS had to continue supporting CP/M-style calls.
A more pervasive CP/M-related issue was the use of FCB-style calls for
file and record management. The version 1.x releases of MS-DOS had
used FCB-style calls exclusively, as had CP/M. Version 2.0 introduced
the more efficient and flexible handle calls, but Microsoft could not
simply abolish the old FCB-style calls, because so many popular
programs used them. In fact, some of Microsoft's own languages used
them. So, MS-DOS had to support both types of calls in the version 2.x
series. To encourage the use of the new handle calls, however,
Microsoft made it easy for MS-DOS users to upgrade to version 2.0. In
addition, the company convinced IBM to require version 2.0 for the
PC/XT and also encouraged software developers to require 2.0 for their
applications.
At first, both software developers and OEM customers were reluctant to
require 2.0 because they were concerned about problems with the
installed user base of 1.0 systems--requiring version 2.0 meant
supporting both sets of calls. Applications also needed to be able to
detect which version of the operating system the user was running. For
versions 1.x, the programs would have to use FCB calls; for versions
2.x, they would use the file handles to exploit the flexibility of MS-
DOS more fully.
All told, it was an awkward period of transition, but by the time
Microsoft began work on version 3.0 and the support for IBM's upcoming
20-megabyte fixed disk, it had become apparent that the change had
been in everyone's best interest.
Version 3
The types of issues that began to emerge as Microsoft worked toward
version 3.0, MS-DOS for networks, exaggerated the problems of
compatibility that had been encountered before.
First, networking, with or without a multitasking capability, requires
a level of cooperation and compatibility among programs that had never
been an issue in earlier versions of MS-DOS. As described by Mark
Zbikowski, one of the principals involved in the project, "there was a
very long period of time between 2.1 and 3.0--almost a year and a
half. During that time, we believed we understood all the problems
involved in making DOS a networking product. [But] as time progressed,
we realized that we didn't fully understand it, either from a
compatibility standpoint or from an operating-system standpoint. We
knew very well how it [DOS] ran in a single-tasking environment, but
we started going to this new environment and found places where it
came up short."
In fact, the great variability in programs and programming approaches
that MS-DOS supported eventually proved to be one of the biggest
obstacles to the development of a sophisticated networking system and,
in the longer term, to the addition of true multitasking.
Further, by the time Microsoft began work on version 3.0, the
programming style of the MS-DOS team had changed considerably. The
team was still small, with a core group of just five people:
Zbikowski, Reynolds, Peters, Evans, and Mark Bebic. But the concerns
for maintainability that had dominated programming in larger systems
had percolated down to the MS-DOS environment. Now, the desire to use
tricks to optimize for speed had to be tempered by the need for
clarity and maintainability, and the small package of tightly written
code that was the early MS-DOS had to be sacrificed for the same
reasons.
Version 3.0
All told, the work on version 3.0 of MS-DOS proved to be long and
difficult. For a year and a half, Microsoft grappled with problems of
software incompatibility, remote file management, and logical device
independence at the network level. Even so, when IBM was ready to
announce its new Personal Computer AT, the network software for MS-DOS
was not quite ready, so in August 1984, Microsoft released version 3.0
to IBM without network software.
Version 3.0 supported the AT's larger fixed disk, its new CMOS clock,
and its high-capacity 1.2-megabyte floppy disks. It also provided the
same international support included earlier in versions 2.01 and 2.11.
These features were made available to Microsoft's other OEM customers
as version 3.05.
But version 3.0 was not a simple extension of version 2.0. In laying
the foundation for networking, the MS-DOS team had completely
redesigned and rewritten the DOS kernel.
Different as it was from version 1.0, version 2.0 had been built on
top of the same structure. For example, whereas file requests in MS-
DOS 1.0 used FCBs, requests in version 2.0 used file handles. However,
the version 2.0 handle calls would simply parse the pathname and then
use the underlying FCB calls in the same way as version 1.0. The
redirected input and output in version 2.0 further complicated the
file-system requests. When a program used one of the CP/M-compatible
calls for character input or output, MS-DOS 2.0 first opened a handle
and then turned it back into an FCB call at a lower level. Version 3.0
eliminated this redundancy by eliminating the old FCB input/output
code of versions 1 and 2, replacing it with a standard set of I/O
calls that could be called directly by both FCB calls and handle
calls. The look-alike calls for CP/M-compatible character I/O were
included as part of the set of handle calls. As a result of this
restructuring, these calls were distinctly faster in version 3.0 than
in version 2.0.
More important than the elimination of inefficiencies, however, was
the fact that this new structure made it easier to handle network
requests under the ISO Open System Interconnect model Microsoft was
using for networking. The ISO model describes a number of protocol
layers, ranging from the application-to-application interface at the
top level down to the physical link--plugging into the network--at the
lowest level. In the middle is the transport layer, which manages the
actual transfer of data. The layers above the transport layer belong
to the realm of the operating system; the layers below the transport
layer are traditionally the domain of the network software or
hardware.
On the IBM PC network, the transport layer and the server functions
were handled by IBM's Network Adapter card and the task of MS-DOS was
to support this hardware. For its other OEM customers, however,
Microsoft needed to supply both the transport and the server functions
as software. Although version 3.0 did not provide this general-purpose
networking software, it did provide the basic support for IBM's
networking hardware.
The support for IBM consisted of redirector and sharer software. MS-
DOS used an approach to networking in which remote requests were
routed by a redirector that was able to interact with the transport
layer of the network. The transport layer was composed of the device
drivers that could reliably transfer data from one part of the network
to another. Just before a call was sent to the newly designed low-
level file I/O code, the operating system determined whether the call
was local or remote. A local call would be allowed to fall through to
the local file I/O code; a remote call would be passed to the
redirector which, working with the operating system, would make the
resources on a remote machine appear as if they were local.
Version 3.1
Both the redirector and the sharer interfaces for IBM's Network
Adapter card were in place in version 3.0 when it was delivered to
IBM, but the redirector itself wasn't ready. Version 3.1, completed by
Zbikowski and Reynolds and released three months later, completed this
network support and made it available in the form of Microsoft
Networks for use on non-IBM network cards.
Microsoft Networks was built on the concept of "services" and
"consumers." Services were provided by a file server, which was part
of the Networks application and ran on a computer dedicated to the
task. Consumers were programs on various network machines. Requests
for information were passed at a high level to the file server; it was
then the responsibility of the file server to determine where to find
the information on the disk. The requesting programs--the consumers--
did not need any knowledge of the remote machine, not even what type
of file system it had.
This ability to pass a high-level request to a remote server without
having to know the details of the server's file structure allowed
another level of generalization of the system. In MS-DOS 3.1,
different types of file systems could be accessed on the same network.
It was possible, for example, to access a XENIX machine across the
network from an MS-DOS machine and to read data from XENIX files.
Microsoft Networks was designed to be hardware independent. Yet the
variability of the classes of programs that would be using its
structures was a major problem in developing a networking system that
would be transparent to the user. In evaluating this variability,
Microsoft identified three types of programs:
■ First were the MS-DOS-compatible programs. These used only the
documented software-interrupt method of requesting services from
the operating system and would run on any MS-DOS machine without
problems.
■ Second were the MS-DOS-based programs. These would run on IBM-
compatible computers but not necessarily on all MS-DOS machines.
■ Third were the programs that used undocumented features of MS-DOS
or that addressed the hardware directly. These programs tended to
have the best performance but were also the most difficult to
support.
Of these, Microsoft officially encouraged the writing of MS-DOS
compatible programs for use on the network.
Network concerns
The file-access module was changed in version 3.0 to simplify file
management on the network, but this did not solve all the problems.
For instance, MS-DOS still needed to handle FCB requests from programs
that used them, but many programs would open an FCB and never close
it. One of the functions of the server was to keep track of all open
files on the network, and it ran into difficulties when an FCB was
opened 50 or 100 times and never closed. To solve this problem,
Microsoft introduced an FCB cache in version 3.1 that allowed only
four FCBs to be open at any one time. If a fifth FCB was opened, the
least recently used one was closed automatically and released. In
addition, an FCBS command was added in the CONFIG.SYS file to allow
the user or network manager to change the maximum number of FCBs that
could be open at any one time and to protect some of the FCBs from
automatic closure.
In general, the logical device independence that had been a goal of
MS-DOS acquired new meaning--and generated new problems--with
networking. One problem concerned printers on the network. Commonly,
networks are used to allow several people to share a printer. The
network could easily accommodate a program that would open the
printer, write to it, and close it again. Some programs, however,
would try to use the direct IBM BIOS interface to access the printer.
To handle this situation, Microsoft's designers had to develop a way
for MS-DOS to intercept these BIOS requests and filter out the ones
the server could not handle. Once this was accomplished, version 3.1
was able to handle most types of printer output on the network in a
transparent manner.
Version 3.2
In January 1986, Microsoft released another revision of MS-DOS,
version 3.2, which supported 3-1/2-inch floppy disks. Version 3.2 also
moved the formatting function for a device out of the FORMAT utility
routine and into the device driver, eliminating the need for a special
hardware-dependent program in addition to the device driver. It
included a sample installable-block-device driver and, finally,
benefited the users and manufacturers of IBM-compatible computers by
including major rewrites of the MS-DOS utilities to increase
compatibility with those of IBM.
The Future
Since its appearance in 1981, MS-DOS has taken and held an enviable
position in the microcomputer environment. Not only has it "taught"
millions of personal computers "how to think," it has taught equal
millions of people how to use computers. Many highly sophisticated
computer users can trace their first encounter with these machines to
the original IBM PC and version 1.0 of MS-DOS. The MS-DOS command
interface is the one with which they are comfortable and it is the MS-
DOS file structure that, in one way or another, they wander through
with familiarity.
Microsoft has stated its commitment to ensuring that, for the
foreseeable future, MS-DOS will continue to evolve and grow, changing
as it has done in the past to satisfy the needs of its millions of
users. In the long term, MS-DOS, the product of a surprisingly small
group of gifted people, will undoubtedly remain the industry standard
for as long as 8086-based (and to some extent, 80286-based)
microcomputers exist in the business world. The story of MS-DOS will,
of course, remain even longer. For this operating system has earned
its place in microcomputing history.
JoAnne Woodcock
Return to The MS-DOS Encyclopedia: Contents