Jump to content

LPT2

From Alfawiki
DOS
Company typeOperating system family
IndustryComputer software
Predecessor86-DOS
Founded1981
ProductsIBM PC DOS, MS-DOS, DR-DOS, ROM-DOS, PTS-DOS, FreeDOS

DOS (, ) represents 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 introduced in 1981. Additional 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 sector from its inception until 1995.

Though frequently linked to MS-DOS, the term DOS is an acronym for disk operating system that is platform-neutral and predates the IBM PC era. Various other operating systems also utilize this acronym, such as DOS/360 (1966), Apple DOS, Atari DOS, and AmigaDOS.

Origins

IBM PC DOS and its forerunner, 86-DOS, operated on Intel 8086 16-bit processors. Designed to mimic Digital Research's CP/M, which was the leading OS for 8-bit microcomputers, DOS facilitated easier porting of CP/M applications to MS-DOS.

During the launch of the IBM PC featuring an Intel 8088 processor, IBM required an operating system. After unsuccessful licensing negotiations with Digital Research founder Gary Kildall, IBM approached Bill Gates. Microsoft purchased Seattle Computer Products' 86-DOS—created by Tim Paterson as a CP/M-80-style OS adapted for 16-bit CPUs—for roughly . This acquisition led to the release of MS-DOS in 1981.

Within a year, Microsoft had licensed MS-DOS to more than 70 companies, some of which marketed it under alternative names like Zenith Data Systems' Z-DOS. Microsoft later insisted on the exclusive use of the MS-DOS brand name, except for IBM’s PC DOS version. IBM continued to develop PC DOS, while Digital Research marketed CP/M-86 alongside it; however, CP/M’s higher price limited its market success.

Initially, Microsoft sold MS-DOS solely to original equipment manufacturers (OEMs), supplying an OEM Adaptation Kit (OAK) to tailor device drivers for hardware deviations. By the early 1990s, most personal computers adhered to IBM standards, allowing Microsoft to offer retail versions starting with MS-DOS 5.0.

In the mid-1980s, Microsoft created a multitasking variant of DOS known as "European MS-DOS 4" for International Computers Limited (ICL), featuring preemptive multitasking and shared memory support. These capabilities influenced the OS/2 1.0 kernel but were omitted from subsequent DOS editions.

Digital Research sought to reclaim market presence with products such as Concurrent DOS, FlexOS, Multiuser DOS, and DR DOS—all compatible with both MS-DOS and CP/M-86 applications. Following acquisitions by Novell and later Caldera, DR DOS continued development under different names including PalmDOS and OpenDOS.

Microsoft co-founder Gordon Letwin remarked in 1995 that DOS was originally intended as a temporary solution to satisfy IBM while Microsoft concentrated on Xenix—a multi-user UNIX-like system aimed at various CPU architectures. However, IBM preferred maintaining DOS; as a result, Microsoft and IBM collaborated on OS/2 as a successor platform but eventually parted ways due to conflicts over OS/2 and Windows development.

The final retail release of MS-DOS was version 6.22; thereafter, MS-DOS was integrated into Windows 95, 98, and Me. IBM’s last retail PC DOS edition was PC DOS 2000; subsequent releases were limited to OEM distribution or internal deployment.

The FreeDOS initiative commenced in June 1994 following Microsoft's discontinuation of MS-DOS sales and support. Spearheaded by Jim Hall along with other developers, FreeDOS aimed to deliver an open-source alternative under the GNU General Public License (GPL). Version 1.0 of FreeDOS became available in September 2006 without any licensing fees or royalties.

Decline

Initial iterations of Microsoft Windows operated atop MS-DOS. By the early 1990s, the Windows graphical interface had become the predominant environment on new computers. The 1995 launch of Windows 95 marked a shift to an independent operating system that no longer depended on a separate DOS license. Alongside Windows 98 and ME, Windows 95 established itself as the standard OS kernel, although MS-DOS persisted for backward compatibility. In Windows 95 and 98 (but not ME), the DOS portion could function separately from the Windows environment. As DOS ceased to be a necessity for running Windows, direct user interaction with it largely diminished.

Continued use

