Jump to content

LPT1

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

DOS (, ) represents a series of disk-based operating systems designed for IBM PC compatible machines. The primary members of this family include IBM PC DOS and Microsoft's adapted version, MS-DOS, both launched in 1981. Additional compatible variants encompass DR-DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1994). From 1981 until 1995, MS-DOS maintained a leading position in the IBM PC compatible market.

Although the term "DOS" is frequently associated specifically with MS-DOS and its derivatives, it is actually an acronym for disk operating system that predates the IBM PC era. Various other operating systems have adopted this abbreviation, including the mainframe DOS/360 from 1966, as well as Apple DOS, Atari DOS, and AmigaDOS.

Origins

The foundation of IBM PC DOS and its forerunner, 86-DOS, was built to operate on Intel 8086 16-bit processors. These systems were engineered to emulate Digital Research’s widely used CP/M platform for 8-bit microcomputers, thereby facilitating easier adaptation of CP/M programs to MS-DOS.

When IBM introduced the IBM PC featuring an Intel 8088 CPU, they required an operating system. Initially, IBM approached Digital Research to license CP/M, but negotiations faltered due to disagreements over licensing conditions and naming rights. Subsequently, IBM engaged Bill Gates, who acquired a CP/M-like OS known as QDOS (Quick and Dirty Operating System) from Seattle Computer Products, created by Tim Paterson. Microsoft purchased QDOS for $50,000 and launched it as MS-DOS in 1981.

Within twelve months, Microsoft had licensed MS-DOS to more than seventy original equipment manufacturers (OEMs), many of whom sold it under their own branding—for example, Zenith Data Systems distributed it as Z-DOS. Microsoft later mandated the use of the MS-DOS brand name except for IBM’s version, which IBM continued to develop under the name PC DOS. In response, Digital Research introduced CP/M-86 alongside PC DOS; however, CP/M-86’s higher cost restricted its market penetration. Consequently, MS-DOS and PC DOS emerged as the prevailing operating systems for PCs and compatibles.

Initially, Microsoft offered MS-DOS exclusively to OEMs because early personal computers lacked full IBM PC compatibility. The DOS architecture separated hardware-specific device drivers (IO.SYS) from the core kernel (MSDOS.SYS), enabling OEMs to customize their versions through Microsoft’s OEM Adaptation Kit (OAK). By the early 1990s, as hardware standards converged, Microsoft began retailing MS-DOS starting with version 5.0.

During the mid-1980s, Microsoft developed a multitasking variant of DOS known as "European MS-DOS 4" tailored for International Computers Limited (ICL) and several European firms. This edition featured preemptive multitasking and shared memory capabilities but was distinct from the broadly distributed IBM PC DOS 4.0 and served as a foundation for the OS/2 1.0 kernel.

Digital Research sought to reclaim market presence with products like Concurrent DOS, FlexOS, DOS Plus, Multiuser DOS, and DR DOS—all compatible with MS-DOS or CP/M-86 applications. Following acquisitions by Novell and later Caldera, DR DOS underwent several rebrandings including PalmDOS and OpenDOS.

In 1995, Gordon Letwin revealed that DOS was originally intended as a temporary solution to satisfy IBM until Xenix could be introduced. Microsoft's strategy involved incremental enhancements aiming to align MS-DOS with single-user Xenix versions that supported multiple CPU platforms.

IBM opted to maintain DOS rather than replace it outright; after AT&T started marketing Unix systems, Microsoft and IBM collaborated on OS/2 as an alternative platform. However, conflicts over OS/2 and Windows development led to a division in their DOS efforts. The final standalone retail release of MS-DOS was version 6.22 before being incorporated into Windows 95/98/Me; IBM’s last retail PC DOS edition was version 2000.

The FreeDOS initiative commenced in June 1994 following Microsoft's announcement that it would discontinue sales and support of MS-DOS. Jim Hall spearheaded the creation of an open-source substitute licensed under the GNU General Public License (GPL). FreeDOS integrated kernels, command interpreters (COMMAND.COM), and utilities contributed by developers such as Pat Villani and Tim Norman. The official FreeDOS 1.0 release occurred in September 2006 without any associated licensing fees or royalties.

Decline

Initial iterations of Microsoft Windows operated atop MS-DOS. By the early 1990s, Windows' graphical interface had become widely adopted. The 1995 launch of Windows 95 marked its emergence as an independent operating system, removing the necessity for a separate DOS license. Alongside Windows 98 and ME, Windows 95 established itself as the default OS kernel, although MS-DOS persisted for backward compatibility. In Windows 95 and 98 (but not ME), the MS-DOS layer could function independently from Windows. As reliance on DOS diminished, direct user interaction with it largely ceased.

