Jump to content

PRN:

From Alfawiki
Adapted from the English Wikipedia article PRN:, available under CC BY-SA 4.0Updated 9 August 2025
DOS
Company typeOperating system family
IndustryComputer software
Founded1981
Area served
IBM PC compatible computers
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 primary members of this family are IBM PC DOS and Microsoft's MS-DOS, both introduced in 1981. Additional compatible variants include DR-DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1994). MS-DOS held a dominant position in the IBM PC compatible market from 1981 until 1995.

Although commonly linked specifically to MS-DOS, DOS is a generic, platform-agnostic abbreviation for disk operating system, with origins preceding the IBM PC era. Many other operating systems have used this acronym, including DOS/360 from 1966, as well as Apple DOS, Apple ProDOS, Atari DOS, Commodore DOS, TRSDOS, and AmigaDOS.

Origins

IBM PC DOS and its forerunner, 86-DOS, operated on Intel 8086 16-bit processors. Modeled to mirror Digital Research's leading CP/M system for 8-bit microcomputers, the goal was to facilitate porting CP/M applications onto MS-DOS.

When IBM developed the IBM PC featuring the Intel 8088 processor, it required an operating system. Chairman John Opel was introduced to Bill Gates through Mary Maxwell Gates. IBM initially approached Digital Research to license CP/M, but negotiations collapsed over licensing terms and naming rights; Digital Research founder Gary Kildall declined IBM's conditions, prompting IBM to withdraw.

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-inspired OS for SCP's Intel 8086 CPU board. Microsoft acquired 86-DOS—reportedly for $50,000—and rebranded it as MS-DOS in 1981. Within a year, Microsoft licensed MS-DOS to more than 70 hardware vendors, who sometimes marketed it under alternative names such as Zenith Data Systems' Z-DOS. Microsoft later enforced the MS-DOS brand name except for IBM's edition. Meanwhile, IBM continued advancing PC DOS.

Digital Research responded by offering CP/M-86 alongside PC DOS; however, higher pricing limited its adoption. As a result, MS-DOS and PC DOS established themselves as the standard operating systems for PCs and compatibles.

Initially, Microsoft sold MS-DOS exclusively to original equipment manufacturers (OEMs) due to early hardware variability among PCs. DOS architecture separated device drivers (IO.SYS) from the kernel (MSDOS.SYS), enabling OEMs to customize via an OEM Adaptation Kit (OAK). By the early 1990s, widespread IBM PC compatibility allowed Microsoft to release retail versions beginning with MS-DOS 5.0.

In the mid-1980s, Microsoft developed a multitasking variant of DOS ("European MS-DOS 4") tailored for International Computers Limited (ICL) and European firms. This edition supported preemptive multitasking, shared memory, device helper services, and New Executable format files—features that influenced the OS/2 1.0 kernel but were not incorporated into subsequent DOS releases. This contrasts with IBM’s broadly distributed PC DOS 4.0, which was based on DOS 3.3.

Digital Research aimed to regain market presence with products such as Concurrent DOS, FlexOS, DOS Plus, Multiuser DOS, and DR DOS—all compatible with MS-DOS or CP/M-86 software. Following Novell’s acquisition of Digital Research, DR DOS evolved into PalmDOS and Novell DOS; later stewardship passed through Caldera (OpenDOS/DR-DOS), Lineo, and DeviceLogics.

Gordon Letwin remarked in 1995 that DOS was originally a stopgap product intended merely to satisfy IBM so they would purchase Microsoft's programming languages. Microsoft planned to transition MS-DOS toward single-user Xenix compatibility—a Unix-like system envisioned as its successor across multiple CPUs—described by BYTE magazine as "the multi-user MS-DOS of the future."

However, IBM preferred maintaining DOS. After AT&T began marketing Unix systems, Microsoft and IBM collaborated on OS/2 as an alternative but eventually diverged due to disagreements over OS/2 and Windows development strategies. This resulted in separate trajectories: Microsoft's final retail MS-DOS release was version 6.22 before integrating it into Windows 95/98/Me; IBM’s last retail PC DOS was version 2000 (7 revision 1), followed by OEM/internal editions.

The FreeDOS initiative commenced in June 1994 after Microsoft discontinued sales and support of MS-DOS. Jim Hall launched this open-source project; additional developers joined promptly. They created a kernel, COMMAND.COM shell, and essential utilities by combining existing codebases. Following several pre-release versions, FreeDOS 1.0 debuted in September 2006 under the GNU General Public License (GPL), providing a royalty-free alternative to MS-DOS.

Decline

