Jump to content

COM2

From Alfawiki
Adapted from the English Wikipedia article COM2, 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 include IBM PC DOS and its rebranded counterpart, Microsoft's MS-DOS, both launched in 1981. Subsequent compatible variants encompass DR-DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1994). MS-DOS maintained a leading position in the IBM PC compatible operating system market from 1981 until 1995.

While MS-DOS is often synonymous with DOS, the term itself is an acronym for disk operating system that predates the IBM PC era and applies broadly across platforms. Various other operating systems have employed this acronym, including the mainframe-oriented DOS/360 dating back to 1966, as well as Apple DOS, Atari DOS, and AmigaDOS.

Origins

IBM PC DOS and its antecedent, 86-DOS, were developed for Intel 8086 16-bit CPUs. Designed to mirror Digital Research's CP/M, which was the leading OS for 8-bit microcomputers, this resemblance facilitated easier porting of CP/M applications onto MS-DOS.

When IBM unveiled the IBM PC equipped with the Intel 8088 processor, they required an operating system. Initially, IBM approached Digital Research to license CP/M; however, negotiations broke down over licensing conditions and naming rights. Digital Research founder Gary Kildall declined IBM's terms, prompting IBM to withdraw from discussions.

Subsequently, IBM engaged Bill Gates, who had acquired a CP/M-like system from Tim Paterson at Seattle Computer Products. This OS, originally called QDOS (Quick and Dirty Operating System), was commercialized as 86-DOS. Microsoft acquired it for about and introduced MS-DOS in 1981.

Within twelve months, Microsoft licensed MS-DOS to more than 70 hardware manufacturers—often marketed under different brand names such as Zenith Data Systems' Z-DOS. Microsoft later standardized the MS-DOS branding except for IBM's version, which remained as PC DOS. Digital Research countered by releasing CP/M-86 alongside PC DOS; however, its higher cost limited adoption. As a result, MS-DOS and PC DOS emerged as the prevailing operating systems for personal computers.

Initially, Microsoft sold MS-DOS exclusively to original equipment manufacturers (OEMs) due to hardware diversity among early PCs. The operating system architecture separated device-specific drivers (IO.SYS) from the core kernel (MSDOS.SYS), enabling OEM customization through an OEM Adaptation Kit (OAK). By the early 1990s, hardware standardization allowed Microsoft to offer retail versions starting with MS-DOS 5.0.

During the mid-1980s, Microsoft developed a multitasking edition of DOS ("European MS-DOS 4") primarily licensed in Europe. This version featured preemptive multitasking, shared memory support, device helper services, and executables in the New Executable ("NE") format—technologies that contributed to the foundation of the OS/2 1.0 kernel but were omitted from subsequent DOS releases. This contrasts with IBM's broadly distributed PC DOS 4.0 based on DOS 3.3.

Digital Research sought to reclaim market presence through products like Concurrent DOS, FlexOS, Multiuser DOS, and DR DOS—all compatible with MS-DOS and CP/M-86 software. Following acquisition by Novell, DR DOS advanced via PalmDOS and Novell DOS; later stewardship passed to Caldera (OpenDOS/DR-DOS), Lineo, and DeviceLogics.

In 1995, Gordon Letwin remarked that DOS began as a "one-time throw-away product" designed merely to satisfy IBM while Microsoft concentrated on developing Xenix—a multi-user Unix-like operating system intended as a successor to DOS across diverse processors.

IBM preferred maintaining DOS while AT&T marketed Unix; consequently, Microsoft and IBM collaborated on OS/2 as an alternative platform. Divergences regarding OS/2 and Windows development led to separate trajectories for their respective DOS systems. The final standalone retail release of MS-DOS was version 6.22 before it became integrated into Windows 95/98/Me; IBM's last retail edition was PC DOS 2000.