Continued use

Currently, compatible alternatives include FreeDOS, ROM-DOS, PTS-DOS, RxDOS, and REAL/32. Some vendors, such as Dell and HP, have offered systems preloaded with FreeDOS as an OEM operating system. Although Dell appears to have phased out FreeDOS preinstallations since 2008, certain developers and engineers maintain use of DOS variants due to their low-level hardware interfacing capabilities.

Embedded systems

Due to its straightforward hardware access model, DOS remains suitable for embedded device applications. The latest DR-DOS releases continue to focus on this niche. ROM-DOS functions as the operating system in products such as the Canon PowerShot Pro 70.

Emulation

Under Linux, DOSEMU offers a native virtual environment enabling DOS programs to run at speeds close to native performance. Other emulators like DOSBox provide DOS support on Unix and Microsoft Windows platforms. DOSBox primarily targets classic gaming titles (for example, King's Quest and Doom) on contemporary systems. It incorporates its own DOS implementation linked with the emulator but can also boot MS-DOS, FreeDOS, or other DOS variants when necessary.

Design

MS-DOS and IBM PC DOS are mainly linked with Intel x86 or compatible processors, predominantly on IBM PC compatible hardware. Distinct MS-DOS versions tailored for non-IBM-compatible x86 machines existed, ranging from Microsoft rebranded editions to specialized releases for unique hardware configurations. Software utilizing DOS APIs could operate across both compatible and incompatible devices. The original FreeDOS kernel, named DOS-C, was derived from DOS/NT designed for Motorola 68000 CPUs; however, it lacked binary compatibility due to differing instruction sets. Applications written in high-level languages were easier to adapt between platforms.

As a single-user, single-tasking operating system, DOS features a simple kernel with non-reentrant functions—only one application executes at any moment. Its kernel exposes an application programming interface (API) that supports character input/output, file and memory handling, and program control.

Batch files (.BAT) facilitate shell scripting by executing commands sequentially and include internal instructions such as GOTO and conditional branching.

Although DOS provides an API for text-based application development, it does not offer standardized access to most hardware components like graphics adapters, printers, or pointing devices. As a result, developers frequently interacted directly with hardware, necessitating custom device drivers for individual applications. Hardware manufacturers supplied documentation to assist in creating drivers compatible with widely used software.

Boot sequence

  • On PC-compatible systems, the bootstrap loader resides in the master boot record (MBR), located at the boot sector, which is the initial sector of the boot disk. The ROM BIOS loads this sector into memory at address :, then verifies a signature "" at offset . If the signature is absent or invalid, it attempts to boot from the next physical disk; if valid, control is transferred to the loaded code with registers appropriately initialized.
  • When the boot sector contains an MBR, it relocates itself to : and examines the partition table to identify an active partition. Upon locating one, it loads that partition's first sector—the Volume Boot Record (VBR)—into memory at :, then hands over execution to it.
  • The VBR is tailored to a specific operating system and typically cannot be interchanged between different DOS versions. Early releases of DOS (such as DOS 1.x) load the entire IO.SYS/IBMBIO.COM file into memory at :, necessitating that these files occupy consecutive sectors on disk. Later iterations read root directory entries into memory and load only the initial sectors of IO.SYS/IBMBIO.COM accordingly, while preserving the Disk Parameter Table (DPT) before passing control.
  • In more recent DOS versions, the VBR loads just a few initial sectors of IO.SYS/IBMBIO.COM, which contains a secondary loader responsible for fetching the remainder using root directory information. Earlier DOS editions bypass this by loading the entire file in one step.
  • The DOS system initialization routines then activate built-in device drivers and load the DOS kernel (located in MSDOS.SYS for MS-DOS). In Windows 9x, these components are merged into IO.SYS, with MSDOS.SYS functioning as a configuration file.
  • The CONFIG.SYS configuration file is processed to set system parameters; the variable designates the shell executable location, defaulting to COMMAND.COM.
  • The shell program is subsequently loaded and executed.
  • Lastly, the startup batch script AUTOEXEC.BAT runs automatically.

DOS system files loaded by the boot sector must be stored contiguously and occupy the first two entries in the FAT directory table. Adding or removing these files can make the media unbootable. However, substituting the shell can accelerate startup for specialized applications. This restriction does not apply to DR DOS, where system files can reside anywhere within the root directory and do not need to be contiguous—facilitating straightforward copying onto compatible disks.

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

Beginning with MS-DOS 7.0, IO.SYS and MSDOS.SYS were consolidated into a single IO.SYS file; MSDOS.SYS was repurposed as a configuration file similar in function to CONFIG.SYS and AUTOEXEC.BAT. If its BootGUI setting is configured to 0, booting halts after loading the command interpreter (usually COMMAND.COM), rather than automatically starting WIN.COM.

File system

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

The underlying filesystem employed by DOS is based on the File Allocation Table (FAT) scheme. Initially, FAT12 was used, allowing up to 4,078 clusters per volume. DOS 3.0 brought in FAT16, which uses 16-bit allocation entries supporting up to 65,518 clusters. The Compaq MS-DOS 3.31 version introduced FAT16B, lifting the previous 32‑MiB size limit and enabling support for volumes up to 512 MiB. With MS-DOS 7.1 (part of Windows 9x), FAT32 was implemented using 32-bit entries, extending support for hard drives up to and beyond 137 GiB.

From DOS version 3.1 onward, support for file redirectors facilitated networking capabilities and CD-ROM access via MSCDEX. IBM PC DOS 4.0 included early support for installable file systems (IFS), which was later removed in DOS 5.0. Additionally, DOS supported Block Devices loaded through CONFIG.SYS for integrating network devices within its filesystem architecture.

Drive letter assignment system

In DOS environments, storage devices are designated by letters, with the letters "A" and "B" specifically reserved for floppy drives. When a system contains only a single floppy drive, both letters may be assigned to it to enable disk swapping during tasks such as copying files or running programs from one floppy while accessing data on another. Initially, hard drives were assigned the letters "C" and "D". DOS allows only one active partition per physical drive; drive letter allocation prioritizes active primary partitions first, followed by logical drives within extended partitions, then inactive primary partitions formatted with supported filesystems. Subsequently, letters are given to optical disc drives, RAM disks, and other hardware devices. Typically, letter assignments correspond to the order in which drivers load, although certain drivers can override this sequence—for example, network drivers often assign letters toward the end of the alphabet.

Because DOS applications rely on direct drive letter references rather than device files like Unix's /dev system, introducing new hardware can alter existing letter assignments. For example, adding a new hard disk with a primary partition may cause previously assigned letters—used by logical drives in extended partitions or devices such as RAM disks and optical drives—to shift. This challenge remained present through Microsoft's DOS-based Windows 9x series but was resolved in NT-based Windows versions that maintain existing drive letter mappings unless manually changed by users. Under DOS, common workarounds include defining SUBST drives or launching programs through batch scripts that reassign logical drive letters. Some multitasking DOS variants automatically allocate the reserved letter L: to the drive from which applications are loaded when they start.

System-reserved device names

DOS defines a set of reserved device names that cannot be used as filenames regardless of their extensions because they correspond to internal character devices. These restrictions continue to exist in multiple Windows versions and have occasionally led to system crashes or security issues.

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, attempts to use these reserved names within file paths could cause system crashes; Microsoft addressed these issues with security patches. Windows XP silently converts such filenames without displaying errors, whereas Windows Vista and subsequent versions present an error message when usage is attempted.

All MS-DOS, PC DOS, and DR-DOS editions continue to support these reserved names except for NUL. Some original equipment manufacturer (OEM) MS-DOS variants also included additional aliases like LST and PLT. Over time, DOS extended support for more devices such as additional COM and LPT ports and introduced special device names like CLOCK$, KEYBD$, and power management idle detection devices found in later multitasking or multiuser DOS systems.

By default, AUX maps to COM1 and PRN to LPT1, though configuration changes are possible in some DOS versions. Device names traditionally conclude with a colon (:) to signify device access; however, this colon is not part of the underlying driver name.

Despite these constraints, it remains technically feasible to create files or directories using these reserved names by directly manipulating disk structures—a method sometimes utilized by malware to hide files from standard user views.

Memory management

DOS was originally created for the Intel 8088 CPU, which supports direct access to a maximum of 1 MiB of RAM. Out of this, IBM and Microsoft allocated 640 kibibytes (KiB) for application use, reserving the remaining 384 KiB for video memory, adapter ROM, and BIOS functions. By the mid-1980s, certain DOS programs began to encounter this memory ceiling, although a significant portion of the reserved memory often remained unused depending on the hardware configuration.

To overcome these limitations, standards such as the Expanded Memory Specification (EMS) were introduced, allowing memory on expansion cards to be accessed through a 64 KiB page frame located in upper memory. Systems equipped with 80386 or newer processors leveraged virtual 8086 mode managers like EMM386 to simulate expanded memory by utilizing extended memory without requiring additional hardware. The Extended Memory Specification (XMS), applicable to 80286 and later processors, enabled data transfers to extended memory as well as access to the 65,520-byte high memory area and upper memory blocks. Support for XMS was commonly provided by drivers such as HIMEM.SYS or virtual 86 mode managers like QEMM and 386MAX, which also offered EMS compatibility.

Beginning with DOS version 5, users could load the kernel and disk caching buffers into the high memory area by specifying DOS=HIGH in CONFIG.SYS, while upper memory blocks could be utilized through DOS=UMB settings.

DOS under OS/2 and Windows

DOS emulation within OS/2 and Windows functions similarly to native applications, granting access to drives, system services, and the host clipboard. This emulation layer translates DOS API calls into corresponding OS/2 or Windows system calls, including BIOS interactions and input/output port virtualization.

In Windows versions 3.1 and 9x, the DOS virtual machine is managed by WINOLDAP, which establishes a virtualized environment based on program PIF files and the system's state at startup. This setup supports running DOS graphics modes inside windows and allows clipboard sharing between DOS applications and Windows.

The DOS emulation present in OS/2 and Windows NT is derived from DOS version 5. It permits users to specify alternative configuration files on a per-session basis and load third-party drivers to enable access to host resources.

Starting with OS/2 version 2.x, DOS emulation is handled by DOSKRNL, which merges the capabilities of IBMBIO.COM and IBMDOS.COM with OS/2’s windowing services. Integrated DOS utilities are accessible through DOS/OS2 applications located in the \OS2 directory. OS/2 can also run Windows 3.1 applications via Win-OS/2—a modified Windows release that either integrates seamlessly with OS/2 or operates in a separate desktop environment.

Additionally, OS/2 supports "DOS from Drive A:" (VMDISK), which boots a genuine DOS environment similar to MS-DOS 6.22 or PC DOS 5.00 from a floppy disk image enhanced with OS/2 drivers. This provides full access to hardware through its own drivers, making it valuable for interacting with devices not supported directly by OS/2.

All 32-bit editions of Windows NT since their introduction in 1993 employ a virtual DOS machine (NTVDM) for running DOS applications. However, 64-bit versions of Windows do not include NTVDM support and thus cannot natively execute 16-bit DOS programs; users must rely on third-party emulators like DOSbox in these cases.

User interface

DOS systems operate through a command-line interface, where users launch programs by typing their filenames at the prompt. The operating system provides both built-in commands and external utility programs beyond standalone executables.

To improve user interaction, various vendors developed file management software featuring WIMP-style graphical interfaces. Microsoft’s Windows evolved into an integrated program loader, with Windows 9x eventually superseding DOS as the primary PC-compatible boot environment. Among popular text-based interfaces were Norton Commander, DOS Navigator, Volkov Commander, Quarterdeck’s DESQview, and Sidekick. Graphical shells included Digital Research’s GEM, originally from CP/M roots, as well as GEOS.

Leading DOS distributors later incorporated their own environment managers: MS-DOS/IBM DOS version 4 introduced DOS Shell, while DR DOS 5.0 featured ViewMAX, a GEM-based interface.

Terminate-and-stay-resident (TSR) programs

While DOS does not inherently support multitasking, it allows for terminate-and-stay-resident (TSR) applications that remain loaded in memory. These programs intercept system interrupts to perform background operations or can be activated on demand. For instance, the DOS PRINT utility utilizes TSR technology to manage print spooling in the background, and Borland Sidekick, a popup personal information manager (PIM), operates using this approach.

TSRs also enhance DOS by adding new features; tools such as CED and DOSKEY improve command-line editing beyond the native capabilities of COMMAND.COM, while Microsoft CD-ROM Extensions (MSCDEX) provide access to CD-ROM drives.

Certain TSRs provide limited task-switching functionality: the shareware application Back and Forth (1990) enables users to save the current program state to disk and switch between applications using hotkeys. However, this does not constitute true multitasking, which was achievable only with software like DESQview running on processors starting from the 386 series.

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.
  • Bailes, Lenny & Mueller, John. Memory Management and Multitasking Beyond 640K. McGraw-Hill, 1992.

External links

Retrieved from "https://www.alfawiki.org/index.php?title=LPT1&oldid=29056"