Jump to content

COM1

From Alfawiki
Adapted from the English Wikipedia article COM1, available under CC BY-SA 4.0Updated 9 August 2025
DOS
Company typeFamily of operating systems
IndustryComputer software
Founded1981
Headquarters
United States
ProductsIBM PC DOS, MS-DOS, DR-DOS, ROM-DOS, PTS-DOS, FreeDOS

DOS (, ) refers to a family of disk-based operating systems designed for IBM PC compatible machines. The core members of this family are IBM PC DOS and Microsoft's MS-DOS, both introduced in 1981. Other compatible variants 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 commonly linked with MS-DOS, DOS is an acronym for disk operating system that is platform-neutral and predates the IBM PC era. Various other operating systems have adopted this term, beginning with the mainframe DOS/360 released in 1966, as well as systems like Apple DOS, Apple ProDOS, Atari DOS, Commodore DOS, TRSDOS, and AmigaDOS.

Origins

IBM PC DOS and its antecedent, 86-DOS, were developed for Intel 8086 16-bit processors. Their design aimed to emulate Digital Research's leading CP/M operating system for 8-bit microcomputers, facilitating easier porting of CP/M software to MS-DOS.

When IBM introduced the IBM PC powered by the Intel 8088 processor, they required an operating system. IBM chairman John Opel was directed to Bill Gates to obtain a CP/M-compatible OS for the 8088. Initially, IBM negotiated with Digital Research, but talks broke down over licensing terms and naming rights. Digital Research’s founder Gary Kildall declined IBM’s conditions, causing IBM to withdraw from the agreement.

Subsequently, IBM turned to Bill Gates, who engaged Seattle Computer Products. Programmer Tim Paterson had created QDOS (Quick and Dirty Operating System), a CP/M-80-inspired OS for testing SCP’s new Intel 8086 CPU card. Microsoft acquired 86-DOS for approximately $50,000 and rebranded it as MS-DOS in 1981. Within one year, Microsoft licensed MS-DOS to more than 70 companies, many of which marketed it under different names—for example, Zenith Data Systems called it Z-DOS. Microsoft later standardized the MS-DOS brand name except for IBM’s version, which continued development as PC DOS.

Digital Research threatened legal action due to IBM selling a similar OS under the CP/M name. In response, IBM offered buyers a choice between PC DOS and CP/M-86, Digital Research's 8086 iteration. CP/M-86 was priced roughly $200 higher than PC DOS and experienced poor sales, resulting in its decline while MS-DOS and PC DOS established dominance across PCs and compatibles.

Initially, Microsoft sold MS-DOS exclusively to original equipment manufacturers (OEMs) because early personal computers were not fully IBM PC compatible. The DOS architecture separated system-specific device drivers (IO.SYS) from the core kernel (MSDOS.SYS), enabling OEMs to customize via an OEM Adaptation Kit (OAK). By the early 1990s, as IBM compatibility became widespread, Microsoft began offering retail versions starting with MS-DOS 5.0.

During the mid-1980s, Microsoft created a multitasking edition called "European MS-DOS 4," primarily licensed in Europe through ICL. This version supported preemptive multitasking, shared memory access, device helper services, and executables in the New Executable ("NE") format—features that influenced the OS/2 1.0 kernel but did not appear in subsequent DOS releases. This should not be confused with IBM’s broadly distributed PC DOS 4.0 based on version 3.3.

Digital Research aimed to reclaim market share lost to MS-DOS by releasing products such as Concurrent DOS, FlexOS, DOS Plus, Multiuser DOS, and DR DOS—all compatible with MS-DOS or CP/M-86 applications. After Novell acquired Digital Research, DR DOS evolved into PalmDOS and Novell DOS; later iterations were marketed by Caldera (OpenDOS), 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." Initially viewed by Microsoft as a temporary solution before launching Xenix—a multi-user UNIX variant designed for upward compatibility with MS-DOS.

