Jump to content

SCREEN$

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

DOS (, ) refers to a group 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 launched in 1981. Other related systems include DR-DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1994). MS-DOS maintained a leading position in the IBM PC compatible market from 1981 until 1995.

Although often linked specifically to MS-DOS and its derivatives, the term DOS broadly stands for disk operating system, a designation that existed before the IBM PC era. Several operating systems have adopted this acronym, such as DOS/360 (1966), Apple DOS, Apple ProDOS, Atari DOS, Commodore DOS, TRSDOS, and AmigaDOS.

Origins

IBM PC DOS and MS-DOS trace their lineage back to 86-DOS, which operated on Intel 8086 16-bit processors. Created to resemble Digital Research’s leading CP/M system for easier software porting, MS-DOS was developed when IBM sought an operating system for its newly introduced IBM PC using the Intel 8088 CPU.

Initially, IBM attempted to license CP/M from Digital Research, but negotiations collapsed over licensing conditions and trademark issues. IBM then approached Bill Gates, who acquired 86-DOS from Seattle Computer Products. This OS, developed by Tim Paterson as a CP/M-like system for testing an 8086 CPU card, was purchased by Microsoft for about $50,000 and rebranded as MS-DOS in 1981.

Within a year, Microsoft licensed MS-DOS to more than 70 original equipment manufacturers (OEMs), who marketed it under various names such as Zenith Data Systems’ Z-DOS. Microsoft eventually standardized the MS-DOS brand, except for IBM’s version, which remained as PC DOS. Digital Research countered by releasing CP/M-86 alongside PC DOS; however, due to higher prices and weaker demand, CP/M gradually declined while MS-DOS and PC DOS became the dominant platforms for PCs and compatibles.

Microsoft initially distributed MS-DOS solely through OEMs to allow customization via an OEM Adaptation Kit (OAK), enabling device driver modifications independent of the DOS kernel to support diverse hardware setups. By the early 1990s, with IBM PC compatibility widespread, Microsoft began offering retail copies starting with MS-DOS version 5.0.

In the mid-1980s, Microsoft developed a multitasking variant of DOS—sometimes referred to as "European MS-DOS 4"—which was licensed to European firms like ICL. This version provided preemptive multitasking and shared memory capabilities and laid the groundwork for OS/2 1.0’s kernel but differed from IBM’s PC DOS 4.0 release.

Digital Research attempted to reclaim market share with products such as Concurrent DOS, FlexOS, Multiuser DOS, and DR DOS—all compatible with MS-DOS applications—and was eventually acquired by Novell. DR DOS evolved through iterations including PalmDOS, Novell DOS, Caldera’s OpenDOS/DR-DOS releases, followed by Lineo and DeviceLogics versions.

According to Gordon Letwin in 1995, DOS was originally intended as a temporary solution for IBM while Microsoft concentrated on developing Xenix—a multi-user UNIX-like system envisioned as its successor. Nevertheless, IBM preferred to continue using DOS, leading Microsoft and IBM to collaborate on OS/2 as an alternative platform. Disagreements over OS/2 and Windows development caused their DOS projects to diverge. The final retail edition of MS-DOS was version 6.22; later versions were integrated into Windows 95/98/Me environments. IBM’s last retail offering was PC DOS 2000; subsequent releases were limited to OEM distribution.

The FreeDOS initiative commenced in June 1994 following Microsoft’s discontinuation of MS-DOS sales and support. Jim Hall spearheaded this open-source effort by assembling contributed components into a complete kernel, command interpreter (COMMAND.COM), and utility suite. Released under the GNU General Public License in September 2006 as FreeDOS 1.0, it provides a free alternative that continues to be actively maintained today.

Decline

Initial iterations of Microsoft Windows functioned as a graphical interface running on top of MS-DOS. By the early 1990s, Windows' graphical environment had become widely embraced. The launch of Windows 95 in 1995 marked its emergence as an independent operating system, removing the necessity for a separate DOS license. Windows 95, together with Windows 98 and ME, established themselves as the primary OS kernel, although MS-DOS was retained for compatibility purposes. Unlike Windows ME, both Windows 95 and 98 allowed MS-DOS to operate independently from the Windows environment. As reliance on DOS diminished, the majority of users stopped interacting with it directly.

Continued use

Currently, several compatible operating systems exist, including FreeDOS, ROM-DOS, PTS-DOS, RxDOS, and REAL/32. Certain manufacturers like Dell and HP have offered computers shipped with FreeDOS as the pre-installed OEM system. While FreeDOS OEM distributions appear to have largely ceased post-2008, various developers and engineers still utilize DOS variants because of their low-level hardware interfacing capabilities.

