Jump to content

COM3

From Alfawiki
Adapted from the English Wikipedia article COM3, available under CC BY-SA 4.0Updated 9 August 2025
DOS
Company typeOperating system family
IndustryComputer software
Founded1981
Headquarters
United States
ProductsIBM PC DOS, MS-DOS, DR-DOS, ROM-DOS, PTS-DOS, FreeDOS

DOS (, ) refers to a collection of disk-based operating systems designed for IBM PC compatible machines. The core members of this family are IBM PC DOS and its rebranded counterpart, Microsoft's MS-DOS, both introduced in 1981. Subsequent compatible versions include DR-DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1994). MS-DOS maintained a dominant position in the IBM PC compatible market from 1981 until 1995.

Although "DOS" is frequently associated with MS-DOS, it stands for disk operating system, a generic term used independently of any platform before the IBM PC's debut. Other significant DOS variants encompass mainframe systems like DOS/360 and successors, as well as Apple DOS, Apple ProDOS, Atari DOS, Commodore DOS, TRSDOS, and AmigaDOS.

Origins

IBM PC DOS and its antecedent, 86-DOS, were designed for Intel 8086 16-bit processors. Their development aimed to mimic Digital Research’s leading CP/M OS for 8-bit microcomputers, facilitating the transition of CP/M applications to MS-DOS.

When IBM launched the IBM PC featuring the Intel 8088 CPU, they required an operating system. IBM Chairman John Opel was directed to Bill Gates to obtain a CP/M-compatible OS for the 8088 processor. However, negotiations with Digital Research faltered due to disagreements over licensing and branding, prompting IBM to withdraw.

Following this, IBM turned to Bill Gates, who had acquired Seattle Computer Products’ QDOS (Quick and Dirty Operating System), created by Tim Paterson as a CP/M-like OS for the Intel 8086. Microsoft reportedly purchased QDOS for $50,000 and rebranded it as MS-DOS in 1981.

Within twelve months, Microsoft licensed MS-DOS to more than 70 firms, allowing them to distribute operating systems under their own brand names, such as Zenith Data Systems’ Z-DOS. Microsoft later required the use of the MS-DOS name except for IBM’s version, called PC DOS. In response, Digital Research released CP/M-86 alongside PC DOS; however, CP/M-86 was priced higher and experienced weaker sales. Consequently, MS-DOS and PC DOS became the prevailing operating systems for PCs and compatibles.

Initially available only to original equipment manufacturers (OEMs), MS-DOS provided customization options through an OEM Adaptation Kit that separated device drivers (IO.SYS) from the core system (MSDOS.SYS). By the early 1990s, as PC compatibility became standardized, Microsoft began retail sales starting with MS-DOS version 5.0.

In the mid-1980s, Microsoft developed a multitasking iteration of DOS—known as "European MS-DOS 4"—for International Computers Limited (ICL) and other European companies. This version included preemptive multitasking, shared memory management, device helper services, and support for the New Executable ("NE") format. These innovations influenced the kernel of OS/2 version 1.0 but were not incorporated into subsequent DOS releases. This variant is distinct from IBM’s widely distributed PC DOS 4.0 based on DOS 3.3.

Digital Research sought to reclaim market share with products such as Concurrent DOS, FlexOS, DOS Plus, Multiuser DOS, and DR DOS—all compatible with MS-DOS applications. After Novell acquired Digital Research, DR DOS evolved through PalmDOS and Novell DOS; later ownership passed through Caldera (OpenDOS/DR-DOS), Lineo, and DeviceLogics.

In 1995, Gordon Letwin remarked that "DOS was... a one-time throw-away product intended to keep IBM happy so that they'd buy our languages." Microsoft originally considered DOS a temporary solution until launching Xenix—a multi-user Unix-like OS intended to maintain upward compatibility with MS-DOS across various CPU platforms.

Nevertheless, IBM preferred retaining DOS. After AT&T began marketing Unix systems, Microsoft and IBM collaborated on OS/2 as a potential successor but eventually diverged due to conflicting visions over whether OS/2 or Windows would be the future platform. This disagreement resulted in separate development tracks for their respective DOS variants.