IBM preferred not to replace DOS immediately. Following AT&T's commercialization of Unix, Microsoft and IBM collaborated on OS/2 as its successor but eventually diverged due to differing strategies regarding OS/2 and Windows development. This led both companies to continue separate development of their respective DOS versions. The final retail release of MS-DOS was version 6.22; afterwards, MS-DOS was embedded within Windows 95, 98, and Me. The last retail PC DOS version was 2000 (revision 7.1), with subsequent OEM/internal releases such as PC DOS 7.10.

The FreeDOS initiative commenced on June 26, 1994, after Microsoft declared it would discontinue sales and support for MS-DOS. Jim Hall launched an open-source replacement project that rapidly gained contributors including Pat Villani and Tim Norman. By integrating existing code into a kernel, command interpreter (COMMAND.COM), and utilities, several pre-release versions were issued before FreeDOS 1.0 debuted on September 3, 2006. Distributed under the GNU General Public License (GPL), FreeDOS operates without licensing fees or royalties.

Decline

Initial iterations of Microsoft Windows operated atop MS-DOS. By the early 1990s, the Windows graphical interface had become widely embraced. The launch of Windows 95 in 1995 marked a shift as it was introduced as a fully independent OS without the need for a separate DOS license. Alongside Windows 98 and ME, Windows 95 established itself as the standard OS kernel, though MS-DOS persisted primarily for backward compatibility. Unlike Windows ME, both Windows 95 and 98 permitted running the MS-DOS subsystem separately. Since DOS ceased to be critical for Windows functionality, most users gradually stopped interacting with it directly.

Continued use

Currently available DOS-compatible systems include FreeDOS, ROM-DOS, PTS-DOS, RxDOS, and REAL/32. OEMs such as Dell and HP have occasionally shipped computers pre-installed with FreeDOS, although this trend appears less common since 2008. These DOS variants continue to find relevance among developers and engineers who require close hardware-level control.

Embedded systems

The architecture of DOS, which allows direct hardware access, makes it suitable for embedded devices. The latest iterations of DR-DOS maintain a focus on this sector. For example, ROM-DOS functions as the operating system for products like the Canon PowerShot Pro 70 camera.

Emulation