The FreeDOS initiative commenced in June 1994 after Microsoft discontinued sales and support for MS-DOS. Jim Hall spearheaded efforts to create an open-source substitute under the GNU General Public License (GPL). Contributors combined resources to develop a kernel, COMMAND.COM shell, and essential utilities. FreeDOS achieved version 1.0 in September 2006 and continues as royalty-free software widely utilized in embedded environments and legacy system maintenance.

Decline

Initial editions of Microsoft Windows operated atop MS-DOS. By the early 1990s, the graphical interface of Windows had become widely embraced. The release of Windows 95 in 1995 marked its debut as an independent operating system, removing the necessity for a separate DOS license. Windows 95, followed by Windows 98 and ME, served as the primary OS kernel, although MS-DOS was retained for backward compatibility. Unlike Windows ME, the MS-DOS component in Windows 95 and 98 could function separately from the graphical environment. As DOS ceased to be essential, direct user interaction with it declined considerably.

Continued use

Currently, compatible alternatives include FreeDOS, ROM-DOS, PTS-DOS, RxDOS, and REAL/32. Certain manufacturers like Dell and HP have supplied computers with FreeDOS pre-installed as an OEM operating system. While Dell appears to have halted FreeDOS-based systems since 2008, some developers and engineers still rely on DOS platforms due to their capability for low-level hardware manipulation.

Embedded systems

The architecture of DOS, which allows direct hardware communication, makes it suitable for use in embedded devices. The latest DR-DOS releases specifically target this sector. For instance, ROM-DOS operates within devices such as the Canon PowerShot Pro 70.

Emulation