The final standalone retail version of MS-DOS was 6.22; later iterations were integrated into Windows versions 95, 98, and Me. IBM’s last retail PC DOS release was version 2000 (revision 7.1), with subsequent versions produced internally for OEMs such as PC DOS 7.10.

The FreeDOS initiative commenced in June 1994 after Microsoft discontinued sales and support of MS-DOS. Jim Hall founded this open-source alternative project; he was joined by developers including Pat Villani and Tim Norman. They collaboratively created a kernel, COMMAND.COM shell, and essential utilities by combining existing codebases. FreeDOS officially reached version 1.0 in September 2006 under the GNU General Public License (GPL), providing a free substitute compatible with legacy software environments.

Decline

Initial iterations of Microsoft Windows operated atop MS-DOS. By the early 1990s, the graphical interface of Windows had become widely adopted. The 1995 launch of Windows 95 marked its debut as an independent operating system, removing the necessity for a separate DOS license. Windows 95, along with Windows 98 and ME, served as the primary OS kernel, although MS-DOS was retained for backward compatibility. Notably, with Windows 95 and 98 (but excluding ME), the MS-DOS portion could function independently from Windows. Since DOS was no longer essential for running Windows, most users stopped interacting with it directly.

Continued use

As of , several DOS-compatible operating systems remain available, including FreeDOS, ROM-DOS, PTS-DOS, RxDOS, and REAL/32. Some hardware vendors like Dell and HP have offered systems pre-installed with FreeDOS as an OEM option. Although Dell seems to have ceased FreeDOS preloads since 2008, FreeDOS and comparable platforms continue to be favored by developers and engineers who require direct hardware-level control.

Embedded systems

Due to its capability for direct hardware interaction, DOS finds application in embedded devices. The most recent versions of DR-DOS specifically target this sector. For instance, ROM-DOS is utilized as the operating system in devices such as the Canon PowerShot Pro 70 camera.

Emulation

