Hubbry Logo
search
logo
DOS
DOS
current hub
1156295

DOS

logo
Community Hub0 Subscribers
Read side by side
from Wikipedia

The boot screen and command-line interface of MS-DOS 6, with an example of its directory structure
The boot screen and command-line interface of FreeDOS, showing version information and an example of its directory structure

DOS (/dɒs/, /dɔːs/) is a family of disk-based operating systems for IBM PC compatible computers.[1] The DOS family primarily consists of IBM PC DOS and a rebranded version, Microsoft's MS-DOS, both of which were introduced in 1981. Later, compatible systems from other manufacturers are DR-DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1994). MS-DOS dominated the IBM PC compatible market between 1981 and 1995.

Although the name has come to be identified specifically with MS-DOS and compatible operating systems, DOS is a platform-independent acronym for disk operating system,[2] whose use predates the IBM PC. Dozens of other operating systems also use the acronym, beginning with the mainframe DOS/360 from 1966. Others include Apple DOS, Apple ProDOS, Atari DOS, Commodore DOS, TRSDOS, and AmigaDOS.

History

[edit]

Origins

[edit]
Apple CP/M from Digital Research on a Z-80 SoftCard for the Apple II

IBM PC DOS (and the separately sold MS-DOS) and its predecessor, 86-DOS, ran on Intel 8086 16-bit processors. It was developed to be similar to Digital Research's CP/M—the dominant disk operating system for 8-bit Intel 8080 and Zilog Z80 microcomputers—in order to simplify porting CP/M applications to MS-DOS.

The IBM Personal Computer (IBM 5150 PC)

When IBM introduced the IBM PC, built with the Intel 8088 microprocessor, they needed an operating system. Chairman John Opel had a conversation with fellow United Way National Board Executive Committee member Mary Maxwell Gates, who referred Opel to her son Bill Gates for help with an 8088-compatible build of CP/M.[3] IBM was then sent to Digital Research, and a meeting was set up. However, initial negotiations for the use of CP/M broke down: Digital Research wished to sell CP/M on a royalty basis, while IBM sought a single license, and to change the name to "PC DOS". Digital Research founder Gary Kildall refused, and IBM withdrew.[4][5]

A simulated SCP 86-DOS session

IBM again approached Bill Gates. Gates in turn approached Seattle Computer Products. There, programmer Tim Paterson had developed a variant of CP/M-80, intended as an internal product for testing SCP's new 16-bit Intel 8086 CPU card for the S-100 bus. The system was initially named QDOS (Quick and Dirty Operating System), before being made commercially available as 86-DOS. Microsoft purchased 86-DOS, allegedly for US$50,000. This became Microsoft Disk Operating System, MS-DOS, introduced in 1981. Within a year Microsoft licensed MS-DOS to over 70 other companies,[6] which supplied the operating system for their own hardware, sometimes under their own names such as Zenith Data Systems's Z-DOS.[7] Microsoft later required the use of the MS-DOS name, with the exception of the IBM variant. IBM continued to develop their version, PC DOS, for the IBM PC. Digital Research became aware that an operating system similar to CP/M was being sold by IBM (under the same name that IBM insisted upon for CP/M), and threatened legal action. IBM responded by offering an agreement: they would give PC consumers a choice of PC DOS or CP/M-86, Kildall's 8086 version. Side-by-side, CP/M cost US$200 more than PC DOS, and sales were low. CP/M faded, with MS-DOS and PC DOS becoming the marketed operating system for PCs and PC compatibles.[4]

Microsoft originally sold MS-DOS only to original equipment manufacturers (OEMs). One major reason for this was that not all early PCs were 100% IBM PC compatible. DOS was structured such that there was a separation between the system specific device driver code (IO.SYS) and the DOS kernel (MSDOS.SYS). Microsoft provided an OEM Adaptation Kit (OAK) which allowed OEMs to customize the device driver code to their particular system. By the early 1990s, most PCs adhered to IBM PC standards so Microsoft began selling a retail version of MS-DOS, starting with MS-DOS 5.0.

In the mid-1980s, Microsoft developed a multitasking version of DOS.[8][9] This version of DOS is generally referred to as "European MS-DOS 4" because it was developed for ICL and licensed to several European companies. This version of DOS supports preemptive multitasking, shared memory, device helper services and New Executable ("NE") format executables. None of these features were used in later versions of DOS, but they were used to form the basis of the OS/2 1.0 kernel. This version of DOS is distinct from the widely released PC DOS 4.0 which was developed by IBM and based upon DOS 3.3.

Digital Research CP/M-86 for the IBM Personal Computer Version 1.0

Digital Research attempted to regain the market lost from CP/M-86, initially with Concurrent DOS, FlexOS and DOS Plus (both compatible with both MS-DOS and CP/M-86 software), later with Multiuser DOS (compatible with both MS-DOS and CP/M-86 software) and DR DOS (compatible with MS-DOS software). Digital Research was bought by Novell, and DR DOS became PalmDOS and Novell DOS; later, it was part of Caldera (under the names OpenDOS and DR-DOS 7.02/7.03), Lineo, and DeviceLogics.

Gordon Letwin wrote in 1995 that "DOS was, when we first wrote it, a one-time throw-away product intended to keep IBM happy so that they'd buy our languages."[10] Microsoft expected that it would be an interim solution before the introduction of Xenix. The company planned to improve MS-DOS over time, so it would be almost indistinguishable from single-user Xenix, or XEDOS, which would also run on the Motorola 68000, Zilog Z-8000, and LSI-11; they would be upwardly compatible with Xenix, which BYTE in 1983 described as "the multi-user MS-DOS of the future".[11][12]

OS/2 1.0 featured a text mode interface similar to MS-DOS.

IBM, however, did not want to replace DOS.[13] After AT&T began selling Unix, Microsoft and IBM began developing OS/2 as an alternative.[10] The two companies later had a series of disagreements over two successor operating systems to DOS, OS/2 and Windows.[14] They split development of their DOS systems as a result.[15] The last retail version of MS-DOS was MS-DOS 6.22; after this, MS-DOS became part of Windows 95, 98 and Me. The last retail version of PC DOS was PC DOS 2000 (also called PC DOS 7 revision 1), though IBM did later develop PC DOS 7.10 for OEMs and internal use.

The FreeDOS project began on 26 June 1994, when Microsoft announced it would no longer sell or support MS-DOS. Jim Hall then posted a manifesto proposing the development of an open-source replacement. Within a few weeks, other programmers including Pat Villani and Tim Norman joined the project. A kernel, the COMMAND.COM command line interpreter (shell), and core utilities were created by pooling code they had written or found available. There were several official pre-release distributions of FreeDOS before the FreeDOS 1.0 distribution was released on 3 September 2006. Made available under the GNU General Public License (GPL), FreeDOS does not require license fees or royalties.[16][17]

Decline

[edit]

Early versions of Microsoft Windows ran on MS-DOS.[18] By the early 1990s, the Windows graphical shell saw heavy use on new systems. In 1995, Windows 95 was bundled as a standalone operating system that did not require a separate DOS license. Windows 95 (and Windows 98 and ME, that followed it) took over as the default OS kernel, though the MS-DOS component remained for compatibility. With Windows 95 and 98, but not ME, the MS-DOS component could be run without starting Windows.[19][20][21] With DOS no longer required to use Windows, the majority of users stopped using it directly.