On Linux platforms, DOSEMU provides a native virtual environment enabling DOS applications to run at speeds close to native execution. Other emulators such as DOSBox support running DOS on both Unix and Windows systems. DOSBox primarily targets legacy gaming titles (for instance, King's Quest and Doom) on contemporary hardware and incorporates its own embedded DOS implementation tied to the emulator, while also allowing booting from MS-DOS, FreeDOS, or other DOS-based systems.

Design

MS-DOS and IBM PC DOS are closely linked with Intel x86 or compatible processors within IBM PC-compatible machines. There were also machine-specific MS-DOS variants designed for non-IBM-compatible x86 hardware, ranging from rebranded Microsoft editions to custom adaptations tailored for unique platforms. Applications utilizing DOS APIs could operate across both compatible and incompatible hardware environments. The original FreeDOS kernel—DOS-C—originated from DOS/NT designed for Motorola 68000 CPUs; it mirrored DOS's general structure but lacked binary compatibility due to differing instruction sets, although software written in high-level languages could be adapted.

DOS is a single-user, single-task operating system featuring non-reentrant kernel functions, permitting only one active program at any moment. Its kernel exposes an API supporting character input/output, file and memory management, and process control.

Batch files (.BAT) facilitate shell scripting by processing commands sequentially, including internal commands such as GOTO and conditional logic.

While the OS provides an API tailored for character-mode applications, it does not offer standardized interfaces for most hardware devices (e.g., graphics adapters, printers, mice). Consequently, programs frequently accessed hardware directly, resulting in many applications bundling their own device drivers. Hardware vendors typically released specifications to assist driver development for widely used software.

Boot sequence

  • On PC-compatible machines, the initial stage of booting involves the bootstrap loader located in the master boot record (MBR), which resides in the boot sector—the first sector of the bootable disk. The system's ROM BIOS loads this sector into memory at address : , then verifies a signature "" at offset . If this signature is invalid, it attempts to load from the next physical disk; if valid, control transfers to the loaded code with registers initialized.
  • When the loaded sector is an MBR (on disks with partitions), it relocates itself to address : in memory. The MBR scans the partition table for an active partition and loads that partition’s first sector—the Volume Boot Record (VBR)—into memory at : , then passes execution with appropriate register settings.
  • The sector loaded at : serves as the VBR, which is specific to each OS version and generally incompatible across different DOS releases. Early DOS versions (such as DOS 1.x) loaded the entire IO.SYS or IBMBIO.COM file into memory at : , requiring these files to be stored contiguously on disk. Later releases locate boot files within the root directory and load initial sectors accordingly while preserving the Disk Parameter Table (DPT) before transferring control.
  • In more recent DOS versions, the VBR loads only a few initial sectors of IO.SYS/IBMBIO.COM; this file contains a secondary boot loader that loads the remainder using information from the root directory. Earlier versions bypassed this two-stage process by loading the complete file at once.
  • The system initialization code then loads built-in device drivers along with the DOS kernel (MSDOS.SYS in MS-DOS). In Windows 9x editions, these components are combined into IO.SYS, with MSDOS.SYS functioning as a configuration file.
  • The CONFIG.SYS file is parsed to apply configuration settings; its variable identifies which shell to launch by default—COMMAND.COM if unspecified.
  • The command shell is loaded and executed.
  • Finally, under this shell environment, the startup batch script AUTOEXEC.BAT runs.

DOS system files loaded during boot must be stored contiguously and occupy the first two entries in the FAT directory table. Modifying these files improperly can prevent successful booting. However, replacing COMMAND.COM with an alternative shell can improve startup times when launching dedicated applications. This restriction does not apply to DR DOS systems where system files may reside anywhere within the root directory without contiguity requirements—allowing straightforward copying if supported by the boot sector.

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

From MS-DOS 7.0 onwards, IO.SYS incorporated MSDOS.SYS binaries; MSDOS.SYS became a configuration file similar in role to CONFIG.SYS and AUTOEXEC.BAT. Setting MSDOS.SYS's BootGUI parameter to 0 halts booting after loading COMMAND.COM instead of automatically launching WIN.COM.

File system

DOS utilizes a filesystem that adheres to the 8.3 filename convention, allowing filenames of up to 8 characters and extensions consisting of 3 characters. Starting with DOS version 2, support for hierarchical directories was introduced, also following the 8.3 naming scheme. The maximum path length is limited to 64 characters due to the constraints of the internal current directory structure (CDS) tables. When including the drive letter, DOS can handle fully qualified filenames up to 80 characters in length (formatted as drive:\path\filename.ext).

The underlying filesystem in DOS is based on the File Allocation Table (FAT) architecture. Originally, FAT12 was implemented, which permitted up to 4,078 clusters per volume. With the release of DOS 3.0, FAT16 was introduced, featuring 16-bit entries and enabling support for as many as 65,518 clusters. Later, Compaq MS-DOS 3.31 incorporated FAT16B, removing the former 32 MiB restriction and allowing drives up to 512 MiB in size. Subsequently, MS-DOS 7.1 (included with Windows 9x) added FAT32, which uses 32-bit entries and supports volumes extending beyond 137 GiB.

Beginning with DOS 3.1, file redirectors were supported, facilitating networking capabilities and later enabling access to CD-ROM drives through MSCDEX. IBM PC DOS version 4.0 offered early support for installable file systems (IFS), though this feature was discontinued by DOS 5.0. Additionally, DOS could load Block Devices via CONFIG.SYS to integrate network hardware into its filesystem environment.

Drive naming scheme

In DOS, drive identification is managed through alphabetical letters. The letters "A" and "B" are traditionally reserved for floppy drives; if only a single floppy drive is present, both letters are assigned to it to simplify disk swapping during operations. Hard disks typically begin with letters "C" and "D". DOS assigns drive letters primarily to one active partition per physical disk: first to each drive’s active primary partition, followed by logical drives within extended partitions, then any inactive primary partitions formatted with supported filesystems. Afterward, letters are allocated to optical disc drives, RAM disks, and other devices.

The order of letter assignments generally reflects the sequence in which device drivers are loaded but can be customized by drivers themselves—for example, network drives often receive letters toward the end of the alphabet.

Since DOS applications reference drives directly via their letters rather than device paths like Unix’s /dev system, adding new hardware can disrupt existing letter assignments. For instance, introducing a new hard disk containing a primary partition might claim a letter previously assigned to logical partitions on another disk, potentially affecting RAM disks and optical drives as well. This issue persisted throughout Microsoft’s DOS-based Windows 9x series but was resolved in NT-based Windows versions that maintain drive letter consistency unless manually changed by users.

Within DOS environments, this problem can be alleviated by using SUBST commands to create virtual drives and installing software there; batch scripts can be employed at startup to manage these assignments dynamically. Certain multitasking DOS variants such as Concurrent DOS, Multiuser DOS, System Manager, and REAL/32 automatically map the reserved letter L: to the relevant load drive upon application launch.

Reserved device names

DOS reserves specific 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 editions and have occasionally led to system instability or security issues.

The reserved device names include:

  • COM1 through COM9 (serial communication ports)
  • LPT1 through LPT9 (parallel printer ports)
  • CON (console input/output)
  • AUX (auxiliary device, usually mapped to COM1)
  • PRN (printer device, typically LPT1)
  • NUL (null device)

In Windows 95 and 98, attempts to use these names within file paths could cause system crashes; Microsoft released patches addressing these vulnerabilities. In Windows XP, such usage results in silent fallback behavior without alerting users, whereas Vista and subsequent versions display error messages when these names are used improperly.

These reserved identifiers—except for NUL—have been consistently supported throughout MS-DOS, PC DOS, and DR-DOS releases. Some OEM versions of MS-DOS included additional aliases like LST or PLT for specific hardware devices. Over time, DOS expanded support for multiple ports (COM2, LPT2, etc.) and introduced special devices such as CLOCK$, KEYBD$, along with power management idle devices in multitasking environments.

Default mappings may vary; for example, while AUX normally corresponds to COM1, certain DOS implementations allow reassignment to alternative serial or parallel interfaces.

By convention, device names are followed by a colon (e.g., NUL:) when referenced as devices; however, the colon itself is not part of the device name and is often optional.

Although standard file operations prohibit creating files or directories with these reserved names, it remains technically feasible through direct disk editing methods. Such techniques have occasionally been exploited by malware authors seeking to conceal files from standard user access methods.

Memory management

DOS was initially developed for the Intel 8088 CPU, which had direct addressing capabilities for up to 1 MiB of RAM. Both IBM and Microsoft designated 640 KiB for application use, while reserving the remaining 384 KiB for video memory, adapter ROMs, and BIOS functions. By the mid-1980s, certain software began to encounter this memory ceiling, although a significant portion of the reserved space often remained unused depending on the hardware configuration.

To increase available memory, standards such as the Expanded Memory Specification (EMS) enabled programs to access extra memory through a 64 KiB page frame located in upper memory. With the introduction of 80386 processors, virtual 8086 mode managers like EMM386 allowed expanded memory to be simulated from extended memory without requiring additional hardware. The Extended Memory Specification (XMS) facilitated access to memory beyond 1 MiB on systems with 80286 or newer processors, including both the high memory area (HMA) immediately above 1 MiB and upper memory blocks. Support for XMS was commonly provided by drivers like HIMEM.SYS or through virtual 8086 mode managers such as QEMM or 386MAX.

Beginning with DOS version 5, users could load the operating system kernel and disk caching buffers into the HMA by adding the DOS=HIGH command in CONFIG.SYS. Additionally, enabling DOS=UMB allowed DOS to utilize upper memory blocks, thereby enhancing overall memory management efficiency.

DOS under OS/2 and Windows

DOS emulation within OS/2 and Windows environments functions similarly to native applications, granting access to drives, system services, and clipboard operations. Since file system drivers reside in the host operating system, DOS emulation layers convert DOS API requests into equivalent OS/2 or Windows system calls while also virtualizing BIOS interrupts and common input/output port interactions.

In Windows versions 3.1 and 9x, the virtual DOS machine is controlled by WINOLDAP. This component constructs a virtualized environment based on program information files (PIF) and current system conditions. It supports running DOS graphics modes within windows and incorporates clipboard integration.

OS/2’s approach to DOS emulation uses DOSKRNL, which merges functionalities of IBMBIO.COM and IBMDOS.COM while forwarding system calls to native OS/2 services. DOS applications execute within isolated sessions, supplemented by utilities combining DOS and OS/2 features. OS/2 can also run Windows 3.1 applications through a customized Windows version called Win-OS/2, allowing either seamless integration with OS/2 or operation in a distinct desktop environment.

Furthermore, OS/2 provides the capability to boot a genuine DOS environment from a floppy disk image (VMDISK), delivering direct hardware access via its own drivers—particularly valuable for unsupported devices such as certain CD-ROM drives.

All 32-bit editions of Windows NT released since 1993 include DOS emulation via the virtual DOS machine (NTVDM). However, this support is absent from 64-bit Windows versions, which cannot natively execute 16-bit DOS programs; users typically rely on third-party solutions like DOSBox in those cases.

User interface

DOS systems operate through a command-line interface, where users launch software by typing executable filenames at a prompt. The environment includes both internal commands and external utility programs beyond standalone applications.

To improve user experience, various software developers introduced file management tools featuring WIMP-style graphical interfaces. Microsoft Windows notably evolved into a comprehensive program loader, with Windows 9x supplanting DOS as the primary PC-compatible loader. Among popular text-based user interfaces were Norton Commander, DOS Navigator, and Volkov Commander, while graphical alternatives included Digital Research’s GEM and GEOS.

Leading DOS vendors eventually incorporated environment managers: MS-DOS and IBM DOS version 4 introduced DOS Shell, whereas DR DOS version 5.0 included ViewMAX, which was based on GEM technology.

Terminate and stay resident

While DOS does not provide genuine multitasking capabilities, it supports terminate-and-stay-resident (TSR) programs that remain loaded in memory to perform background functions or be activated on demand. This mechanism facilitates rudimentary multitasking tailored to specific applications—for example, the DOS PRINT utility relies on TSR for background print spooling, and Borland Sidekick utilizes it as a popup personal information manager.

TSR programs also serve to augment DOS features—tools such as CED and DOSKEY improve command-line editing, whereas Microsoft CD-ROM Extensions (MSCDEX) allow access to CD-ROM drives.

Certain TSRs provide limited task-switching abilities; for instance, the shareware application Back and Forth (1990) enables saving a program’s state to disk and toggling between different software, albeit without true background execution—functionality that was otherwise achieved through solutions like DESQview on Intel 386 CPUs.

Software

Development tools

  • BASIC interpreters: BASICA and GW-BASIC
  • DJGPP, a 32-bit DPMI-compliant port of the GNU Compiler Collection (gcc) for DOS
  • Microsoft development utilities: Macro Assembler, C compiler, and CodeView debugger
  • Watcom C/C++, development suite from Watcom
  • Borland’s Turbo series: Pascal, BASIC, C, Prolog, and Assembler compilers

See also

Further reading

  • IBM Corp., (January 1984). "IBM DOS Release 2.10 Cloth bound retail hard board box". First edition. IBM Corp. Item Number 6183946
  • IBM Corp., (January 1984). "Disk Operating System User's guide (DOS Release 2.10)". First edition. Microsoft Corp. Item Number 6183947
  • IBM Corp., (January 1984). "Disk Operating System Manual (DOS Release 2.10)". First edition. Microsoft Corp. Item No. 6183940
  • Mueller, Scott. Upgrading and Repairing PCs, Eighth Edition, Que Publishing, 1998, ISBN 0-7897-1295-4
  • Bailes, Lenny & Mueller, John. Memory Management and Multitasking Beyond 640K, McGraw-Hill, 1992, ISBN 0-8306-3476-2

External links

Related profiles

CCLOCK$CCOM2CCOM3LLPT3
Retrieved from "https://www.alfawiki.org/index.php?title=COM1&oldid=29029"