On Linux systems, DOSEMU enables near-native performance when running DOS applications. Other emulators like DOSBox allow DOS programs to operate on Unix and Windows environments. DOSBox is primarily designed to support classic games (e.g., King's Quest, Doom) on modern machines. It features its own integrated DOS environment tied to the emulator but also supports booting MS-DOS, FreeDOS, or other DOS variants if required.

Design

MS-DOS and IBM PC DOS were developed mainly for Intel x86 processors or compatible CPUs, predominantly targeting IBM PC compatibles. Machine-specific MS-DOS editions existed for non-IBM-compatible x86 hardware, ranging from rebranded Microsoft versions to customized builds tailored for specialized equipment. Applications using DOS APIs could operate on both compatible and incompatible systems. The original FreeDOS kernel, known as DOS-C, originated from DOS/NT designed for Motorola 68000 processors; however, it lacked binary compatibility due to differing CPU instruction sets, though applications written in high-level languages could be ported with relative ease.

As a single-user, single-tasking operating system with non-reentrant kernel functions, DOS permits only one program to run at any given moment. Its kernel exposes an API facilitating character input/output, file and memory management, program loading, and termination.

Batch files (.BAT) provide scripting capabilities by interpreting each line as a command or executable instruction, supporting internal commands such as GOTO and conditional branching.

While DOS offers an API suitable for character-mode applications, it does not standardize access to most hardware components (such as graphics adapters, printers, or mice). Consequently, software often accessed hardware directly, necessitating unique device drivers per application and peripheral device. Hardware manufacturers published technical specifications to aid driver development for popular software titles.

Boot sequence

  • On PC-compatible machines, the initial stage involves the bootstrap loader located in the master boot record (MBR) at the boot disk’s first sector (boot sector). The system’s ROM BIOS loads this sector into memory at address : and verifies a signature "" at offset . If this signature is invalid, it attempts to read from subsequent physical disks; if valid, execution jumps to the load address with registers configured accordingly.
  • When the loaded sector is identified as an MBR, it relocates itself to : in memory. The MBR then examines its partition table to find an active partition and loads that partition’s first sector—the Volume Boot Record (VBR)—into memory at :, transferring control thereafter.
  • The VBR is specific to the operating system and typically cannot be interchanged among different DOS versions. Early DOS releases (e.g., DOS 1.x) loaded the entire IO.SYS/IBMBIO.COM file into memory at :, requiring these sectors to be stored contiguously on disk. Later editions retrieve root directory entries into memory to load initial IO.SYS/IBMBIO.COM sectors while preserving the Disk Parameter Table, then transfer control with registers set.
  • In more recent DOS variants, the partial IO.SYS/IBMBIO.COM loaded by the VBR contains a secondary loader that completes loading itself using root directory information; earlier versions bypass this by loading the full file initially.
  • Following this, DOS system initialization loads built-in device drivers along with the kernel (MSDOS.SYS in MS-DOS). In Windows 9x editions, these components are merged into IO.SYS while MSDOS.SYS functions as a configuration file.
  • The CONFIG.SYS configuration file is parsed for parameters; its variable defines the shell’s location—defaulting to COMMAND.COM.
  • Subsequently, the shell is loaded and executed before running the startup batch script AUTOEXEC.BAT.

System files loaded by the boot sector must be stored contiguously and occupy the first two entries in the FAT directory table. Modifying these files by adding or removing them can render media unbootable. However, substituting the shell can improve startup speed by launching dedicated applications directly. This restriction does not apply to DR DOS systems where system files may reside anywhere within the root directory if the boot sector supports DR DOS.

In PC DOS and DR DOS version 5.0 and later, system files are named IBMBIO.COM instead of IO.SYS, and IBMDOS.COM replaces MSDOS.SYS. Earlier DR DOS releases used DRBIOS.SYS and DRBDOS.SYS respectively.

Beginning with MS-DOS 7.0, IO.SYS and MSDOS.SYS were combined into a single IO.SYS executable; MSDOS.SYS was repurposed as a configuration file akin to CONFIG.SYS and AUTOEXEC.BAT. Setting the MSDOS.SYS BootGUI directive to 0 halts booting after loading the command interpreter (typically COMMAND.COM), preventing automatic launching of WIN.COM.

File system

DOS utilizes a filesystem that supports 8.3 filename conventions, where filenames consist of up to 8 characters and extensions up to 3 characters. Starting with DOS 2, hierarchical directory structures became available, with each directory name also adhering to the 8.3 format. Due to the internal current directory structure (CDS) tables, the maximum length for a directory path is limited to 64 characters. When including the drive letter, the longest possible fully qualified filename can reach 80 characters in the format drive:\path\filename.ext.

The filesystem used by DOS is based on the File Allocation Table (FAT) system. The initial FAT12 variant supported a maximum of 4,078 clusters per volume. With the release of DOS 3.0, FAT16 was introduced, which employed 16-bit allocation entries and allowed up to 65,518 clusters. Later, Compaq MS-DOS 3.31 implemented FAT16B, lifting the previous 32 MiB volume size limit and enabling support for drives as large as 512 MiB. Subsequently, MS-DOS 7.1 (included in Windows 9x) brought in FAT32, featuring 32-bit entries and compatibility with drives exceeding 137 GiB.

Beginning with DOS version 3.1, support for file redirectors was added initially to enable network functionality and later extended to CD-ROM drives via MSCDEX. IBM PC DOS 4.0 introduced early installable file system (IFS) capabilities; however, these were removed in DOS 5.0. Additionally, DOS allowed loading Block Devices through CONFIG.SYS to enhance file system operations for networked devices.

Drive naming scheme

In DOS environments, drives are designated by letters. The letters "A" and "B" are traditionally reserved for floppy drives. On systems equipped with a single floppy drive, both letters might be assigned to it to facilitate disk swapping during tasks such as copying or executing programs that require separate data disks. Initially, hard drives were assigned letters starting from "C" and "D". DOS supports only one active partition per physical drive; drive letters are allocated first to each drive’s active primary partition, then to logical drives within extended partitions, followed by inactive primary partitions if any exist, and finally to optical drives, RAM disks, and other devices.

The assignment of drive letters generally follows the order in which drivers are loaded but can be influenced by specific drivers—for instance, network drivers often allocate letters near the end of the alphabet.

Since DOS applications access drives directly via letter identifiers (unlike Unix-like systems using /dev paths), adding new hardware can cause existing drive letter assignments to shift. For example, introducing a new hard disk’s primary partition may claim a letter previously assigned to logical drives on another disk, thereby affecting RAM disks and optical drives as well. This challenge persisted throughout Microsoft’s DOS-based Windows 9x releases until NT-based Windows versions were introduced, which maintain consistent drive letter assignments unless manually altered by users.

Some solutions include defining SUBST drives or utilizing reserved letters such as L: in certain multitasking DOS variants (Concurrent DOS, Multiuser DOS, System Manager, REAL/32), where L: is automatically allocated to the load drive when launching applications.

Reserved device names

DOS reserves several device names that cannot be used as filenames regardless of their extensions because they correspond to built-in character devices. These restrictions continue across various Windows versions and have occasionally led to system crashes or security vulnerabilities.

The list of reserved names includes:

  • COM1 through COM9 (serial ports)
  • LPT1 through LPT9 (printer parallel ports)
  • CON (console input/output)
  • AUX (the first serial port)
  • PRN (the first parallel port)
  • NUL (null device)

In Windows 95 and 98, attempting to use these reserved names within file paths could cause system crashes; Microsoft released patches addressing these issues. Windows XP silently reverts such filenames back without notifying errors. From Windows Vista onward, attempts to use these reserved names result in explicit error messages.

Apart from NUL, these device names remain recognized in MS-DOS, PC DOS, and DR-DOS variants. Certain OEM MS-DOS versions introduced additional aliases like LST and PLT. Specific DOS implementations also included devices such as CLOCK$, KEYBD$, and SCREEN$. DR-DOS added unique devices like $IDLE$, intended for power management and multitasking purposes.

By default, AUX maps to COM1, while PRN corresponds to LPT1, although some DOS versions allow remapping these designations to other serial or parallel hardware.

Device names are often suffixed with a colon (e.g., NUL:) when referenced as devices; this colon indicates device status but is not part of the actual device name and is optional in command usage.

Despite operating system restrictions, it remains possible—through direct disk editing—to create files or directories bearing these reserved names. Such methods have been exploited by malware authors aiming to conceal files from standard user interfaces.

Memory management

DOS was originally developed for the Intel 8088 CPU, which had direct access to a maximum of 1 MiB of RAM. IBM and Microsoft allocated 640 kibibytes (KiB) for application use, reserving the remaining 384 KiB for video memory, adapter ROMs, and BIOS functions. By the mid-1980s, certain DOS programs reached this memory ceiling, although a significant portion of the reserved space often remained unused depending on the hardware configuration.

To address these limitations, new memory access standards were introduced. The Expanded Memory Specification (EMS) allowed additional memory on expansion cards to be accessed through a 64 KiB page frame located in upper memory. Computers equipped with 80386 or newer processors could utilize virtual 8086 mode (V86) managers such as EMM386 to simulate expanded memory from extended memory without requiring physical add-on cards. The Extended Memory Specification (XMS), designed for 80286 and later systems, facilitated data transfers between conventional and extended memory and enabled access to the high memory area (HMA) above 1 MiB as well as upper memory blocks. Support for XMS was commonly provided by drivers like HIMEM.SYS or through V86 mode managers including QEMM and 386MAX, which also offered EMS compatibility.

Starting with DOS version 5, it became possible to load the operating system’s kernel and disk buffers into the HMA by adding DOS=HIGH in CONFIG.SYS, while DOS=UMB allowed utilization of upper memory blocks.

DOS under OS/2 and Windows

DOS emulation within OS/2 and Windows operates similarly to native applications by accessing drives, services, and clipboard functionality via a translation layer that converts DOS system calls into those of OS/2 or Windows. This layer also virtualizes BIOS interrupts and common I/O port operations.

In Windows versions 3.1 and 9x, DOS runs inside a virtual machine provided by WINOLDAP, which establishes an environment based on program information files (PIFs) and captures the system state at startup. This VM supports DOS graphics modes and clipboard sharing.

DOS emulation on OS/2 and Windows NT is built upon DOS version 5. Users can specify alternate config.sys and autoexec.bat files per session, enabling loading of third-party drivers to access host system resources.

From OS/2 version 2.x onward, DOS functionality is managed by DOSKRNL, which merges the roles of IBMBIO.COM and IBMDOS.COM with OS/2’s windowing capabilities. DOS applications run in isolated sessions with utilities accessible through combined DOS/OS2 programs located in \OS2. Additionally, OS/2 can run Windows 3.1 applications through Win-OS/2, offering either seamless integration or operation within a separate desktop environment.

OS/2 also supports booting a genuine DOS environment (such as MS-DOS 6.22) from a floppy disk image enhanced with OS/2 drivers like VMDISK, granting full hardware control including access to CD-ROM drives not supported by native OS/2 drivers.

Since 1993, all 32-bit editions of Windows NT include DOS emulation via the virtual DOS machine (NTVDM). However, 64-bit versions of Windows lack NTVDM support and therefore cannot run 16-bit DOS programs natively; users must rely on third-party emulators such as DOSbox for compatibility.

User interface

DOS environments primarily operate through a command-line interface, where users launch applications by typing their filenames at the prompt. The system includes both internal commands integrated into the shell and external utility programs.

To improve user experience, various software vendors created file management utilities featuring WIMP-style interfaces. Microsoft Windows evolved into a comprehensive program loader that ultimately replaced DOS as the dominant PC-compatible loader. Well-known text-based user interface tools included Norton Commander, DOS Navigator, Volkov Commander, Quarterdeck’s DESQview, and Sidekick. Graphical interfaces were offered by Digital Research’s GEM and GEOS.

Leading DOS providers later incorporated their own environment managers: MS-DOS/IBM DOS version 4 introduced DOS Shell, while DR DOS 5.0 featured ViewMAX, which was derived from GEM.

Terminate and Stay Resident Programs

While DOS does not inherently support multitasking, it allows for terminate-and-stay-resident (TSR) applications that remain loaded in memory to carry out background functions or be activated as needed, thereby providing a form of limited multitasking. For instance, the DOS PRINT utility leverages TSR technology to handle print spooling, and Borland Sidekick, a pop-up personal information manager, utilizes this approach.

TSRs enhance the capabilities of DOS by introducing additional features such as improved command-line editing tools (like CED and DOSKEY) or enabling CD-ROM drive access through Microsoft CD-ROM Extensions (MSCDEX).

Certain TSR programs provide basic task-switching abilities. The shareware application Back and Forth (1990) permits users to save the state of the active program to disk, open another application, and toggle between them—although this process is slow due to reliance on disk operations. Genuine background multitasking on DOS required specialized software such as DESQview running on an 386 CPU.

Software

Development Tools

See also

Further Reading

  • IBM Corp., IBM, (January 1984). "IBM DOS Release 2.10 Cloth bound retail hard board box". First edition. IBM Corp. Item Number: 6183946
  • IBM Corp., IBM, (January 1984). "Disk Operating System User's Guide (DOS Release 2.10)". First edition. Microsoft Corp. (100 pages with color illustrations) Item Number: 6183947
  • IBM Corp., IBM, (January 1984). "Disk Operating System Manual (DOS Release 2.10)". First edition. Microsoft Corp. (574 looseleaf pages in three-ring binder) Item Number: 6183940
  • Mueller, Scott. Upgrading and Repairing PCs, Eighth Edition, Que Publishing, 1998.
  • Bailes, Lenny and Mueller, John. Memory Management and Multitasking Beyond 640K, McGraw-Hill, 1992.

External links

Related profiles

CCOM1CCLOCK$CCOM2LLPT3
Retrieved from "https://www.alfawiki.org/index.php?title=COM3&oldid=29037"