Continued use

[edit]
DOSBox

As of 2025, available compatible systems are FreeDOS, ROM-DOS, PTS-DOS, RxDOS[22] and REAL/32. Some computer manufacturers, including Dell and HP, sell computers with FreeDOS as an OEM operating system,[23][24] [needs update] and some developers and computer engineers still use it because it is close to the hardware.[citation needed]

Embedded systems

[edit]

DOS's structure of accessing hardware directly allows it to be used in embedded devices. The final versions of DR-DOS are still aimed at this market.[25] ROM-DOS was used as operating system for the Canon PowerShot Pro 70.[26]

Emulation

[edit]

On Linux, it is possible to run DOSEMU, a Linux-native virtual machine for running DOS programs at near native speed. There are a number of other emulators for running DOS on various versions of Unix and Microsoft Windows such as DOSBox.[27][28] DOSBox is designed for legacy gaming (e.g. King's Quest, Doom) on modern operating systems.[18][27] DOSBox includes its own implementation of DOS which is strongly tied to the emulator and cannot run on real hardware, but can also boot MS-DOS, FreeDOS, or other DOS operating systems if needed.

Design

[edit]

MS-DOS and IBM PC DOS related operating systems are commonly associated with machines using the Intel x86 or compatible CPUs, mainly IBM PC compatibles. Machine-dependent versions of MS-DOS were produced for many non-IBM-compatible x86-based machines, with variations from relabelling of the Microsoft distribution under the manufacturer's name, to versions specifically designed to work with non-IBM-PC-compatible hardware. As long as application programs used DOS APIs instead of direct hardware access, they could run on both IBM-PC-compatible and incompatible machines. The original FreeDOS kernel, DOS-C, was derived from DOS/NT for the Motorola 68000 series of CPUs in the early 1990s. While these systems loosely resembled the DOS architecture, applications were not binary compatible due to the incompatible instruction sets of these non-x86-CPUs. However, applications written in high-level languages could be ported easily.

DOS is a single-user, single-tasking operating system with basic kernel functions that are non-reentrant: only one program at a time can use them, and DOS itself has no functionality to allow more than one program to execute at a time. The DOS kernel provides various functions for programs (an application program interface), like character I/O, file management, memory management, program loading and termination.

DOS provides the ability for shell scripting via batch files (with the filename extension .BAT). Each line of a batch file is interpreted as a program to run. Batch files can also make use of internal commands, such as GOTO and conditional statements.[29]

The operating system offers an application programming interface that allows development of character-based applications, but not for accessing most of the hardware, such as graphics cards, printers, or mice. This required programmers to access the hardware directly, usually resulting in each application having its own set of device drivers for each hardware peripheral. Hardware manufacturers would release specifications to ensure device drivers for popular applications were available.[30]

Boot sequence

[edit]
  • The bootstrap loader on PC-compatible computers, the master boot record, is located beginning at the boot sector, the first sector on the first track (track zero), of the boot disk. The ROM BIOS will load this sector into memory at address 0000h:7C00h, and typically check for a signature "55h AAh" at offset +1FEh. If the sector is not considered to be valid, the ROM BIOS will try the next physical disk in the row, otherwise it will jump to the load address with certain registers set up.
  • If the loaded boot sector happens to be a Master Boot Record (MBR), as found on partitioned media, it will relocate itself to 0000h:0600h in memory,[31] otherwise this step is skipped. The MBR code will scan the partition table, which is located within this sector, for an active partition (modern MBRs check if bit 7 is set at offset +1BEh+10h*n, whereas old MBRs simply check for a value of 80h), and, if found, load the first sector of the corresponding partition, which holds the Volume Boot Record (VBR) of that volume, into memory at 0000h:7C00h in the similar fashion as if it had been loaded by the ROM BIOS itself. The MBR will then pass execution to the loaded portion with certain registers set up.
  • The sector content loaded at 0000h:7C00h constitutes a VBR now. VBRs are operating system specific and cannot be exchanged between different DOS versions in general, as the exact behaviour differs between different DOS versions. In very old versions of DOS such as DOS 1.x, the VBR would load the whole IO.SYS/IBMBIO.COM file into memory at 0000h:0600h.[32] For this to work, these sectors had to be stored in consecutive order on disk by SYS. In later issues, it would locate and store the contents of the first two entries in the root directory at 0000h:0500h and if they happen to reflect the correct boot files as recorded in the VBR, the VBR would load the first 3 consecutive sectors of the IO.SYS/IBMBIO.COM file into memory at 0070h:0000h. The VBR also has to take care to preserve the contents of the Disk Parameter Table (DPT). Finally, it passes control to the loaded portion by jumping to its entry point with certain registers set up (with considerable differences between different DOS versions).
  • In later[clarification needed] DOS versions, where the VBR has loaded only the first 3 sectors of the IO.SYS/IBMBIO.COM file into memory, the loaded portion contains another boot loader, which will then load the remainder of itself into memory, using the root directory information stored at 0000h:0500h. For most versions, the file contents still need to be stored in consecutive order on disk. In older versions of DOS, which were still loaded as a whole, this step is skipped.
  • The DOS system initialization code will initialize its built-in device drivers and then load the DOS kernel, located in MSDOS.SYS on MS-DOS systems, into memory as well. In Windows 9x, the DOS system initialization code and built-in device drivers and the DOS kernel are combined into a single IO.SYS file while MSDOS.SYS is used as a text configuration file.
  • The CONFIG.SYS file is then read to parse configuration parameters. The SHELL variable specifies the location of the shell which defaults to COMMAND.COM.
  • The shell is loaded and executed.
  • The startup batch file AUTOEXEC.BAT is then run by the shell.[33][34]

The DOS system files loaded by the boot sector must be contiguous and be the first two directory entries.[35] As such, removing and adding this file is likely to render the media unbootable. It is, however, possible to replace the shell at will, a method that can be used to start the execution of dedicated applications faster. This limitation does not apply to any version of DR DOS, where the system files can be located anywhere in the root directory and do not need to be contiguous. Therefore, system files can be simply copied to a disk provided that the boot sector is DR DOS compatible already.

In PC DOS and DR DOS 5.0 and above, the DOS system files are named IBMBIO.COM instead of IO.SYS and IBMDOS.COM instead of MSDOS.SYS. Older versions of DR DOS used DRBIOS.SYS and DRBDOS.SYS instead.

Starting with MS-DOS 7.0 the binary system files IO.SYS and MSDOS.SYS were combined into a single file IO.SYS whilst MSDOS.SYS became a configuration file similar to CONFIG.SYS and AUTOEXEC.BAT. If the MSDOS.SYS BootGUI directive is set to 0, the boot process will stop with the command processor (typically COMMAND.COM) loaded, instead of executing WIN.COM automatically.

File system

[edit]

DOS uses a filesystem which supports 8.3 filenames: 8 characters for the filename and 3 characters for the extension. Starting with DOS 2 hierarchical directories are supported. Each directory name is also 8.3 format but the maximum directory path length is 64 characters due to the internal current directory structure (CDS) tables that DOS maintains. Including the drive name, the maximum length of a fully qualified filename that DOS supports is 80 characters using the format drive:\path\filename.ext followed by a null byte.

DOS uses the File Allocation Table (FAT) filesystem. This was originally FAT12 which supported up to 4078 clusters per drive. DOS 3.0 added support for FAT16 which used 16-bit allocation entries and supported up to 65518 clusters per drive. Compaq MS-DOS 3.31 added support for FAT16B which removed the 32‑MiB drive limit and could support up to 512 MiB. Finally MS-DOS 7.1 (the DOS component of Windows 9x) added support for FAT32 which used 32-bit allocation entries and could support hard drives up to 137 GB (127 GiB) and beyond.

Starting with DOS 3.1, file redirector support was added to DOS. This was initially used to support networking but was later used to support CD-ROM drives with MSCDEX. IBM PC DOS 4.0 also had preliminary installable file system (IFS) support but this was unused and removed in DOS 5.0. DOS also supported Block Devices ("Disk Drive" devices) loaded from CONFIG.SYS that could be used under the DOS file system to support network devices.

Drive naming scheme

[edit]

In DOS, drives are referred to by identifying letters. Standard practice is to reserve "A" and "B" for floppy drives. On systems with only one floppy drive DOS assigns both letters to the drive, prompting the user to swap disks as programs alternate access between them. This facilitates copying from floppy to floppy or having a program run from one floppy while accessing its data on another. Hard drives were originally assigned the letters "C" and "D". DOS could only support one active partition per drive. As support for more hard drives became available, this developed into first assigning a drive letter to each drive's active primary partition, then making a second pass over the drives to allocate letters to logical drives in the extended partition, then a third pass to give any other non-active primary partitions their names (where such additional partitions existed and contained a DOS-supported file system). Lastly, DOS allocates letters for optical disc drives, RAM disks, and other hardware. Letter assignments usually occur in the order the drivers are loaded, but the drivers can instruct DOS to assign a different letter; drivers for network drives, for example, typically assign letters nearer to the end of the alphabet.[36]

Because DOS applications use these drive letters directly (unlike the /dev directory in Unix-like systems), they can be disrupted by adding new hardware that needs a drive letter. An example is the addition of a new hard drive having a primary partition where a pre-existing hard drive contains logical drives in extended partitions; the new drive will be assigned a letter that was previously assigned to one of the extended partition logical drives. Moreover, even adding a new hard drive having only logical drives in an extended partition would still disrupt the letters of RAM disks and optical drives. This problem persisted through Microsoft's DOS-based 9x versions of Windows until they were replaced by versions based on the NT line, which preserves the letters of existing drives until the user changes them.[36] Under DOS, this problem can be worked around by defining a SUBST drive and installing the DOS program into this logical drive. The assignment of this drive would then be changed in a batch job whenever the application starts. Under some versions of Concurrent DOS, as well as under Multiuser DOS, System Manager and REAL/32, the reserved drive letter L: will automatically be assigned to the corresponding load drive whenever an application starts.

Reserved device names

[edit]
Error message when attempting to use a reserved name while naming or renaming a file or folder

There are reserved device names in DOS that cannot be used as filenames regardless of extension as they are occupied by built-in character devices. These restrictions also affect several Windows versions, in some cases causing crashes and security vulnerabilities.[37]

The reserved names are:

In Windows 95 and Windows 98, typing in the location of the reserved name (such as CON/CON, AUX/AUX, or PRN/PRN) crashes the operating system, of which Microsoft has provided a security fix for the issue. In Windows XP, the name of the file or folder using a reserved name silently reverts to its previous name, with no notification or error message. In Windows Vista and later, attempting to use a reserved name for a file or folder brings up an error message saying "The specified device name is invalid."

These names (except for NUL) have continued to be supported in all versions of MS-DOS, PC DOS and DR-DOS ever since.[39] LST was also available in some OEM versions of MS-DOS 1.25, whereas other OEM versions of MS-DOS 1.25 already used LPT1 (first line printer) and COM1 (first serial communication device) instead, as introduced with PC DOS. In addition to LPT1 and LPT2 as well as COM1 to COM3, Hewlett-Packard's OEM version of MS-DOS 2.11 for the HP Portable Plus also supported LST as alias for LPT2 and 82164A as alias for COM2;[40][41] it also supported PLT for plotters.[40][41] Otherwise, COM2, LPT2, LPT3 and the CLOCK$ (still named CLOCK in some issues of MS-DOS 2.11[42][40][41]) clock device were introduced with DOS 2.0, and COM3 and COM4 were added with DOS 3.3.[39] Only the multitasking MS-DOS 4 supported KEYBD$ and SCREEN$. DR DOS 5.0 and higher and Multiuser DOS support an $IDLE$ device for dynamic idle detection to saving power and improve multitasking. LPT4 is an optional built-in driver for a fourth line printer supported in some versions of DR-DOS since 7.02. CONFIG$ constitutes the real mode PnP manager in MS-DOS 7.0–8.0.

AUX typically defaults to COM1, and PRN to LPT1 (LST),[39] but these defaults can be changed in some versions of DOS to point to other serial or parallel devices.[40][41][43] The PLT device (present only in some HP OEM versions of MS-DOS) was reconfigurable as well.[40][41]

Filenames ended with a colon (:) such as NUL: conventionally indicate device names, but the colon is not actually a part of the name of the built-in device drivers. Colons are not necessary to be typed in some cases, for example:

ECHO This achieves nothing > NUL

It is still possible to create files or directories using these reserved device names, such as through direct editing of directory data structures in disk sectors. Such naming, such as starting a file name with a space, has sometimes been used by viruses or hacking programs to obscure files from users who do not know how to access these locations.

Memory management

[edit]

DOS was designed for the Intel 8088 processor, which can only directly access a maximum of 1 MiB of RAM.[44] Both IBM and Microsoft chose 640 kibibytes (KiB) as the maximum amount of memory available to programs and reserved the remaining 384 KiB for video memory, the read-only memory of adapters on some video and network peripherals, and the system's BIOS. By 1985, some DOS applications were already hitting the memory limit, while much of reserved was unused, depending on the machine's specifications.[45]

Specifications were developed to allow access to additional memory. The first was the Expanded Memory Specification (EMS) was designed to allow memory on an add-on card to be accessed via a 64 KiB page frame in the reserved upper memory area.[46] 80386 and later systems could use a virtual 8086 mode (V86) mode memory manager like EMM386 to create expanded memory from extended memory without the need of an add-on card.[47] The second specification was the Extended Memory Specification (XMS) for 80286 and later systems. This provided a way to copy data to and from extended memory, access to the 65,520-byte high memory area[48] directly above the first megabyte of memory and the upper memory block area. Generally XMS support was provided by HIMEM.SYS or a V86 mode memory manager like QEMM or 386MAX which also supported EMS.[49]

Starting with DOS 5,[50] DOS could directly take advantage of the HMA by loading its kernel code and disk buffers there via the DOS=HIGH statement in CONFIG.SYS. DOS 5+ also allowed the use of available upper memory blocks via the DOS=UMB statement in CONFIG.SYS.[51]

DOS under OS/2 and Windows

[edit]

The DOS emulation in OS/2 and Windows runs in much the same way as native applications do. They can access all of the drives and services, and can even use the host's clipboard services. Because the drivers for file systems and such forth reside in the host system, the DOS emulation needs only provide a DOS API translation layer which converts DOS calls to OS/2 or Windows system calls. The translation layer generally also converts BIOS calls and virtualizes common I/O port accesses which many DOS programs commonly use.

In Windows 3.1 and 9x, the DOS virtual machine is provided by WINOLDAP. WinOldAp creates a virtual machine based on the program's PIF file, and the system state when Windows was loaded. The DOS graphics mode, both character and graphic, can be captured and run in the window. DOS applications can use the Windows clipboard by accessing extra published calls in WinOldAp, and one can paste text through the WinOldAp graphics.

The emulated DOS in OS/2 and Windows NT is based upon DOS 5. Although there is a default configuration (config.sys and autoexec.bat), one can use alternate files on a session-by-session basis. It is possible to load drivers in these files to access the host system, although these are typically third-party.

Under OS/2 2.x and later, the DOS emulation is provided by DOSKRNL. This is a file that represents the combined IBMBIO.COM and IBMDOS.COM, the system calls are passed through to the OS/2 windowing services. DOS programs run in their own environment, the bulk of the DOS utilities are provided by bound DOS / OS2 applications in the \OS2 directory. OS/2 can run Windows 3.1 applications by using a modified copy of Windows (Win-OS/2). The modifications allow Windows 3.1 programs to run seamlessly on the OS/2 desktop, or one can start a WinOS/2 desktop, similar to starting Windows from DOS.

OS/2 allows for 'DOS from Drive A:', (VMDISK). This is a real DOS, like MS-DOS 6.22 or PC DOS 5.00. One makes a bootable floppy disk of the DOS, adds a number of drivers from OS/2, and then creates a special image. The DOS booted this way has full access to the system, but provides its own drivers for hardware. One can use such a disk to access cdrom drives for which there is no OS/2 driver.

In all 32-bit (IA-32) editions of the Windows NT family since 1993, DOS emulation is provided by way of a virtual DOS machine (NTVDM). 64-bit (IA-64 and x86-64) versions of Windows do not support NTVDM and cannot run 16-bit DOS applications directly; third-party emulators such as DOSbox can be used to run DOS programs on those machines.

User interface

[edit]

DOS systems use a command-line interface. A program is started by entering its filename at the command prompt. DOS systems include utility programs and provide internal commands that do not correspond to programs.[52]

In an attempt to provide a more user-friendly environment, numerous software manufacturers wrote file management programs that provided users with WIMP interfaces. Microsoft Windows is a notable example, eventually resulting in Microsoft Windows 9x becoming a self-contained program loader, and replacing DOS as the most-used PC-compatible program loader. Text user interface programs included Norton Commander, DOS Navigator, Volkov Commander, Quarterdesk DESQview, and Sidekick. Graphical user interface programs included Digital Research's GEM (originally written for CP/M) and GEOS.

Eventually, the manufacturers of major DOS systems began to include their own environment managers. MS-DOS/IBM DOS 4 included DOS Shell;[53] DR DOS 5.0, released the following year, included ViewMAX, based upon GEM.[54]

Terminate and stay resident

[edit]

Although DOS is not a multitasking operating system, it does provide a terminate-and-stay-resident (TSR) function which allows programs to remain resident in memory. These programs can hook the system timer or keyboard interrupts to allow themselves to run tasks in the background or to be invoked at any time, preempting the current running program and effectively implementing a simple form of multitasking on a program-specific basis. The DOS PRINT command does this to implement background print spooling. Borland Sidekick, a popup personal information manager (PIM), also uses this technique.

Terminate-and-stay-resident programs are also used to provide additional features not available by default. Programs like CED and DOSKEY provide command-line editing facilities beyond what is available in COMMAND.COM. Programs like the Microsoft CD-ROM Extensions (MSCDEX) provide access to files on CD-ROM disks.

Some TSRs can even perform a rudimentary form of task switching. For example, the shareware program Back and Forth (1990)[55] has a hotkey to save the state of the currently-running program to disk, load another program, and switch to it, making it possible to switch "back and forth" between programs (albeit slowly, due to the disk access required). Back and Forth could not enable background processing however; that needed DESQview (on at least a 386).

Software

[edit]
Arachne web browser

Development tools

[edit]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia
from Grokipedia
DOS (Disk Operating System) is a family of closely related, command-line operating systems designed for personal computers, particularly those based on the x86 architecture, providing basic file management, program execution, and disk operations through a text-based interface.[1] The term originated in the 1970s but gained prominence with the rise of IBM PC compatibles in the early 1980s, where it served as the foundational software layer for running applications and managing hardware resources in a single-tasking environment.[2] The most influential implementation, MS-DOS (Microsoft Disk Operating System), was developed by Microsoft and first released as version 1.0 on August 12, 1981, alongside the IBM Personal Computer (model 5150).[3] MS-DOS originated from 86-DOS, a system created by Tim Paterson at Seattle Computer Products in April 1980, which Microsoft licensed for $25,000 in December 1980 and later purchased outright for $50,000 in July 1981.[4] Adapted and customized for IBM under the name PC DOS, it powered the IBM PC's Intel 8088 processor and became the basis for Microsoft's retail version, MS-DOS, licensed to other PC manufacturers.[4] Key early enhancements included version 2.0 in March 1983, which added support for subdirectories, hard disk drives, and the XCOPY command, aligning with the IBM PC/XT release.[4] MS-DOS dominated the personal computing market throughout the 1980s and into the 1990s, serving as the platform for thousands of business and productivity applications, including early versions of Microsoft Office and WordPerfect.[4] Its command-driven interface, accessed via the COMMAND.COM shell, allowed users to execute commands like DIR for file listings and COPY for file transfers, while batch files enabled simple scripting.[2] By the mid-1990s, MS-DOS evolved into versions like 6.22 (1994), incorporating features such as DriveSpace disk compression, but it was gradually supplanted by graphical successors like Windows 95, which retained backward compatibility through a DOS mode.[5] The system's open licensing model spurred the growth of IBM PC clones, standardizing the PC ecosystem and contributing to the explosive expansion of personal computing.[4]

History

Origins

The origins of DOS trace back to the need for an operating system compatible with Intel's 8086 microprocessor, heavily influenced by Digital Research's CP/M, which dominated early microcomputer systems. CP/M, introduced in 1974, provided a standardized interface for 8-bit processors like the Intel 8080 and Zilog Z80, featuring a command structure based on simple text commands (e.g., DIR for directory listing) and a modular design separating the basic input/output system (BDOS) from hardware-specific components. This 8-bit architecture and API compatibility inspired developers seeking a similar environment for the emerging 16-bit 8086, as CP/M-86—a 16-bit version—was not yet available from Digital Research in 1980, prompting the creation of a CP/M-like alternative to facilitate software porting.[6][7] In April 1980, Tim Paterson, an engineer at Seattle Computer Products (SCP), began developing 86-DOS—initially called QDOS, or "Quick and Dirty Operating System"—as a temporary solution for SCP's 8086-based hardware, which lacked a suitable OS at the time. SCP, a small firm producing memory boards and early 8086 systems since 1979, required software to demonstrate their hardware's capabilities, leading Paterson to build 86-DOS in just two months using the CP/M 2.0 Interface Guide from 1976. This made 86-DOS the first operating system fully compatible with the 8086 architecture, supporting SCP's 8086-based S-100 computer systems and later commercialized as 86-DOS version 0.33 in December 1980, with features like a CP/M-emulating system call interface for easier application development.[6][7] Microsoft, seeking an OS for IBM's forthcoming personal computer, licensed 86-DOS from SCP in December 1980 for $25,000 and acquired full rights in July 1981 for $50,000, under the leadership of co-founders Bill Gates and Paul Allen. Paterson joined Microsoft in May 1981 to refine the code, adapting it alongside engineer Bob O'Rear for IBM's requirements, resulting in its rebranding as PC-DOS for IBM (released August 1981) and MS-DOS for other licensees. The initial version was a single-tasking system supporting floppy disks, featuring the File Allocation Table (FAT) file system—originally designed by Microsoft's Marc McDonald in 1977 for standalone BASIC interpreters—and the COMMAND.COM interpreter for executing commands and batch files, providing a text-based interface reminiscent of CP/M.[4][7]

Major Versions and Development

MS-DOS 1.0 was released in August 1981 specifically for the IBM PC, providing basic disk support for 160 KB floppy disks along with the ability to execute .COM and .EXE files and process batch files.[8][9] This initial version operated on a 16-bit architecture compatible with the Intel 8088 processor in the IBM PC.[9] Subsequent upgrades addressed growing hardware capabilities. MS-DOS 2.0, launched in March 1983, introduced support for subdirectories to enable hierarchical file organization and limited hard disk partitions to 10 MB to accommodate the IBM PC XT's storage.[4][10] MS-DOS 3.0 followed in 1984, expanding partition support to 32 MB for larger hard drives and adding foundational networking features such as file locking and redirection to facilitate shared resource access.[9][11] By the early 1990s, memory constraints became a key focus. MS-DOS 5.0, released in 1991, innovated memory management with HIMEM.SYS for accessing extended memory beyond 1 MB and EMM386.EXE to emulate expanded memory, significantly increasing available RAM for applications.[12][13] It also included the Undelete utility to recover accidentally deleted files by preserving directory entries.[14] MS-DOS 6.x, starting with version 6.0 in March 1993, further enhanced storage and diagnostics with DoubleSpace (later renamed DriveSpace) for on-the-fly disk compression to effectively double capacity, SCANDISK for improved surface scanning and error repair over CHKDSK, and support for 32-bit protected mode execution via DOS/4GW, a DOS extender that allowed programs to access extended memory.[15][16][17][18] Competing variants emerged to challenge Microsoft's dominance. DR-DOS, introduced in 1988 by Digital Research, offered enhanced features like built-in multitasking derived from its Concurrent DOS roots, appealing to users seeking alternatives to MS-DOS.[19][20] Later, FreeDOS began development in 1994 as an open-source successor compatible with MS-DOS applications, ensuring continued availability for legacy software without proprietary restrictions.[21] Microsoft's distribution strategy relied on OEM licensing agreements, allowing hardware manufacturers to customize and bundle the OS, which led to variants like IBM's PC-DOS, a tailored version of MS-DOS for IBM systems that included minor hardware-specific adjustments.[8][22] This model enabled widespread adoption across compatible PCs while maintaining Microsoft's control over core development.[8]

Decline and Continued Relevance

The decline of DOS as a standalone operating system accelerated in the early 1990s with the rise of graphical user interfaces, particularly Microsoft's Windows 3.x series released in 1990, which provided a more user-friendly layer atop DOS while beginning to supplant its command-line dominance.[23] This shift culminated in 1995 with the launch of Windows 95, which integrated a version of MS-DOS (7.0) as an underlying compatibility layer but operated as a standalone OS, allowing DOS applications to run without a separate DOS installation and further diminishing the need for pure DOS environments.[24] As a result, standalone DOS usage waned rapidly on consumer PCs. By the mid-1990s, Windows had captured over 80% of the PC operating system market, with Windows 95 alone reaching approximately 57% market share by 1998, effectively reducing standalone DOS to a niche role outside specialized applications.[25][26] Despite its decline in general computing, DOS maintained relevance in embedded systems throughout the 2000s and into the 2010s, powering industrial controllers, point-of-sale terminals, and legacy hardware where stability and low resource demands outweighed the benefits of modern OSes.[27] For instance, variants of DOS continued to underpin operations in some automated teller machines (ATMs) and retail POS systems due to their reliability in resource-constrained environments.[28] The advent of emulation tools revived interest in DOS for modern hardware, with DOSBox—first released in 2002—emerging as a key emulator to run legacy DOS software and games on contemporary operating systems by simulating the original IBM PC-compatible environment. Complementing this, FreeDOS, an open-source DOS-compatible OS initiated in 1994, saw modern distributions like version 1.4 in 2025, supporting hobbyists, retro computing enthusiasts, and compatibility testing for legacy business software.[29] On the legal front, Microsoft ended mainstream support for MS-DOS 6.22, its final standalone version from 1994, on December 31, 2001, with extended support concluding by 2006. However, in 2014, Microsoft released the source code for early MS-DOS versions 1.25 and 2.0 to the Computer History Museum under the MIT License, enabling non-commercial study, modification, and preservation by developers and historians. In April 2024, Microsoft released the source code for MS-DOS 4.0 on GitHub under the MIT License.[30][31]

Design and Architecture

Boot Sequence

The boot sequence of DOS, the Disk Operating System developed by Microsoft for IBM PC-compatible computers, begins with the computer's power-on self-test (POST) performed by the ROM BIOS, which verifies hardware components such as memory, keyboard, and display before proceeding to locate a bootable device.[32][33] Following POST, the BIOS searches for the Master Boot Record (MBR) in the first sector of the boot device—typically a floppy disk or hard drive—according to the predefined boot order, and loads it into memory at address 0000:7C00h if a valid signature (AA55h) is present.[32][33] This MBR contains the partition table and bootstrap loader code, which then identifies the active bootable partition and transfers control to its boot sector.[33] The DOS boot sector, executed next, initializes basic hardware and uses the file allocation table (FAT) to locate and load the core system files from the root directory of the boot volume.[34] In MS-DOS, the process loads IO.SYS first, a hidden system file that contains the DOS BIOS for device drivers and hardware initialization, including support for console, printer, auxiliary port, clock, and disk devices.[33][34] IO.SYS then loads MSDOS.SYS, the core kernel responsible for file system management, memory allocation, and process handling, relocating it to the appropriate memory area above the BIOS data structures.[32][33] Once these are in place, the system searches for and executes COMMAND.COM, the command interpreter that provides the shell interface, along with any specified drivers or buffers.[34] The boot sector's loader routine handles this sequence by reading sectors into memory, verifying file existence, and jumping to the entry point of IO.SYS.[35] User configuration occurs after core loading, with IO.SYS processing the CONFIG.SYS file in the root directory to install device drivers (e.g., via DEVICE= statements), set file handles (FILES=), and configure buffers (BUFFERS=), enabling customization for additional hardware like expanded memory managers.[34][33] Following CONFIG.SYS, the system executes AUTOEXEC.BAT, a batch file that runs startup commands, such as setting environment variables (SET) or loading terminate-and-stay-resident (TSR) programs, before displaying the DOS prompt (e.g., C:>).[32][34] In later versions like MS-DOS 6.0, options like pressing F5 to skip these files or F8 for step-by-step execution were added for troubleshooting.[34] Variants exist between Microsoft MS-DOS and IBM PC-DOS: MS-DOS uses IO.SYS and MSDOS.SYS, while early IBM PC-DOS (version 1.00) employs IBMBIO.COM and IBMDOS.COM, loaded from the floppy's first and subsequent sectors into memory starting at 0000:0600h, with the boot sector checking for these files explicitly before proceeding.[35][34] In IBM PC-DOS 1.00, the boot sector lacks a BIOS Parameter Block (BPB) and relies on fixed floppy geometry, differing from MS-DOS's more flexible structure in later versions.[35] Common boot failures include the "Non-system disk or disk error" message if a non-bootable floppy is inserted or the MBR/boot sector is invalid, halting the process after POST; missing core files like IO.SYS trigger "Missing operating system" errors during sector loading.[32][34] If no active partition is found, the BIOS may display "No boot device found" and prompt for media insertion.[32] These errors often require replacing faulty media or repairing the boot sector using tools like SYS.COM.[34]

File System

The file system in DOS, known as the File Allocation Table (FAT), serves as the primary mechanism for organizing and accessing data on storage media such as floppy disks and hard drives. Introduced with MS-DOS 1.0 in 1981, the FAT system uses a table of linked entries to map clusters—fixed-size blocks of disk space—enabling efficient file storage and retrieval. In FAT12 and FAT16 variants, which were standard in early DOS versions, the File Allocation Table functions as a linked list where each entry indicates the location of the next cluster in a file or marks the end of a file, with unused clusters available for allocation.[36] This structure begins immediately after the boot sector and reserved sectors, with the table replicated for redundancy, though DOS primarily uses the first copy.[37] The root directory in FAT12 volumes, such as those on early 360 KB floppy disks, is limited to 112 entries, each 32 bytes long, restricting the number of files and subdirectories directly under the root to this fixed size before requiring subdirectories for expansion.[38] In contrast, FAT16 on hard disks typically supports up to 512 root directory entries, but the overall design emphasizes simplicity over scalability. Drive naming follows a sequential letter-based convention, with A: assigned to the first floppy drive and C: to the first hard disk partition, reflecting the era's hardware priorities where floppy drives preceded hard disks.[39] Pure DOS lacks support for Universal Naming Convention (UNC) paths like \server\share, limiting file access to local drives without native networking integration.[39] DOS reserves specific names for hardware devices to enable output redirection, including CON for the console, PRN for the printer, AUX for the auxiliary serial port, and NUL for a null device that discards data. Additional reserved names encompass COM1 through COM4 for serial ports and LPT1 through LPT3 for parallel ports, allowing commands to route input/output to these devices instead of files—for instance, directing print output to LPT1.[39] File naming adheres to the 8.3 format, comprising up to 8 uppercase ASCII characters for the base name followed by a period and up to 3 characters for the extension (e.g., PROGRAM.EXE), with no spaces, lowercase letters, or multiple periods permitted to ensure compatibility with the system's parsing limitations.[40] Common file operations in DOS are handled via command-line utilities integrated into the shell. The DIR command lists directory contents, displaying file names, sizes, dates, and attributes, with options for sorting, wide display, or including subdirectories (e.g., DIR /W for wide format).[41] The COPY command duplicates files or combines them, supporting binary or ASCII modes and verification (e.g., COPY FILE1.TXT C:\BACKUP /V to copy with verification).[42] For deletion, the DEL (or ERASE) command removes specified files, optionally prompting for confirmation or forcing read-only deletions (e.g., DEL *.TMP /P to prompt before deleting temporary files).[43] Key limitations of the FAT12/16 file system in DOS include the absence of user permissions or access controls, relying solely on basic file attributes like read-only or hidden flags for rudimentary protection.[44] FAT16 partitions are capped at 2 GB due to 16-bit cluster addressing, which supports a maximum of 65,525 clusters (e.g., with 32 KB clusters yielding approximately 2 GB).[45] Native support excludes long filenames beyond the 8.3 convention, requiring third-party extensions like VFAT for compatibility with extended naming in later systems.[39]

Memory Management

DOS memory management was fundamentally constrained by the Intel 8086 processor's real mode architecture, which provided a 20-bit address bus limiting the total addressable memory to 1 MB.[46] Within this 1 MB space, the first 640 KB, known as conventional memory, was available for DOS and application programs, while the remaining 384 KB, referred to as upper memory, was reserved for hardware peripherals, video adapters, and system ROMs.[47] This division arose from hardware design choices in early IBM PCs, where BIOS and adapter ROMs occupied addresses from 640 KB to 1 MB, leaving conventional memory as the primary workspace for software execution.[48] The DOS memory map segmented this space into distinct regions to optimize usage under these limitations. Conventional memory spanned from 0 to 640 KB and served as the default allocation area for programs and the transient program area (TPA).[47] Upper memory blocks (UMBs), located between 640 KB and 1 MB, could be carved out from unused portions of the upper memory area for device drivers and TSR programs, but required memory management tools to access effectively.[46] To extend beyond 1 MB on systems with more RAM, DOS supported extended memory via the Extended Memory Specification (XMS), managed by the HIMEM.SYS driver, which allowed programs to allocate and transfer data to memory above 1 MB.[47] Similarly, expanded memory adhered to the Expanded Memory Specification (EMS), emulated on 80386 and later processors by EMM386.EXE, which provided a page-swapping mechanism to simulate additional conventional memory from extended RAM.[47] Third-party DOS memory managers, such as Quarterdeck's QEMM and Qualitas' 386MAX, addressed fragmentation and underutilization by optimizing UMB allocation and loading device drivers and buffers into high memory.[46] These tools analyzed the upper memory area for free blocks, linked them into a contiguous chain under DOS control, and enabled the LOADHIGH command to relocate small utilities above 640 KB, thereby maximizing available conventional memory for applications.[48] For instance, QEMM's Stealth mode hid portions of system code in extended memory to free up conventional space, while 386MAX offered similar UMB optimization with additional virtual memory features on 80386 systems.[46] Program loading in DOS varied by executable format to accommodate memory constraints. .COM files, limited to a single 64 KB segment, were loaded directly into the TPA without relocation, making them simple but restrictive for larger codebases.[49] In contrast, .EXE files included a header with relocation information, allowing the DOS loader to load relocatable segments anywhere in available memory, supporting programs up to the full 640 KB conventional limit.[49] For applications exceeding available RAM, overlay techniques divided code into segments loaded on demand; the program manager swapped inactive overlays to disk or unused memory, enabling execution of complex software like early games or compilers within the 1 MB boundary.[33] Base DOS lacked support for protected mode, relying entirely on real mode where all programs shared the same address space without isolation or memory protection.[48] Addressing in real mode used 16-bit segment registers combined with 16-bit offsets, inherently restricting each segment to a maximum size of 64 KB due to the offset range.[48] This segmentation model required programmers to manage multiple segments for data, code, and stack, complicating development for anything beyond small utilities.[47]

Integration with Modern Operating Systems

OS/2 version 1.x, released in 1987, incorporated a DOS compatibility box that emulated a virtual machine environment running MS-DOS 3.3 to support legacy DOS applications.[50] This single-session virtual DOS machine (VDM) allowed OS/2 to execute DOS programs alongside its protected-mode operations, providing backward compatibility for early PC software without requiring a separate boot into DOS.[51] Windows 3.x, spanning releases from 1990 to 1995, operated as a graphical shell layered directly atop an underlying MS-DOS installation, leveraging DOS for real-mode execution, file system access, and hardware interaction.[52] In real mode, Windows 3.x adhered to the 640 KB conventional memory limit of DOS, while standard and enhanced modes utilized protected-mode extensions but still relied on DOS for booting and basic I/O operations.[53] The Windows 9x series (Windows 95, 98, and ME), featuring a hybrid 16/32-bit kernel, integrated DOS as the primary command prompt via COMMAND.COM and used virtual DOS machines (VDM) to run DOS applications in isolated sessions. For 16-bit Windows applications, support came through the Windows on Windows (WOW) subsystem, which translated API calls to the 32-bit environment while maintaining compatibility with DOS-hosted elements.[54] In contrast, the Windows NT lineage, starting with Windows NT and continuing through Windows 2000 and XP, lacked native DOS support due to its fully 32-bit architecture, instead employing the NT Virtual DOS Machine (NTVDM) subsystem to emulate DOS and 16-bit Windows environments up to Windows XP.[55] Beyond Windows XP, Microsoft deprecated NTVDM, shifting legacy DOS support to third-party emulators such as DOSBox for running older applications. As of 2025, emulators like DOSBox and its fork DOSBox-X continue to be actively developed, providing enhanced support for DOS software on modern operating systems including Windows 11, Linux, and macOS.[55][56] DOS integration in these modern systems imposed key limitations, including restricted direct hardware access within virtualized modes to prevent system instability, as VDMs and NTVDM intercepted low-level interrupts for emulation.[57] Additionally, the Year 2000 (Y2K) issues inherent to MS-DOS's two-digit year handling persisted under Windows, causing date miscalculations in legacy applications unless patched, such as through Microsoft's updates for affected components like file managers.[58]

User Interface

Command-Line Interface

The command-line interface of DOS is provided by COMMAND.COM, the default command processor that serves as the primary shell for user interaction. Loaded into memory during the boot process, COMMAND.COM interprets keyboard input, executes commands, and manages the environment, including searching for executable files in the current directory and along the PATH variable. The interface is text-based, with users entering commands at a prompt displayed on the screen, typically in the format "C:>", indicating the current drive followed by a greater-than sign, though this can vary based on the active directory and drive.[59][60] Batch files, identified by the .BAT extension, enable scripting by allowing sequences of commands to be stored in plain text files and executed as a single unit, facilitating automation of repetitive tasks. These files support replaceable parameters (%0 through %9 for command-line arguments) and control structures like ECHO for displaying messages, GOTO for branching, and IF for conditional execution based on conditions such as string comparisons or error levels. Error levels, which are integer return codes from commands (0 typically indicating success and values greater than 0 signaling errors), can be tested in batch files using constructs like IF ERRORLEVEL n to direct program flow.[59][60][61] DOS commands are divided into internal commands, which are built directly into COMMAND.COM and execute without loading additional files, and external commands, which are separate executable programs (typically .COM or .EXE files) loaded from disk when invoked. Internal commands include CD (or CHDIR) to change the current directory (e.g., CD \NEWDIR or CD .. to move to the parent directory), MKDIR (or MD) and RMDIR (or RD) to create or remove directories (e.g., MKDIR SUBDIR, requiring the directory to be empty for removal), TYPE to display the contents of a text file (e.g., TYPE FILE.TXT), and REN to rename files or directories (e.g., REN OLD.TXT NEW.TXT, supporting wildcards like *.TXT). External commands, such as FORMAT, require loading from disk and include options like FORMAT A: to initialize a floppy disk or FORMAT C: /S to make it bootable by copying system files. Other internal commands like CLS (to clear the screen) and PATH (to set the search path for executables) enhance navigation and efficiency.[59][60] Data flow between commands is supported through piping (using | to send the output of one command as input to another, e.g., DIR | SORT to alphabetically sort a directory listing) and redirection (using > to send output to a file or device, e.g., TYPE FILE.TXT > OUTPUT.TXT, or >> to append rather than overwrite). The interface operates in a case-insensitive manner for commands, filenames, and parameters, allowing users to enter DIR, dir, or DiR interchangeably, which simplifies input but preserves the original case in file listings.[59][60][62] Customization of the user experience is possible via the PROMPT command, an internal utility that allows modification of the prompt string using special codes, such as $P for the current path, $G for the greater-than sign, $T for the current time, or $D for the date (e.g., PROMPT PPG displays the full path followed by >, or PROMPT $T PPG includes time and path). This feature enables tailored prompts for better context during sessions, and changes can be made permanent by including the PROMPT command in AUTOEXEC.BAT.[59][60]

Terminate-and-Stay-Resident Programs

Terminate-and-Stay-Resident (TSR) programs in DOS are utility applications that load into memory, execute their initialization, and then terminate while remaining resident to provide ongoing services or quick access without requiring a full reload. This mechanism allows TSRs to extend core DOS capabilities, such as background printing or input device support, by intercepting system interrupts and running in the background alongside the primary foreground application. Unlike standard programs that release all allocated memory upon exit, TSRs retain a fixed block for their code, data, and interrupt handlers, enabling pseudo-multitasking in an otherwise single-tasking environment.[63] The primary mechanism for a program to become resident involves invoking DOS system calls to terminate execution while preserving memory. The original method uses interrupt 27h, where the program sets DX to the offset of the byte immediately following the last byte of code to retain (from the Program Segment Prefix, or PSP), limiting the resident portion to a maximum of 64 KB; upon invocation, DOS releases memory beyond this offset but keeps the specified block allocated until reboot. For more flexibility, especially with larger programs, interrupt 21h with AH=31h is preferred, where AL specifies a return code (0-255) passed to the parent process, and DX indicates the number of 16-byte paragraphs to keep resident starting from the PSP, allowing sizes exceeding 64 KB without the offset-based calculation of interrupt 27h. In .EXE programs, the PSP (a 256-byte structure at the base of the allocated block) must be accounted for in size calculations, ensuring the retained memory includes essential headers and code without overlap. These calls do not automatically close open files, requiring manual handling to avoid resource leaks.[64] Many TSRs employ hotkeys for user activation, hooking into keyboard interrupts to detect specific key combinations and pop up interfaces over the current application. For instance, Borland's SideKick utility intercepts interrupt 9h (hardware keyboard) or 16h (BIOS keyboard services) to respond to dual-key presses, such as both Shift keys, launching features like a notepad, calculator, or phone directory without disrupting the foreground task. Similarly, Norton Utilities included TSR components that used keyboard interrupts for rapid access to disk diagnostics or file recovery tools, enhancing productivity in resource-constrained environments.[63] Representative examples of TSRs illustrate their practical roles in extending DOS. The built-in PRINT.COM serves as a print spooler, queuing output to disk via interrupt hooks on DOS file I/O functions (interrupt 21h), allowing applications to continue while printing occurs in the background and consuming about 8-10 KB of memory. Mouse drivers like MOUSE.COM install resident handlers for interrupt 33h (mouse services), enabling cursor control and event polling for graphical applications without reloading. Desk accessories, such as pop-up clocks or text editors, further demonstrate TSR versatility by providing utility overlays activated via hotkeys, often chaining to prior interrupt handlers to maintain system compatibility.[65][63] TSRs impact memory usage by permanently occupying portions of the 640 KB conventional RAM limit, reducing availability for foreground programs and potentially causing out-of-memory errors in memory-intensive setups; for example, multiple TSRs could collectively consume 50-100 KB, leaving less for applications like word processors. They are commonly loaded at boot time by including their executable names in the AUTOEXEC.BAT file, ensuring residency from the start of a session without manual intervention each time.[63] Key limitations stem from DOS's single-tasking architecture, which provides no preemptive multitasking—TSRs must process interrupts quickly and chain to the previous handler to yield control voluntarily, or risk hanging the system if execution time exceeds interrupt latency. Interrupt conflicts arise when multiple TSRs hook the same vector (e.g., keyboard or timer interrupts) without proper chaining, leading to overwritten handlers, missed events, or crashes; resolution requires careful installation order and multiplex checks via interrupt 2Fh to detect and coexist with existing residents.[63]

Software and Development

Key Applications

DOS's ecosystem fostered a diverse array of applications that leveraged its lightweight architecture and widespread adoption on IBM PC compatibles, enabling productivity, entertainment, and data management in the 1980s and early 1990s. Among the most influential were word processors that transformed document creation from typewriters to digital editing. WordStar, initially developed for CP/M in 1979, was ported to MS-DOS with version 3.0 in 1982, becoming one of the first major word processing programs for the platform and achieving dominance by offering features like non-destructive editing and programmable function keys.[66][67] [Microsoft Word](/page/Microsoft Word) 1.0 followed in 1983 as a character-based application for MS-DOS, introducing mouse support for menu navigation and marking a shift toward more intuitive interfaces, though it initially competed against established titles like WordStar.[68][69] Spreadsheets emerged as quintessential business tools under DOS, with Lotus 1-2-3 revolutionizing data analysis upon its release in January 1983. Developed by Lotus Development Corporation, it integrated spreadsheet functions, basic graphics, and database capabilities into a single package, quickly outselling predecessors like VisiCalc and becoming the "killer app" that propelled PC adoption in offices by simplifying complex calculations and reporting.[70][71] Its dominance persisted until Microsoft's Excel gained traction in the late 1980s, but 1-2-3's integrated approach set standards for productivity software.[72] In gaming, DOS supported titles that pushed hardware limits through innovative techniques. Doom, released by id Software in 1993, exemplified this by employing DOS extenders like DOS/4GW to access protected mode memory beyond the 640 KB conventional limit, enabling fast-paced 3D rendering and multiplayer networking on standard PCs.[73][74] This first-person shooter not only popularized the genre but also demonstrated DOS's extensibility for resource-intensive applications, influencing game development for years. Utilities enhanced file handling and storage efficiency in DOS's command-line environment. Norton Commander, introduced in 1986 by developer John Socha and later acquired by Symantec, provided a dual-pane, text-based interface for file management, streamlining operations like copying and viewing without relying on DOS commands alone.[75] PKZIP, launched in 1989 by PKWARE under Phil Katz, standardized file compression with the ZIP format, allowing users to archive and transfer files efficiently across floppy disks and early networks, and it remains a foundational tool for data compression.[76][77] Database management also thrived, with dBase III from Ashton-Tate debuting in 1984 as a relational system for MS-DOS. It expanded on earlier versions by supporting larger datasets, indexed files, and report generation, making it essential for business applications and contributing to Ashton-Tate's status as a leading software firm in the mid-1980s.[78][79] A hallmark of DOS applications was their emphasis on 8086 compatibility to ensure portability across hardware variations and DOS versions from 1.0 to 6.22. Developers targeted the Intel 8086's real-mode architecture, allowing software to run seamlessly on subsequent x86 processors without modification, which sustained the ecosystem's longevity even as computing power evolved.[80][81]

Programming and Development Tools

Programming on DOS relied on a limited set of languages, compilers, and tools tailored to the constraints of 16-bit x86 architecture and the absence of modern operating system abstractions. Early development centered around interpreted and compiled languages that could generate compact executables suitable for the era's memory limitations, typically 640 KB of conventional RAM. Developers often chose tools based on speed of compilation, ease of use, and integration with DOS's interrupt-based system calls. BASIC was a foundational language for DOS programming, with Microsoft GW-BASIC serving as the primary interpreter bundled with MS-DOS versions from 1983 onward.[82] Released in 1983, GW-BASIC provided an interactive environment for beginners, supporting structured programming elements like subroutines and graphics via direct hardware access, though it lacked advanced features such as modules.[83] For more efficient code, C became popular through Borland's Turbo C compiler, introduced in 1987, which offered fast compilation times and an integrated editor for creating portable applications.[84] Assembly language programming used Microsoft's Macro Assembler (MASM), a tool for low-level optimization that generated object files from Intel-syntax code, essential for system-level software like device drivers.[85] Integrated Development Environments (IDEs) streamlined the process by combining editors, compilers, and basic debugging. Borland's Turbo Pascal, launched in 1983, exemplified this approach with its full-screen editor, syntax highlighting, and built-in compiler that produced standalone .EXE files from Pascal source code.[86] This IDE's efficiency—compiling a simple program in seconds—made it a staple for rapid prototyping, though it required careful management of DOS's segmented memory model. Debugging tools were rudimentary but effective for troubleshooting at the machine level. The built-in DEBUG.COM utility, included in MS-DOS since version 1.0, allowed developers to assemble, disassemble, and step through code in real-time using commands like 'A' for assembly and 'G' for execution.[87] For more sophisticated needs, Borland's Turbo Debugger (TD), released around 1987, provided symbolic debugging, watchpoints, and register inspection, supporting both source-level and assembly views for Turbo C and Pascal programs.[88] Build tools facilitated project management and executable generation. Microsoft's NMAKE utility handled dependency tracking and automated compilation via makefiles, integrating with compilers like CL for C or MASM for assembly to rebuild only modified files.[89] Linking object files (.OBJ) to executables (.EXE) was performed using Microsoft's LINK.EXE, which resolved symbols and supported overlays for larger programs exceeding available memory.[90] These tools emphasized command-line workflows, with no graphical alternatives until later DOS extenders. Access to system services in DOS programming occurred through direct invocation of BIOS and DOS interrupts rather than high-level APIs. For instance, interrupt 21h (INT 21h) served as the primary DOS function dispatcher, with subfunctions like AH=3Dh for opening files enabling basic I/O operations without abstract layers.[91] This low-level approach, while efficient, demanded precise handling of error codes in the carry flag and registers, contrasting sharply with the protected APIs of later systems like Windows.

References

User Avatar
No comments yet.