Compatible DOS variants available today include FreeDOS, ROM-DOS, PTS-DOS, RxDOS, and REAL/32. Certain vendors such as Dell and HP have offered systems preloaded with FreeDOS as an OEM operating system. Although such offerings have decreased since around 2008, FreeDOS remains favored by developers and engineers who appreciate its low-level hardware access.

Embedded systems

The architecture of DOS, with its direct control over hardware, makes it suitable for use in embedded devices. The latest releases of DR-DOS continue to focus on this sector. For example, ROM-DOS is employed as the operating system in devices like the Canon PowerShot Pro 70 camera.

Emulation

On Linux, DOSEMU allows execution of DOS applications at speeds close to native performance. Additional emulators, including DOSBox, provide DOS functionality on Unix-like systems and Microsoft Windows. DOSBox is primarily designed to run classic games (such as King's Quest and Doom) on contemporary platforms. It features an integrated DOS environment within the emulator but can also boot MS-DOS, FreeDOS, or other DOS variants if required.

Design

MS-DOS and IBM PC DOS are chiefly linked with Intel x86 or compatible processors, predominantly within the realm of IBM PC compatible hardware. There were machine-specific MS-DOS editions created for non-IBM-compatible x86 computers, ranging from simple rebranding efforts to versions customized for specialized hardware configurations. Software utilizing DOS APIs was capable of running on both compatible and incompatible systems. The original kernel of FreeDOS, known as DOS-C, originated from DOS/NT designed for Motorola 68000 CPUs but lacked binary compatibility due to differing instruction sets; nonetheless, applications written in high-level languages were relatively easy to port.

As a single-user, single-task operating system with non-reentrant kernel functions, DOS permits only one program to execute at any given moment. Its kernel provides an API supporting character input/output, file handling, memory management, program execution, and termination.

Batch files (.BAT) facilitate shell scripting by incorporating internal commands such as GOTO and conditional statements.

Although DOS offers an API tailored for character-mode software, it does not include standardized interfaces for most hardware components like graphics adapters, printers, or pointing devices. Consequently, programmers often accessed hardware directly. This practice led many applications to bundle their own device drivers for peripherals, with hardware manufacturers releasing specifications to ensure compatibility with popular software titles.

Boot sequence

  • On systems compatible with PCs, the bootstrap loader is located within the master boot record (MBR) at the boot sector, which is the initial sector of the bootable disk. The ROM BIOS loads this sector into memory at :, then verifies the presence of a signature "" at offset . If the signature is missing or invalid, it attempts to boot from the next available disk; if valid, execution jumps to the designated load address.
  • When the boot sector contains an MBR on partitioned storage, it relocates itself to :, examines the partition table to identify the active partition, and loads that partition’s first sector—the Volume Boot Record (VBR)—into memory at :. Control is then transferred accordingly.
  • The VBR is tailored to a specific operating system and typically lacks compatibility across different DOS versions. Early DOS releases (such as DOS 1.x) loaded the entire IO.SYS/IBMBIO.COM file into memory at :, necessitating that these files be stored contiguously on disk. Later iterations load initial portions of these files into memory first and use directory entries to complete loading, preserving the Disk Parameter Table (DPT) as required before passing control.
  • In newer DOS versions, a secondary boot loader embedded within IO.SYS/IBMBIO.COM finalizes loading the remainder of itself from disk, generally requiring contiguous file placement. This step is omitted in earlier versions.
  • Subsequent DOS initialization loads built-in device drivers along with the core DOS kernel (MSDOS.SYS in MS-DOS). In Windows 9x, these components are merged into IO.SYS, with MSDOS.SYS functioning as a configuration file.
  • The system parses CONFIG.SYS for configuration directives; its variable defines the shell’s path, defaulting to COMMAND.COM.
  • The shell is then loaded and executed, followed by running the startup batch script AUTOEXEC.BAT.
  • DOS system files loaded by the boot sector must be contiguous and occupy the first two directory entries. Modifying these files risks making the media unbootable; however, substituting the shell can accelerate startup for dedicated applications. This restriction does not apply to DR DOS, where system files can be located anywhere in the root directory without contiguity constraints if supported by the 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 editions used DRBIOS.SYS and DRBDOS.SYS instead.
  • Beginning with MS-DOS 7.0, IO.SYS and MSDOS.SYS binaries were consolidated into IO.SYS; MSDOS.SYS became a configuration file similar in role to CONFIG.SYS. Setting the MSDOS.SYS BootGUI parameter to 0 stops booting after loading COMMAND.COM rather than automatically launching WIN.COM.

File system

DOS utilizes a filesystem supporting 8.3 filename conventions: filenames limited to 8 characters plus a 3-character extension. From DOS 2 onward, hierarchical directories were introduced, also adhering to 8.3 naming rules, with an internal current directory structure (CDS) limiting full path lengths to 64 characters. Including drive letters, DOS supports fully qualified filenames up to 80 characters in length (drive:\path\filename.ext).

The filesystem employed by DOS is based on the File Allocation Table (FAT). Initially, FAT12 allowed up to 4,078 clusters per volume. DOS 3.0 brought in FAT16, which uses 16-bit entries and supports up to 65,518 clusters. With Compaq MS-DOS 3.31 came FAT16B, which removed the prior 32 MiB volume size limit and enabled support for drives up to 512 MiB. MS-DOS 7.1 (distributed with Windows 9x) introduced FAT32, expanding support for drives beyond 137 GiB.

Starting with DOS 3.1, file redirector functionality provided networking capabilities and later CD-ROM support via MSCDEX. IBM PC DOS 4.0 included preliminary installable file system (IFS) support, which was removed in DOS 5.0. Additionally, DOS supported Block Devices loaded through CONFIG.SYS for integrating network hardware.

Drive letter assignment scheme

Within DOS, storage devices are designated by alphabetical letters. The letters "A" and "B" are traditionally allocated to floppy drives, and systems equipped with a single floppy drive often assign both letters to facilitate disk swapping. Hard drives typically begin with the letters "C" and "D". DOS supports only one active partition per physical drive; drive letters are first distributed to active primary partitions, followed by logical drives within extended partitions, and then to inactive primary partitions formatted with compatible filesystems. Subsequent letter assignments go to optical drives, RAM disks, and other hardware components, generally following the sequence in which their drivers load, though driver software can alter this order. Network drives usually receive letters from the latter part of the alphabet.

Because DOS programs directly reference drives by their assigned letters, introducing new hardware can disrupt the existing letter assignments. For instance, adding a new hard disk containing an active primary partition may reassign letters previously allocated to logical drives on other disks. This challenge remained present throughout DOS-based Windows 9x editions but was resolved in NT-based Windows versions, which maintain drive letter consistency unless manually changed by users. Common DOS workarounds include creating SUBST drives or launching applications through batch scripts that assign logical drive letters dynamically. Certain multitasking DOS variants automatically reserve the letter L: for the drive from which applications are loaded when they start.

Device name restrictions

DOS enforces a set of reserved device names that cannot be used as filenames, regardless of file extension, because they correspond to internal character devices. These constraints continue across multiple Windows versions and have occasionally resulted in system crashes or security vulnerabilities.

The reserved device names consist of:

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

In Windows 95 and 98, attempting to use these reserved names within file paths could cause system crashes; Microsoft subsequently issued security updates to address this. Windows XP silently renames such files without alerting the user, whereas Windows Vista and later versions display an error message when these names are used.

With the exception of NUL, these reserved names remain supported across MS-DOS, PC DOS, and DR-DOS releases. Some OEM variants of MS-DOS also included additional aliases like LST and PLT. Later or multitasking versions of DOS introduced support for devices such as CLOCK$, KEYBD$, and SCREEN$. Starting with DR DOS 5.0, a special device named $IDLE$ was added for power management purposes.

By default, AUX is mapped to COM1, and PRN to LPT1, though some DOS versions allow these mappings to be redirected to other serial or parallel devices. While device names are commonly followed by a colon (e.g., NUL:) as a notation convention, the colon itself is not part of the device identifier.

Despite these naming restrictions, it is possible—through direct disk editing—to create files or directories named after reserved devices. This technique has sometimes been exploited by malicious software to conceal files from users.

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 allocated 640 KiB for application use, reserving the remaining 384 KiB for video memory, adapter ROMs, and BIOS components. By the mid-1980s, some DOS applications had reached this memory ceiling, although much of the reserved space often remained unused depending on the hardware configuration.

To increase accessible memory, standards such as the Expanded Memory Specification (EMS) enabled programs to utilize extra memory through a 64 KiB page frame within the upper memory region. With the arrival of the 80386 processor, virtual 8086 mode managers like EMM386 introduced expanded memory capabilities derived from extended memory without requiring additional hardware. The Extended Memory Specification (XMS), designed for the 80286 and later processors, facilitated data transfers to extended memory and allowed access to the high memory area above 1 MiB. Typically, XMS functionality was activated via HIMEM.SYS or virtual 8086 mode managers such as QEMM and 386MAX, which also provided EMS support.

Beginning with DOS version 5, the operating system gained the ability to load its core kernel and disk buffering routines into the high memory area through the DOS=HIGH directive in CONFIG.SYS. Additionally, upper memory blocks could be utilized using DOS=UMB, thereby freeing up more conventional memory for applications.

DOS under OS/2 and Windows

DOS emulation within OS/2 and Windows environments functions much like native application execution, granting access to drives, system services, and clipboard operations. This emulation layer converts DOS API requests into corresponding OS/2 or Windows system calls, emulates BIOS interrupts, and controls I/O port interactions commonly required by DOS software.

In Windows versions 3.1 and 9x, DOS virtual machines are managed by WINOLDAP, which establishes a virtualized environment based on program information files (PIFs). This setup supports DOS graphics modes inside windowed interfaces and enables clipboard sharing between DOS and Windows applications.

OS/2’s approach to DOS emulation relies on DOSKRNL, which merges functionalities of IBMBIO.COM and IBMDOS.COM while redirecting system calls to OS/2 services. DOS programs execute within isolated sessions supported by utilities integrated into combined DOS/OS2 applications. Furthermore, OS/2 can run Windows 3.1 software through a customized Windows version known as Win-OS/2, allowing either seamless integration or separate desktop operation.

Additionally, OS/2 permits booting genuine DOS environments—such as MS-DOS 6.22—from floppy disk images enhanced with OS/2 drivers. This method offers full hardware access, including support for CD-ROM drives that OS/2 itself does not natively recognize.

Windows NT (32-bit IA-32 editions since 1993) provides DOS compatibility through the virtual DOS machine (NTVDM). However, its 64-bit variants lack NTVDM support and cannot execute 16-bit DOS programs directly; users must rely on third-party solutions like DOSBox for such functionality.

User interface

DOS systems employ a command-line interface, where users launch programs by typing filenames at a prompt. The environment includes both internal commands embedded within the shell and external utility programs.

To improve user experience, numerous software developers created file management tools featuring WIMP graphical interfaces. Microsoft Windows notably evolved into an independent loader that supplanted DOS as the primary program loader on PC-compatible machines. Among text-based interfaces were Norton Commander, DOS Navigator, and Volkov Commander, while graphical environments included Digital Research’s GEM and GEOS.

Leading DOS vendors eventually incorporated their own environment managers: MS-DOS/IBM DOS version 4 introduced DOS Shell, whereas DR DOS 5.0 shipped with ViewMAX, a graphical shell derived from GEM.

Terminate and stay resident

Although DOS does not inherently support multitasking, its terminate-and-stay-resident (TSR) capability permits programs to remain loaded in memory. These TSR programs intercept system interrupts, allowing them to perform background functions or be activated on demand. For instance, the DOS PRINT utility leverages TSR technology for background spooling, while Borland Sidekick, a popup personal organizer, utilizes this approach.

TSRs provide enhancements that surpass the standard DOS functionality. Tools such as CED and DOSKEY improve command-line editing features, and the Microsoft CD-ROM Extensions (MSCDEX) facilitate access to CD-ROM drives.

Certain TSR applications offer limited task switching abilities. The shareware utility Back and Forth (1990) enabled users to save a program’s state to disk, load another application, and switch between them—though this process was relatively slow due to reliance on disk operations. Genuine multitasking required more advanced solutions like DESQview, which operated on systems with 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 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