Embedded systems

Due to DOS's architecture granting direct hardware control, it remains suitable for use in embedded devices. The latest releases of DR-DOS have been tailored specifically to this sector. For instance, ROM-DOS operates as the system software in devices such as the Canon PowerShot Pro 70.

Emulation

Under Linux, DOSEMU enables execution of DOS applications at speeds close to native performance. Additional emulators like DOSBox facilitate running DOS on both Unix-like platforms and Microsoft Windows. DOSBox is primarily designed for preserving classic games (such as King's Quest and Doom) on contemporary operating systems. It incorporates its own embedded DOS environment linked to the emulator but can also boot external DOS versions like MS-DOS or FreeDOS when required.

Design

MS-DOS and IBM PC DOS are predominantly associated with Intel x86 or compatible processors, especially within the realm of IBM PC compatible hardware. There were machine-specific MS-DOS variants created for non-IBM-compatible x86 systems that ranged from simple rebranding to fully customized versions accommodating unique hardware configurations. Applications utilizing DOS APIs rather than direct hardware manipulation could operate across both compatible and incompatible platforms. The initial kernel of FreeDOS, known as DOS-C, originated from DOS/NT developed for Motorola 68000 CPUs; however, it lacked binary compatibility due to different instruction sets, although programs written in high-level languages remained portable.

As a single-user, single-tasking operating system, DOS features a non-reentrant kernel allowing only one active program at any given time. Its kernel offers an application programming interface that facilitates character input/output, file and memory management, along with program execution control.

Batch files (.BAT) serve as scripting tools within the shell environment, supporting internal commands such as GOTO and conditional statements.

While DOS's API permits creation of character-based applications, it does not provide direct access to most hardware components like graphics adapters, printers, or mice. Consequently, developers often had to implement direct hardware access themselves, typically embedding device drivers within each application to support peripheral devices. Hardware manufacturers released specifications to assist developers in producing drivers compatible with widely used software.

Boot sequence

  • On PC-compatible machines, the bootstrap loader is stored within the master boot record (MBR), which is found at the boot sector—the initial sector of the boot disk. The ROM BIOS loads this sector into memory at :, verifying the presence of a signature "" at offset . If this signature is absent or incorrect, it attempts to boot from the next available disk; if present and valid, execution proceeds by jumping to the designated load address with registers configured accordingly.
  • When the boot sector contains an MBR, it is relocated in memory to : . The MBR then examines its partition table for an active partition and loads that partition’s first sector—the Volume Boot Record (VBR)—into memory at :, subsequently transferring control to it.
  • The VBR is tailored to a specific operating system and typically lacks compatibility across different DOS versions. Initial DOS releases (such as DOS 1.x) loaded the complete IO.SYS/IBMBIO.COM file into memory at :, necessitating these files to be stored contiguously on disk. Later iterations identify the first boot file entries within the root directory and load only the initial sectors of IO.SYS/IBMBIO.COM into memory, preserving the Disk Parameter Table (DPT), before handing over control to that code segment.
  • In more modern DOS versions, this partial loader then proceeds to load the remainder of IO.SYS/IBMBIO.COM using information from the root directory, still requiring contiguous file placement. Earlier DOS variants bypass this by loading the entire file upfront.
  • Following this, DOS system initialization occurs, which involves loading built-in device drivers alongside the DOS kernel—known as MSDOS.SYS in MS-DOS or integrated within IO.SYS on Windows 9x systems, where MSDOS.SYS functions as a configuration file.
  • Configuration parameters are parsed from the CONFIG.SYS file; among these, the variable specifies the shell’s location, defaulting to COMMAND.COM.
  • Once loaded, the shell executes and then runs the startup batch script AUTOEXEC.BAT.
  • For successful booting, DOS system files loaded by the boot sector must be stored contiguously and occupy the first two entries in the directory table. Altering these files by removal or addition can prevent media from booting properly. However, swapping out the shell is feasible to speed up startup for dedicated applications. This constraint does not apply to DR DOS, where system files may reside anywhere within the root directory without requiring contiguity; consequently, system files can be copied directly if using a DR DOS-compatible boot sector.
  • In PC DOS and DR DOS versions 5.0 and later, system files are named IBMBIO.COM (replacing IO.SYS) and IBMDOS.COM (replacing MSDOS.SYS). Earlier DR DOS releases used DRBIOS.SYS and DRBDOS.SYS instead.
  • Beginning with MS-DOS 7.0, IO.SYS and MSDOS.SYS were merged into a single IO.SYS binary; MSDOS.SYS became a configuration file analogous to CONFIG.SYS and AUTOEXEC.BAT. Setting the MSDOS.SYS BootGUI directive to 0 halts booting after loading COMMAND.COM instead of launching WIN.COM automatically.

File system

DOS utilizes a filesystem that supports 8.3 filename conventions: filenames are limited to eight characters plus a three-character extension. Starting with DOS 2, hierarchical directories were introduced, each adhering to the 8.3 naming format as well. Due to internal current directory structure (CDS) tables, directory path lengths are capped at 64 characters. Including drive letters, fully qualified filenames cannot exceed 80 characters (drive:\path\filename.ext).

The filesystem employed is based on the File Allocation Table (FAT). Initially, FAT12 was used, accommodating up to 4,078 clusters per volume. DOS 3.0 introduced FAT16, featuring 16-bit entries that support up to 65,518 clusters. Compaq MS-DOS 3.31 extended this with FAT16B, removing previous 32 MiB drive size restrictions and allowing volumes up to 512 MiB. MS-DOS 7.1 (bundled with Windows 9x) incorporated FAT32, which uses 32-bit entries enabling support for hard drives sized up to and beyond 137 GiB.

From DOS version 3.1 onward, support for file redirectors was added to enable networking and later CD-ROM access through MSCDEX. IBM PC DOS 4.0 introduced preliminary installable file system (IFS) support, which was discontinued in DOS 5.0. Additionally, DOS could load Block Devices via CONFIG.SYS to integrate network devices into its filesystem architecture.

Drive letter assignment system

Within DOS, drive identification relies on letters: "A" and "B" are designated exclusively for floppy drives. In systems with a single floppy drive, both letters correspond to the same physical device, simplifying disk swapping for copying or accessing data and programs. Hard drives begin with the letters "C" and "D". DOS permits only one active partition per physical disk; drive letters are allocated first to active primary partitions, then to logical drives within extended partitions, followed by non-active primary partitions that have supported filesystems. Subsequently, letters are assigned to optical disc drives, RAM disks, and other hardware components.

Typically, letter allocation follows the sequence in which drivers are loaded but can be customized—for example, network drive drivers often designate letters near the end of the alphabet.

Because DOS programs interact directly with drive letters (contrasting with Unix-like systems that use device files in /dev), adding new hardware can alter existing letter assignments. For instance, connecting a hard disk containing a primary partition may cause reassignment of letters previously used by logical drives on other disks. This challenge remained present through DOS-based Windows 9x editions until NT-based Windows versions preserved current assignments unless manually changed by users.

Common solutions include creating SUBST drives and installing software on those virtual drives, with batch scripts adjusting letter assignments during system startup. Certain versions of Concurrent DOS, Multiuser DOS, System Manager, and REAL/32 automatically map the reserved drive letter L: to the drive from which applications launch upon startup.

Reserved device identifiers

DOS reserves specific device names that cannot be employed as filenames under any extension because they correspond to built-in character devices. These restrictions continue in multiple Windows releases and have occasionally led to system crashes or security vulnerabilities.

The reserved names consist of:

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

In Windows 95 and 98, attempting to use these reserved names within file paths could cause system crashes, prompting Microsoft to release security patches. Windows XP silently reverts such filenames back to their original names without warning, whereas Windows Vista and subsequent versions display an error message stating "The specified device name is invalid."

These reserved identifiers (except for NUL) remain supported across MS-DOS, PC DOS, and DR-DOS variants. Some OEM MS-DOS versions introduced additional aliases such as LST, while Hewlett-Packard's OEM MS-DOS 2.11 added further aliases including 82164A for serial devices and PLT for plotters.

Later DOS releases introduced extra reserved devices like CLOCK$, starting from DOS 2.0, along with multitasking-specific devices such as KEYBD$ and SCREEN$. DR-DOS and Multiuser DOS incorporated devices like $IDLE$, designed for power management and multitasking efficiency.

By default, AUX is linked to COM1, and PRN corresponds to LPT1, although some DOS variants permit remapping these to alternative serial or parallel ports. Device names are conventionally followed by a colon (e.g., NUL:) though the colon itself is not part of the device identifier.

Although normal file operations prevent creation of files or directories with these reserved names, it is possible via direct disk editing—an approach sometimes exploited by malware to conceal files from standard user access.

Memory management

DOS was originally developed for the Intel 8088 CPU, which supports direct addressing of up to 1 MiB of RAM. IBM and Microsoft designated 640 kibibytes (KiB) as the upper limit of memory accessible to applications, reserving the remaining 384 KiB for video buffers, adapter ROMs, and BIOS functions. By the mid-1980s, some DOS programs approached this memory ceiling, although a significant portion of reserved memory often remained idle depending on the hardware configuration.

To overcome these constraints, standards such as the Expanded Memory Specification (EMS) provided a mechanism to access extra memory through a 64 KiB page frame located in upper memory. Computers equipped with 80386 or newer processors could leverage virtual 8086 mode (V86) managers like EMM386, which simulated expanded memory using extended memory without requiring additional expansion cards. The Extended Memory Specification (XMS), designed for 80286 and later systems, allowed data transfer between conventional and extended memory, as well as access to the high memory area (HMA) just beyond the 1 MiB boundary—typically managed by drivers such as HIMEM.SYS or V86 managers including QEMM and 386MAX.

With the release of DOS 5, it became possible to load the kernel and disk caching buffers into the HMA by specifying DOS=HIGH in CONFIG.SYS. Additionally, DOS 5 and subsequent versions supported upper memory blocks through DOS=UMB, thereby freeing more conventional memory for applications.

DOS under OS/2 and Windows

Within OS/2 and Windows environments, DOS programs run through an emulation layer that mimics native execution by translating DOS API calls into corresponding OS/2 or Windows system calls. This abstraction also virtualizes BIOS routines and I/O port interactions typical of DOS software.

In Windows versions 3.1 and 9x, the DOS virtual machine is controlled by WINOLDAP, which establishes a virtual machine based on program-specific PIF configurations and system conditions at launch. This setup supports running DOS graphics modes inside a windowed environment while facilitating clipboard sharing.

The emulated DOS environment in OS/2 and Windows NT is based on DOS version 5, enabling users to customize config.sys and autoexec.bat files on a per-session basis. Access to host resources can be achieved by loading device drivers, often with assistance from third-party utilities.

Starting with OS/2 version 2.x and later, DOS emulation is handled by DOSKRNL, which merges IBMBIO.COM and IBMDOS.COM while redirecting system calls to OS/2 services. DOS applications execute in isolated sessions supported by utilities from integrated DOS/OS2 programs. OS/2 also provides compatibility with Windows 3.1 applications via Win-OS/2, allowing them to run either integrated within the OS/2 desktop or in a separate WinOS/2 session.

OS/2 further supports booting genuine DOS systems from floppy disks (using VMDISK), such as MS-DOS 6.22 or PC DOS 5.00, enhanced with OS/2 drivers for hardware access—beneficial for devices lacking native support like certain CD-ROM drives.

All 32-bit editions of Windows NT released since 1993 include the virtual DOS machine (NTVDM) for running DOS applications. However, 64-bit Windows versions do not support NTVDM and thus cannot execute 16-bit DOS programs natively; users must rely on third-party emulators such as DOSbox to achieve compatibility.

User interface

DOS environments operate primarily through a command-line interface, where users launch programs by typing their executable names at the prompt. The system includes both internal commands built into the shell and external utility programs stored as separate files.

To improve usability, numerous developers created file management tools featuring WIMP-style graphical interfaces. Microsoft Windows notably evolved into a comprehensive program loader that ultimately supplanted DOS as the primary PC-compatible application launcher. Well-known text-based user interfaces encompassed solutions like Norton Commander, DOS Navigator, Volkov Commander, Quarterdeck’s DESQview, and Sidekick. Graphical shells included Digital Research’s GEM—initially developed for CP/M—and GEOS.

Later on, leading DOS distributors integrated their own environment management systems: MS-DOS/IBM DOS version 4 introduced DOS Shell, while DR DOS 5.0 shipped with ViewMAX, a GEM-based file manager.

Terminate and stay resident

While DOS does not inherently provide multitasking, it does allow the use of terminate-and-stay-resident (TSR) programs that persist in memory after execution. These TSR applications intercept system timers or keyboard interrupts to perform background operations or be activated at any moment, thereby enabling a rudimentary form of multitasking on an individual program level. For instance, the DOS PRINT utility utilizes TSR technology for background print spooling, and Borland Sidekick functions as a TSR-based popup personal information manager.

TSRs also serve to augment DOS functionality: tools such as CED and DOSKEY improve command-line editing capabilities beyond the standard features of COMMAND.COM, while Microsoft CD-ROM Extensions (MSCDEX) facilitate access to CD-ROM drives.

Certain TSRs provide elementary task-switching abilities; for example, the shareware application Back and Forth (1990) lets users save the active program’s state to disk and toggle between applications using hotkeys—although this method is hindered by slow disk operations and lacks genuine background processing, which requires advanced solutions like 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 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 Number 6183940
  • Mueller, Scott, Upgrading and Repairing PCs, 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

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