Initial iterations of Microsoft Windows operated atop MS-DOS. By the early 1990s, the Windows graphical user interface had become widely adopted. The release of Windows 95 in 1995 marked the debut of a standalone operating system that no longer required a separate DOS license. Windows 95, along with Windows 98 and ME, served as the primary OS kernel, although MS-DOS remained available for compatibility reasons. In Windows 95 and 98 (excluding ME), the MS-DOS component could function independently from Windows. Since DOS was no longer critical for running Windows, direct user interaction with DOS significantly declined.

Continued use

Currently, compatible DOS variants include FreeDOS, ROM-DOS, PTS-DOS, RxDOS, and REAL/32. Certain manufacturers such as Dell and HP have offered systems preloaded with FreeDOS as an OEM operating system. While Dell appears to have ceased FreeDOS pre-installations after 2008, DOS remains in use among some developers and engineers due to its low-level hardware control capabilities.

Embedded systems

The ability of DOS to access hardware directly makes it suitable for embedded devices. The most recent DR-DOS editions continue to target this segment. ROM-DOS functions as the OS for hardware like the Canon PowerShot Pro 70 camera.

Emulation

On Linux platforms, DOSEMU delivers a native virtual environment that runs DOS applications at near-native speeds. Additionally, emulators such as DOSBox enable DOS program execution on Unix and Windows systems. DOSBox primarily focuses on running classic games (for example, King's Quest and Doom) on contemporary operating systems. It incorporates its own DOS implementation integrated with the emulator but also supports booting MS-DOS, FreeDOS, or other DOS variants.

Design

MS-DOS and IBM PC DOS are predominantly associated with Intel x86 or compatible processors, mainly within IBM PC-compatible machines. Customized MS-DOS versions existed for non-IBM-compatible x86 hardware, ranging from rebranded Microsoft editions to specially adapted variants. Software utilizing DOS APIs could operate across both compatible and incompatible platforms. The original FreeDOS kernel, known as DOS-C, originated from DOS/NT designed for Motorola 68000 CPUs; it lacked binary compatibility due to differing instruction sets, although high-level language applications remained portable.

As a single-user, single-tasking operating system with non-reentrant kernel functions, DOS permits only one active program at a time. Its kernel exposes an API for character input/output, managing files and memory, loading programs, and terminating processes.

Shell scripting is facilitated through batch files (.BAT), which support commands such as GOTO and conditional branching.

While DOS provides an API tailored for character-based applications, it does not standardize access to most hardware devices (including graphics adapters, printers, or mice), necessitating direct hardware manipulation by programmers. This situation led to the creation of application-specific device drivers for peripherals, with manufacturers releasing hardware specifications to ensure compatibility with popular software.

Boot sequence

  • On PC-compatible computers, the boot process begins with 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 booting from the next physical disk; otherwise, it transfers control to the load address with registers initialized.
  • When an MBR is present in the boot sector, it relocates itself to memory address : and scans the partition table for an active partition. It then loads that partition’s first sector—the Volume Boot Record (VBR)—into memory at :, handing over execution there.
  • The VBR is specific to each operating system version and generally cannot be interchanged between different DOS releases. Early DOS versions (such as DOS 1.x) loaded the entire IO.SYS/IBMBIO.COM file into memory at :, requiring these sectors 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 continuing execution.
  • In more recent DOS versions, after loading initial sectors of IO.SYS/IBMBIO.COM, a secondary loader completes reading the remainder from disk using root directory information. Older versions omit this step by loading the full file immediately.
  • System initialization proceeds by loading built-in device drivers along with the DOS kernel (contained in MSDOS.SYS for MS-DOS). In Windows 9x editions, these components are merged into IO.SYS; MSDOS.SYS functions instead as a configuration file.
  • The configuration file CONFIG.SYS is parsed next for system parameters; notably, the variable specifies the shell’s location—defaulting to COMMAND.COM.
  • The command shell is then loaded and executed.
  • Finally, any startup commands contained in the batch file AUTOEXEC.BAT are run.

Boot sector-loaded DOS system files must be stored contiguously and occupy the first two entries in the FAT directory table. Modifying these files can render media unbootable; however, substituting just the shell can accelerate startup for dedicated applications. This restriction does not apply to DR DOS systems where system files may reside anywhere within the root directory without being contiguous—allowing straightforward copying if the boot sector supports DR DOS.

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

Starting with MS-DOS 7.0, IO.SYS and MSDOS.SYS were combined into a single IO.SYS executable file while MSDOS.SYS became a configuration file similar in purpose to CONFIG.SYS and AUTOEXEC.BAT. If MSDOS.SYS contains a BootGUI directive set to 0, booting halts after launching COMMAND.COM rather than automatically starting 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. From DOS version 2 onwards, hierarchical directory structures were implemented, adhering to the same 8.3 format. Due to internal Current Directory Structure (CDS) limitations, the maximum allowable path length is restricted to 64 characters. When including the drive letter, the maximum length for a fully qualified filename is 80 characters (formatted as drive:\path\filename.ext).

The underlying filesystem in DOS is based on the File Allocation Table (FAT) architecture. Originally, FAT12 allowed for a maximum of 4,078 clusters per volume. With the release of DOS 3.0, FAT16 was introduced, featuring 16-bit entries and supporting up to 65,518 clusters. Later, Compaq MS-DOS 3.31 expanded capabilities with FAT16B, eliminating the previous 32 MiB volume size restriction and allowing volumes up to 512 MiB. Subsequently, MS-DOS 7.1 (integrated with Windows 9x) incorporated FAT32, which supports drives exceeding 137 GiB.

Beginning with DOS 3.1, support for file redirectors enabled network functionality and later CD-ROM access through MSCDEX. IBM PC DOS 4.0 briefly offered installable file system (IFS) support; however, this feature was removed in DOS 5.0. Additionally, DOS could load Block Devices via CONFIG.SYS to facilitate integration with network hardware.

Drive naming scheme

In DOS environments, drive identifiers are assigned as letters, with "A" and "B" traditionally reserved for floppy drives. Systems equipped with a single floppy drive typically allocate both letters to it, enabling disk swapping during tasks such as copying files or running programs that require data from separate disks. Initially, hard drives were assigned the letters "C" and "D." DOS supports only one active partition per physical drive; letter assignments prioritize active primary partitions first, followed by logical drives within extended partitions, then inactive primary partitions, and finally optical drives, RAM disks, and other devices. The order of letter assignment generally corresponds to the sequence in which device drivers load but can be manually overridden—network drive drivers often assign letters toward the end of the alphabet.

Because DOS applications rely on fixed drive letters rather than dynamic device paths like Unix-style /dev entries, adding new hardware can alter existing letter assignments. For example, installing a hard disk containing a primary partition might cause previously assigned letters for logical drives or RAM disks to shift. This issue persisted through Microsoft’s DOS-based Windows 9x versions until NT-based systems were introduced, which maintain existing drive letter allocations unless manually changed by users. Common workarounds in DOS include creating SUBST drives or launching applications via batch scripts that remap drive letters dynamically. Some multitasking DOS variants such as Concurrent DOS, Multiuser DOS, System Manager, and REAL/32 automatically assign the reserved L: drive letter to the current load drive when launching applications.

Reserved device names

DOS reserves certain device names that cannot be used as filenames regardless of file extension because they correspond to internal character devices. These reserved names remain restricted in various Windows versions and have occasionally caused system crashes or security vulnerabilities.

The list of reserved device names includes:

  • COM1 through COM9 (serial ports)
  • LPT1 through LPT9 (parallel printer ports)
  • CON ("console," representing keyboard input and screen output)
  • AUX ("auxiliary," commonly mapped to the first serial port)
  • PRN ("printer," typically corresponding to the first parallel port)
  • NUL (null device)

Under Windows 95 and 98, referencing these reserved names within file paths could lead to system crashes; Microsoft subsequently issued security patches addressing these issues. In Windows XP, attempts to use these names silently revert filenames without error messages, whereas Vista and later versions display an error indicating "The specified device name is invalid."

These reserved identifiers—except for NUL—have been consistently supported across MS-DOS, PC DOS, and DR-DOS variants. Certain OEM versions of MS-DOS included additional aliases such as LST and PLT, while support for multiple COM and LPT ports was extended in later releases of DOS. Advanced multitasking DOS systems introduced further device names like KEYBD$, SCREEN$, and power management features accessible via $IDLE$.

By default, AUX and PRN map respectively to COM1 and LPT1, though some DOS implementations allow reassignment to alternative serial or parallel devices. Device names are conventionally followed by a colon (e.g., NUL:) to signify device files; however, this colon is not part of the actual device name.

While these reserved names cannot be created through normal file operations, they can occasionally be exploited by malicious software or hacking tools using direct disk editing techniques to conceal files from users.

Memory management

DOS was originally developed for the Intel 8088 processor, which has a direct addressing capability limited to 1 MiB of RAM. IBM and Microsoft allocated 640 KiB of this space for application use, reserving the remaining 384 KiB for video memory, adapter ROMs, and BIOS functions. By the mid-1980s, certain software applications began to approach this memory ceiling, although a significant portion of reserved memory often remained idle depending on the hardware configuration.

To overcome these constraints, the Expanded Memory Specification (EMS) was introduced, enabling additional memory through expansion cards that mapped extra RAM into a 64 KiB page frame located in the upper memory region. Systems equipped with 80386 or newer processors could utilize virtual 8086 mode managers such as EMM386 to simulate expanded memory by leveraging extended memory without requiring physical add-on cards. The Extended Memory Specification (XMS), designed for systems with 80286 processors and above, facilitated data transfers to extended memory and provided access to the high memory area (HMA) just beyond the 1 MiB boundary, as well as upper memory blocks. Support for XMS was commonly delivered via HIMEM.SYS or virtual 86 mode managers like QEMM and 386MAX, which also offered EMS compatibility.

Starting with DOS version 5, users could configure the operating system to load its kernel and disk buffering routines into the HMA by including DOS=HIGH in the CONFIG.SYS file. Additionally, the use of DOS=UMB allowed DOS to exploit upper memory blocks for loading device drivers and TSR programs.

DOS under OS/2 and Windows

DOS emulation within OS/2 and Windows environments operates similarly to native applications by providing access to drives, system services, and clipboard functionality. Because these host systems manage file system drivers internally, DOS emulators implement a translation layer that converts DOS API calls into corresponding OS/2 or Windows system calls. This layer also virtualizes BIOS interrupts and I/O port operations typically used by DOS applications.

In Windows versions 3.1 and 9x, the WINOLDAP component creates a virtual machine environment guided by program information files (PIFs) and initial system state at startup. This setup allows DOS graphics modes to be rendered within windowed interfaces while supporting clipboard sharing between DOS and Windows applications.

DOS emulation on OS/2 and Windows NT is based on DOS version 5. Users can specify alternative CONFIG.SYS and AUTOEXEC.BAT files on a per-session basis to load drivers that facilitate interaction with the host operating system. Often, third-party utilities assist in managing these configurations.

Starting with OS/2 version 2.x, DOSKRNL—a merged version of IBMBIO.COM and IBMDOS.COM—routes system calls through OS/2 services. DOS programs execute in isolated sessions supported by utility programs bundled with integrated DOS/OS2 applications located in the \OS2 directory. OS/2 also supports Windows 3.1 applications through Win-OS/2 technology, allowing them to run either seamlessly alongside OS/2 programs or within separate desktop environments.

OS/2 provides a feature called 'DOS from Drive A:' (VMDISK), which boots a genuine DOS environment such as MS-DOS 6.22 enhanced with OS/2 device drivers to enable hardware access not natively supported by OS/2.

Since the release of all 32-bit editions of Windows NT in 1993, DOS emulation has been provided via the Virtual DOS Machine (NTVDM). However, 64-bit versions of Windows do not include NTVDM support and thus cannot run 16-bit DOS applications directly; users must rely on third-party emulators like DOSBox.

User interface

DOS systems function through a command-line interface, where users initiate programs by typing their filenames at the command prompt. The environment includes built-in commands as well as external utility programs that offer additional functionality.

To improve user experience, numerous software developers created file management tools featuring WIMP interfaces. Microsoft Windows evolved significantly in this domain, ultimately becoming a standalone program loader that supplanted DOS as the primary PC-compatible environment loader. Popular text-based interfaces included Norton Commander, DOS Navigator, Volkov Commander, Quarterdeck’s DESQview, and Sidekick. Graphical user interfaces were represented by Digital Research’s GEM and GEOS.

Leading DOS vendors incorporated their own environment management tools: MS-DOS/IBM DOS version 4 introduced DOS Shell, whereas DR DOS 5.0 featured ViewMAX, which was built upon GEM technology.

Terminate and stay resident

Although DOS does not inherently support multitasking, its terminate-and-stay-resident (TSR) capability allows applications to remain loaded in memory, intercepting system timers or keyboard interrupts to perform background operations or be activated at any moment. For instance, the DOS PRINT utility utilizes TSR for asynchronous print spooling, while Borland Sidekick, a popup personal organizer, also relies on this approach.

TSRs enhance DOS by providing features beyond its standard limitations. Utilities such as CED and DOSKEY improve command-line editing, whereas Microsoft CD-ROM Extensions (MSCDEX) facilitate access to CD-ROM drives.

Certain TSR programs offer rudimentary task switching; the shareware application Back and Forth (1990) enables users to save a program’s state to disk, load another application, and toggle between them—albeit with delays due to disk operations. Nevertheless, genuine multitasking required specialized software like DESQview running on at least an 386 processor.

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 including 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 No. 6183940
  • Mueller, Scott. Upgrading and Repairing PCs. Que Publishing, 1998.
  • Bailes, Lenny; Mueller, John. Memory Management and Multitasking Beyond 640K. McGraw-Hill, 1992.

External links

Related profiles

CCOM1CCLOCK$CCOM2CCOM3
Retrieved from "https://www.alfawiki.org/index.php?title=PRN:&oldid=29057"