On Linux, DOSEMU facilitates running DOS applications at speeds close to native performance. Additional emulators like DOSBox enable DOS usage on Unix and Microsoft Windows. DOSBox primarily caters to classic gaming titles (for example, King's Quest and Doom) on contemporary operating systems. It incorporates its own DOS environment integrated with the emulator but can also boot MS-DOS, FreeDOS, or other DOS variants when necessary.

Design

MS-DOS and IBM PC DOS are predominantly associated with systems powered by Intel x86 or compatible processors, especially IBM PC compatible machines. There were machine-specific MS-DOS variants for non-IBM-compatible x86 hardware, ranging from Microsoft-branded distributions to customized versions tailored for specialized equipment. Programs utilizing DOS APIs were capable of running on both compatible and incompatible platforms. The original kernel of FreeDOS, known as DOS-C, originated from DOS/NT designed for Motorola 68000 CPUs; although it lacked binary compatibility due to different instruction sets, it facilitated easier porting of high-level language software.

As a single-user, single-tasking system with a non-reentrant kernel, DOS permits only one program to execute at any moment. Its kernel exposes an API that supports character input/output operations, file and memory management, as well as program loading and termination.

Shell scripting is enabled through batch files (.BAT), which interpret each line sequentially as a command or program invocation and support internal commands such as GOTO alongside conditional logic.

While the OS API accommodates development of character-based applications, it does not provide direct control over most hardware components like graphics adapters, printers, or pointing devices. Consequently, software developers often implemented direct hardware access within their programs by including device drivers specific to peripherals. Hardware vendors supplied documentation to assist in creating drivers compatible with widely used applications.

Boot sequence

  • On PC-compatible systems, the bootstrap loader resides in the master boot record (MBR), located at the boot disk's first sector, known as the boot sector. The ROM BIOS loads this sector into memory at address :, then verifies a signature "" at offset . If the signature is absent or incorrect, the BIOS attempts to boot from the next available disk; if valid, it transfers execution to the loaded code with registers appropriately initialized.
  • When the loaded sector is an MBR on a partitioned disk, it relocates itself to : and examines the partition table to identify an active partition. It then loads that partition's initial sector—the Volume Boot Record (VBR)—into memory at : and hands over control.
  • The VBR contains OS-specific code and typically varies between DOS versions. Early DOS releases (such as DOS 1.x) directly loaded the entire IO.SYS/IBMBIO.COM file into memory, mandating that these files occupy contiguous sectors on disk. Later editions locate boot files by referencing root directory entries and load their initial sectors accordingly, preserving the Disk Parameter Table (DPT) before passing control.
  • In more recent DOS versions, only the first sectors of IO.SYS/IBMBIO.COM are loaded by the VBR; this segment includes a secondary loader that completes loading based on root directory information. Older DOS versions bypass this two-step process by loading the complete file immediately.
  • System initialization in DOS subsequently loads built-in device drivers alongside the DOS kernel (found in MSDOS.SYS for MS-DOS). In Windows 9x, these components are consolidated into IO.SYS, with MSDOS.SYS functioning as a configuration file.
  • The CONFIG.SYS file is parsed to extract configuration settings, including the variable which defaults to launching COMMAND.COM.
  • Once loaded, the command shell executes and then runs the startup batch script AUTOEXEC.BAT.
  • For successful booting, DOS system files loaded by the boot sector must be contiguous and occupy the first two entries in the FAT directory table, making modifications such as removal or addition potentially hazardous. However, substituting the shell can accelerate startup for dedicated applications. This restriction does not apply to DR DOS, where system files may reside anywhere within the root directory if the boot sector remains compatible.
  • In PC DOS and DR DOS 5.0 and later, system files are named IBMBIO.COM (replacing IO.SYS) and IBMDOS.COM (instead of MSDOS.SYS). Earlier DR DOS versions utilized DRBIOS.SYS and DRBDOS.SYS.
  • Beginning with MS-DOS 7.0, IO.SYS and MSDOS.SYS binaries were merged into IO.SYS, with MSDOS.SYS serving as a configuration file akin to CONFIG.SYS and AUTOEXEC.BAT. Setting MSDOS.SYS's BootGUI directive to 0 prevents automatic launching of WIN.COM after loading COMMAND.COM during boot.

File system

DOS employs a filesystem format that supports 8.3 filenames—filenames with up to eight characters plus a three-character extension. Hierarchical directories were introduced starting with DOS 2, also adhering to 8.3 naming conventions. Due to internal directory structure constraints, maximum path lengths are limited to 64 characters; including drive letters, fully qualified paths can be up to 80 characters long (drive:\path\filename.ext).

The underlying filesystem is based on the File Allocation Table (FAT). Initially, FAT12 supported a maximum of 4,078 clusters per volume. With DOS 3.0 came FAT16, which expanded cluster support up to 65,518 per drive. The Compaq MS-DOS 3.31 release introduced FAT16B, eliminating the previous 32 MiB volume size limit and extending support up to 512 MiB. Later, MS-DOS 7.1 (the DOS component within Windows 9x) added support for FAT32, enabling management of drives sized up to 137 GiB and beyond.

Starting from DOS 3.1, file redirector capabilities were incorporated—initially targeting network drives and subsequently CD-ROM drives through utilities like MSCDEX. IBM PC DOS 4.0 included early installable file system (IFS) support; however, this feature was removed in DOS 5.0. Additionally, DOS allowed Block Devices loaded via CONFIG.SYS to integrate network hardware directly into its filesystem architecture.

Drive letter assignment system

In DOS environments, storage devices are designated by alphabetic letters. The letters "A" and "B" are traditionally allocated to floppy drives, often both assigned on single-diskette setups to simplify disk swapping during tasks such as copying files or executing programs that require separate data disks. Initially, hard drives received the letters "C" and "D". DOS permits 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 formatted with supported filesystems, and finally to optical drives, RAM disks, and other hardware components.

The order in which letters are assigned depends on the sequence in which device drivers load, though this can be altered by specific drivers—for instance, network drive drivers generally assign letters toward the end of the alphabet.

Since DOS applications access drives directly through their letter designations (in contrast to Unix-like systems that use device paths such as /dev), introducing new hardware can disrupt existing drive letter arrangements. For example, adding a new hard disk with an active primary partition might cause reassignment of letters previously allocated to logical drives within extended partitions or affect the letters assigned to RAM disks and optical drives. This challenge persisted in Microsoft’s DOS-based Windows 9x series until NT-based Windows versions were introduced, which maintain consistent drive letter assignments unless manually changed by users.

Within DOS, users can alleviate this problem by creating a SUBST drive and installing software there, adjusting the drive mapping through batch scripts executed at startup. Certain versions of Concurrent DOS, Multiuser DOS, System Manager, and REAL/32 automatically assign the reserved letter L: to the drive from which an application is launched.

Device name reservations

DOS reserves specific device names that cannot be used as filenames regardless of file extension because they correspond to built-in character devices. These restrictions extend into various Windows editions and have occasionally led to system crashes and security vulnerabilities.

The reserved device names include:

  • COM1 through COM9 (serial communication ports)
  • LPT1 through LPT9 (parallel ports for printers)
  • CON (console; handles keyboard input and screen output)
  • AUX (auxiliary device; typically mapped to the first serial port)
  • PRN (printer; usually linked to the first parallel port)
  • NUL (null device)

In Windows 95 and 98, employing these reserved names within file paths could cause system crashes; Microsoft released security patches to address this. Windows XP silently reverts any such filenames back to their previous names without alerting the user, whereas Windows Vista and subsequent versions display an error message when these reserved names are used.

All MS-DOS, PC DOS, and DR-DOS versions have supported these reserved names (excluding NUL) consistently. Some OEM variants of MS-DOS included additional aliases like LST, while Hewlett-Packard’s MS-DOS 2.11 featured unique aliases such as 82164A for serial devices and PLT for plotters.

DOS 2.0 introduced extra devices like CLOCK$, with later releases expanding support for additional COM and LPT ports. Multitasking MS-DOS 4 added devices such as KEYBD$ and SCREEN$. DR-DOS 5.0 and later, along with Multiuser DOS, incorporate an $IDLE$ device intended for power management and multitasking optimization; some DR-DOS editions also support a fourth parallel printer via LPT4. The CONFIG$ device functions as the real-mode Plug and Play manager in MS-DOS versions 7.0 through 8.0.

By default, the name AUX points to COM1, while PRN maps to LPT1, although certain DOS versions permit reconfiguration so these aliases can refer to alternative serial or parallel hardware. Some OEM releases also provided flexible reassignment options for these device identifiers.

Conventionally, device names are followed by a colon (for example, NUL:) to signify their special function; however, the colon itself is not part of the device name. For instance:

<syntaxhighlight lang="dosbatch"> ECHO This achieves nothing > NUL </syntaxhighlight>

Using low-level disk editing tools makes it possible to create files or directories named after these reserved devices despite standard restrictions. Such methods have occasionally been exploited by malware authors seeking to conceal files from typical user access.

Memory management

DOS was originally created for the Intel 8088 CPU, which supports direct addressing of up to 1 MiB of RAM. IBM and Microsoft designated 640 kibibytes (KiB) for application use, while reserving the remaining 384 KiB for video memory, adapter ROMs, and BIOS functions. By the mid-1980s, certain DOS programs began to approach this memory ceiling, although a substantial portion of the reserved space often remained unused depending on system hardware.

To overcome these limitations, several memory extension standards were introduced. The Expanded Memory Specification (EMS) allowed access to additional memory installed on expansion cards through a 64 KiB page frame located in upper memory. Computers equipped with the 80386 processor or newer could employ virtual 8086 mode managers such as EMM386 to simulate expanded memory by mapping extended memory without requiring physical expansion cards. The Extended Memory Specification (XMS), designed for 80286 and later machines, enabled data transfers to and from extended memory areas, including the 65,520-byte high memory area and upper memory blocks. Support for XMS was commonly provided by drivers like HIMEM.SYS or virtual 86 mode managers like QEMM and 386MAX, which frequently also offered EMS functionality.

Beginning with DOS version 5, it became possible to load the operating system kernel and disk caching buffers into the HMA by configuring DOS=HIGH in CONFIG.SYS. Additionally, upper memory blocks could be utilized by specifying DOS=UMB, improving conventional memory availability.

DOS under OS/2 and Windows

DOS applications running under OS/2 and Windows operate similarly to native software, interfacing with drives, system services, and clipboard features through the host operating system’s drivers. This emulation layer converts DOS API requests into corresponding OS/2 or Windows system calls and simulates BIOS and I/O port interactions typical of DOS programs.

In Windows versions 3.1 and 9x, the DOS environment is managed by WINOLDAP, which establishes a virtual machine based on program information files (PIFs) and the system state at startup. This setup supports running DOS graphics modes within windowed environments and integrates clipboard operations.

OS/2 and Windows NT provide a DOS emulation environment derived from DOS 5. They allow session-specific alternate config.sys and autoexec.bat files, enabling third-party drivers to access host resources seamlessly.

Starting with OS/2 version 2.x and later, DOS emulation is handled by DOSKRNL—a merged IBMBIO.COM and IBMDOS.COM component—with system calls redirected to OS/2 services. DOS utilities are incorporated as combined DOS/OS2 applications within the \OS2 directory. OS/2 also runs Windows 3.1 programs through Win-OS/2, allowing either integrated desktop operation or dedicated WinOS/2 sessions.

Additionally, OS/2 supports "DOS from Drive A:" (VMDISK), which lets users boot an authentic MS-DOS floppy disk image (such as MS-DOS 6.22) enhanced with OS/2 drivers for direct hardware access—beneficial for unsupported peripherals like certain CD-ROM drives.

Since 1993, all 32-bit editions of Windows NT include DOS emulation via the virtual DOS machine (NTVDM). However, 64-bit versions of Windows do not feature NTVDM support and cannot execute native 16-bit DOS programs; running such software requires third-party emulators like DOSbox.

User interface

DOS environments rely on a command-line interface, where users launch applications by typing their filenames at the prompt. The system also provides utility programs alongside internal commands integrated into the command interpreter.

To improve usability, numerous developers created file management tools featuring WIMP-style interfaces. Microsoft Windows notably evolved from these concepts, with Windows 9x eventually supplanting DOS as the primary PC-compatible program loader. Among widely used text-based interfaces were Norton Commander, DOS Navigator, and Volkov Commander, while graphical shells included Digital Research’s GEM and GEOS.

Prominent DOS distributors released their own environment managers: MS-DOS/IBM DOS version 4 introduced DOS Shell, whereas DR DOS 5.0 launched ViewMAX, which was based on GEM technology.

Terminate and stay resident

While DOS does not inherently support multitasking, its terminate-and-stay-resident (TSR) capability allows applications to remain loaded in memory by intercepting system interrupts. This mechanism enables programs to perform background operations or be activated on demand, providing a form of limited multitasking for individual applications. A notable instance is the DOS PRINT utility, which employs TSR to manage print spooling in the background. Similarly, Borland Sidekick, a popup personal organizer, utilizes this approach.

TSRs enhance DOS by adding functionalities such as improved command-line editing tools like CED and DOSKEY, as well as facilitating CD-ROM support through Microsoft CD-ROM Extensions (MSCDEX).

Certain TSR programs offer rudimentary task switching; for example, the shareware application Back and Forth (1990) permitted users to save a program’s state to disk, load another application, and toggle between them—albeit with noticeable delays due to disk operations. Genuine multitasking and background processing typically required utilities like DESQview, which demanded at least an 386 processor.

Software

Development tools

See also

External links

Related profiles

CCOM1CCLOCK$CCOM3LLPT3
Retrieved from "https://www.alfawiki.org/index.php?title=COM2&oldid=29034"