Jump to content

LPT3

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 (, ) refers to a collection of disk-based operating systems designed for IBM PC compatible machines. The core members of this group 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 sector from 1981 until 1995.

Although often linked with MS-DOS, the term DOS is an abbreviation for disk operating system and existed before the IBM PC era. Various other systems have employed this acronym, beginning with the mainframe DOS/360 released in 1966, as well as systems like Apple DOS, Apple ProDOS, Atari DOS, Commodore DOS, TRSDOS, and AmigaDOS.

Origins

IBM PC DOS and its antecedent, 86-DOS, operated on Intel 8086 16-bit CPUs. These were designed to mimic Digital Research’s prominent CP/M system for 8-bit microcomputers, which eased the process of adapting CP/M applications to run on MS-DOS.

When IBM was developing the IBM PC featuring the Intel 8088 processor, they required an operating system. Chairman John Opel was introduced to Bill Gates through Mary Maxwell Gates. IBM initially entered negotiations with Digital Research to license CP/M, but discussions collapsed due to disagreements over licensing conditions and naming rights. Digital Research’s founder Gary Kildall declined IBM’s terms, prompting IBM to withdraw.

Subsequently, IBM turned to Bill Gates, who procured a CP/M-like OS from Seattle Computer Products created by Tim Paterson. Originally named QDOS (Quick and Dirty Operating System), Microsoft purchased it for about $50,000 and rebranded it as MS-DOS in 1981. Within a year, Microsoft licensed MS-DOS to more than 70 companies, many of which sold it under their own brand names such as Zenith Data Systems’ Z-DOS. Microsoft mandated the use of the MS-DOS name except for IBM’s version, known as PC DOS. In response, Digital Research released CP/M-86 alongside PC DOS; however, its higher cost limited its adoption.

Initially, Microsoft sold MS-DOS exclusively to original equipment manufacturers (OEMs), supplying an OEM Adaptation Kit that allowed hardware-specific customization. By the early 1990s, as IBM PC compatibility became widespread, Microsoft began retailing MS-DOS starting with version 5.0.

During the mid-1980s, Microsoft developed a multitasking variant of DOS—referred to as "European MS-DOS 4"—for International Computers Limited and other European firms. This version featured preemptive multitasking and shared memory support, innovations that influenced the OS/2 kernel but were not incorporated into subsequent DOS releases. This differs from IBM’s widely distributed PC DOS 4.0, which was based on DOS 3.3.

Digital Research aimed to reclaim market presence with products compatible with both MS-DOS and CP/M-86 applications, including Concurrent DOS, FlexOS, Multiuser DOS, and DR DOS. After being acquired by Novell, DR DOS progressed through iterations like PalmDOS and Novell DOS; later ownership passed to Caldera (as OpenDOS), Lineo, and DeviceLogics.

Gordon Letwin remarked in 1995 that DOS was originally intended as a temporary solution to satisfy IBM while Microsoft concentrated on Xenix development. Microsoft planned for MS-DOS to evolve toward compatibility with single-user versions of Xenix across various processor platforms.

IBM preferred maintaining DOS rather than replacing it outright; after AT&T began marketing Unix systems, Microsoft and IBM collaborated on OS/2 as an alternative but eventually parted ways due to conflicting priorities between OS/2 and Windows development. This divergence resulted in separate paths for DOS systems. The final retail version of MS-DOS was 6.22; later editions were bundled within Windows 95, 98, and Me. IBM’s last retail PC DOS release was version 2000; subsequent releases were OEM or internal only.

The FreeDOS initiative commenced in June 1994 after Microsoft discontinued sales and support for MS-DOS. Jim Hall spearheaded development of an open-source alternative licensed under the GNU General Public License (GPL). Contributors combined efforts to build a kernel, command interpreter, and utilities. FreeDOS 1.0 was officially launched in September 2006 without any licensing fees or royalties.

Decline

Initial editions of Microsoft Windows operated atop MS-DOS. By the early 1990s, the graphical interface of Windows had achieved extensive acceptance. The 1995 release of Windows 95 marked its debut as an independent operating system, removing the necessity for a separate DOS license. Windows 95 and its follow-ups (Windows 98 and ME) became the primary OS kernel, although MS-DOS persisted for compatibility reasons. While Windows 95 and 98 allowed the MS-DOS component to function independently, this capability was absent in ME. As Windows no longer depended on DOS, direct usage of MS-DOS by most users declined significantly.

Continued use

Currently, compatible alternatives include FreeDOS, ROM-DOS, PTS-DOS, RxDOS, and REAL/32. Some OEMs, such as Dell and HP, have shipped systems with FreeDOS pre-installed as the default operating system. Despite a reduction in availability since 2008, FreeDOS continues to be favored by developers and engineers who require low-level access to hardware.

Embedded systems

The architecture of DOS, which allows direct hardware interaction, makes it suitable for use in embedded devices. The latest versions of DR-DOS specifically target this sector. ROM-DOS is employed as the OS in devices like the Canon PowerShot Pro 70.

Emulation

On Linux, DOSEMU enables execution of DOS applications at speeds close to native performance. Other emulators, including DOSBox, facilitate running DOS on Unix and Microsoft Windows platforms. DOSBox primarily focuses on supporting legacy games (such as 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.

Design

MS-DOS and IBM PC DOS predominantly run on Intel x86 or compatible processors, especially within the IBM PC compatible ecosystem. There were machine-specific MS-DOS versions for non-IBM-compatible x86 hardware, ranging from rebranded Microsoft editions to versions customized for specialized equipment. Applications that utilized DOS APIs could operate across both compatible and incompatible hardware. The original kernel of FreeDOS, known as DOS-C, was derived from DOS/NT designed for Motorola 68000 CPUs; it shared architectural similarities with DOS but lacked binary compatibility due to differing instruction sets. Porting applications written in high-level languages was comparatively straightforward.

DOS is a single-user, single-task operating system featuring non-reentrant kernel functions—only one program executes at any given time. Its kernel exposes an API facilitating character input/output, file and memory management, as well as process control.

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

While DOS provides APIs for character-mode applications, it does not offer standard interfaces for most hardware components (e.g., graphics adapters, printers, mice), requiring programmers to access devices directly. Consequently, many applications included their own device drivers for peripherals. Hardware vendors typically supplied specifications to enable popular application drivers.

Boot sequence

  • On PC-compatible machines, the boot process begins with the bootstrap loader located in the first sector (boot sector) of the bootable disk—the master boot record (MBR). The system's ROM BIOS loads this sector into memory at address :, then verifies a signature "" at offset . If the signature is invalid, BIOS attempts booting from another disk; if valid, execution jumps to the loaded code with registers initialized.
  • When dealing with partitioned media, if the loaded sector is an MBR, it relocates to address : in memory. The MBR code scans the partition table to find an active partition and loads its initial sector—the Volume Boot Record (VBR)—into :, then transfers control there.
  • The VBR varies between DOS versions and is generally not cross-compatible. Early DOS releases (such as DOS 1.x) loaded the entire IO.SYS or IBMBIO.COM file into memory at :, requiring contiguous disk sectors. Later versions store the first two root directory entries at : and load initial sectors of IO.SYS/IBMBIO.COM accordingly while preserving the Disk Parameter Table (DPT). Control is then handed off to this code.
  • More recent DOS iterations employ a secondary boot loader after loading initial IO.SYS/IBMBIO.COM sectors to load the remaining file using root directory information. Older versions bypass this by loading the entire file at once.
  • Following this, DOS initialization loads built-in device drivers along with the DOS kernel (MSDOS.SYS in MS-DOS). In Windows 9x systems, these components are combined within IO.SYS; MSDOS.SYS functions as a configuration file.
  • The system parses configuration directives from CONFIG.SYS, where the variable specifies the shell's path—defaulting to COMMAND.COM.
  • Subsequently, the shell is loaded and executed.
  • Lastly, under the shell environment, the startup batch script AUTOEXEC.BAT runs.

System files loaded by the boot sector must be stored contiguously and occupy the initial two entries in the FAT directory table. Modifying these files can prevent successful booting; however, substituting the shell can accelerate startup for dedicated applications. This constraint does not apply to DR DOS systems where system files may reside anywhere within the root directory if boot sector compatibility is maintained.

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

Beginning with MS-DOS 7.0, IO.SYS and MSDOS.SYS binaries were merged into a single IO.SYS file; MSDOS.SYS became a configuration file analogous to CONFIG.SYS and AUTOEXEC.BAT. Setting MSDOS.SYS's BootGUI parameter to 0 halts booting after loading COMMAND.COM instead of automatically starting WIN.COM.

File system

DOS utilizes a filesystem that enforces the 8.3 filename convention, allowing filenames of up to 8 characters plus a 3-character extension. Starting with DOS 2, support for hierarchical directories was introduced, each directory adhering to the 8.3 naming format. Due to internal limitations in directory structures, the maximum path length is capped at 64 characters. When including the drive letter, DOS permits fully qualified paths up to 80 characters, formatted as drive:\path\filename.ext.

The underlying filesystem for DOS is the File Allocation Table (FAT). Initially, FAT12 was used, accommodating up to 4,078 clusters per volume. With DOS 3.0, FAT16 was implemented, which uses 16-bit entries and supports as many as 65,518 clusters. The introduction of Compaq MS-DOS 3.31 brought FAT16B, eliminating the previous 32 MiB partition size limit and enabling volumes up to 512 MiB. Later, MS-DOS 7.1—bundled with Windows 9x—added support for FAT32, featuring 32-bit cluster entries and allowing partitions exceeding 137 GiB.

Networking capabilities began with DOS 3.1 through file redirector support, eventually extending to CD-ROM access via MSCDEX. IBM PC DOS 4.0 offered early installable file system (IFS) functionality, which was discontinued in DOS 5.0. Additionally, DOS could integrate Block Devices loaded from CONFIG.SYS to support network hardware.

Drive naming scheme

DOS assigns drive identifiers using letters, reserving "A" and "B" exclusively for floppy drives. In systems equipped with a single floppy drive, both letters are allocated to it to facilitate swapping disks during tasks like copying files or running programs from different floppy disks. Typically, hard drives are designated starting at "C" and continue sequentially with "D" and beyond. Only one active partition per disk is supported; drive letters are allocated first to active primary partitions, followed by logical drives within extended partitions, then inactive primary partitions if any exist, and finally optical drives, RAM disks, and other devices.

While letter assignments generally reflect the order in which device drivers load, they can be modified by drivers themselves—for instance, network drivers often assign letters toward the end of the alphabet.

Since DOS applications directly reference drive letters, adding new hardware can alter existing assignments—for example, introducing a new hard disk with an active partition may claim a letter previously used by logical drives on another disk. This problem continued through Microsoft's DOS-based Windows 9x releases but was addressed in NT-based Windows versions by preserving existing letter assignments unless explicitly changed by users. Workarounds in DOS include creating SUBST drives or reserving specific drive letters such as L:, a practice employed in systems like Concurrent DOS, Multiuser DOS, System Manager, and REAL/32, where L: is automatically linked to the load drive upon application launch.

Reserved device names

DOS reserves certain device names that cannot be assigned as filenames regardless of their extensions because they correspond to internal character devices. These reserved identifiers remain enforced in various Windows editions and have occasionally been sources of system crashes and security vulnerabilities.

The reserved device names include:

  • COM1 through COM9 (serial ports)
  • LPT1 through LPT9 (printer parallel ports)
  • CON (console interface for keyboard input and display output)
  • AUX (auxiliary device, typically mapped to the first COM port)
  • PRN (printer device usually linked to the first LPT port)
  • NUL (null device)

In Windows 95 and 98, attempts to use these reserved names within file paths could cause system crashes; Microsoft released patches addressing this issue. From Windows XP onward, such usage is silently corrected without user notification. Starting with Windows Vista, an explicit error message is displayed when these names are used improperly.

Except for NUL, these reserved names have been consistently supported across MS-DOS, PC DOS, and DR-DOS variants. Some OEM versions of MS-DOS included additional aliases like LST or PLT. Over time, DOS added support for devices such as CLOCK$, while multitasking MS-DOS 4 introduced KEYBD$ and SCREEN$. DR DOS includes an $IDLE$ device intended for power management and multitasking environments.

Default mappings such as AUX pointing to COM1 and PRN linked to LPT1 can be altered in certain DOS editions. Some HP OEM MS-DOS releases provided extra device aliases covering serial ports, parallel ports, and plotters.

By convention, device names end with a colon (e.g., NUL:) to signify their status as devices; however, the colon itself is not part of the actual device name. For example:

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

Although standard interfaces prevent creating files or directories using these reserved names, it remains possible through direct directory editing methods—a technique sometimes exploited by malware authors to conceal files from normal user access.

Memory management

DOS was originally developed for the Intel 8088 CPU, which supports direct access to a maximum of 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 approached this memory ceiling, although a significant portion of reserved memory often remained idle depending on system hardware.

To overcome these limitations, new memory specifications were introduced. The Expanded Memory Specification (EMS) allowed systems to access extra memory through a 64 KiB page frame located in upper memory. On machines equipped with 80386 processors or newer, virtual 8086 mode managers such as EMM386 could simulate expanded memory using extended memory without requiring additional hardware. The Extended Memory Specification (XMS), designed for 80286 and later processors, facilitated data transfers to extended memory and provided access to the 65,520-byte high memory area (HMA) as well as upper memory blocks. XMS functionality was commonly delivered by drivers like HIMEM.SYS or V86 mode managers including QEMM and 386MAX, which also supported EMS.

Beginning with DOS version 5, the operating system utilized the HMA by relocating kernel components and disk buffers there through the DOS=HIGH directive in CONFIG.SYS. Furthermore, DOS 5 and subsequent versions enabled the use of upper memory blocks by activating DOS=UMB in CONFIG.SYS.

DOS under OS/2 and Windows

DOS emulation within OS/2 and Windows environments functions similarly to native applications, granting access to drives, system services, and the host clipboard. Because file system drivers operate within the host OS, the DOS emulation layer converts DOS API requests into corresponding OS/2 or Windows system calls while virtualizing BIOS interrupts and I/O port operations typical of DOS software.

In Windows versions 3.1 and 9x, the DOS virtual machine is implemented via WINOLDAP, which establishes a virtual machine configured by program PIF files and the system state at Windows startup. This VM supports running DOS graphics modes inside a window and facilitates clipboard sharing.

Both OS/2 and Windows NT emulate DOS based on DOS version 5, allowing users to specify alternative config.sys and autoexec.bat files per session and load third-party drivers to enable access to host resources.

Starting with OS/2 version 2.x, DOSKRNL serves as a combined replacement for IBMBIO.COM and IBMDOS.COM; system calls are routed through OS/2's windowing services. DOS applications execute within isolated environments supported by utilities bundled with integrated DOS/OS2 applications located in \OS2. OS/2 also supports Windows 3.1 through Win-OS/2, permitting either seamless integration or operation on separate desktops.

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 drivers to facilitate hardware support—particularly useful for devices like certain CD-ROM drives that are otherwise unsupported.

All 32-bit editions of Windows NT since their introduction in 1993 offer DOS emulation via a virtual DOS machine (NTVDM). However, 64-bit versions do not include NTVDM support and thus cannot run native 16-bit DOS applications; users must rely on third-party emulators such as DOSbox to execute these programs.

User interface

DOS systems operate through a command-line interface, where users launch applications by typing their filenames at the command prompt. The environment includes both internal commands built into the shell and external utility programs.

To improve user experience, various developers created file management utilities featuring WIMP interfaces. Microsoft Windows notably evolved into an independent program loader; by the era of Windows 9x, it had largely supplanted DOS as the primary PC-compatible loader. Prominent text-based user interface file managers included Norton Commander, DOS Navigator, and Volkov Commander, whereas graphical interfaces encompassed Digital Research's GEM and GEOS.

Leading DOS providers later incorporated environment managers: MS-DOS/IBM DOS version 4 introduced DOS Shell, while DR DOS 5.0 debuted ViewMAX, which was built upon GEM technology.

Terminate-and-Stay-Resident Programs

Although DOS does not natively support multitasking, it allows for terminate-and-stay-resident (TSR) applications that remain loaded in memory. These programs intercept system interrupts, enabling background operations or on-demand execution. For instance, the DOS PRINT utility employs TSR to manage print spooling, while Borland Sidekick—a popup personal organizer—utilizes this approach.

TSRs augment DOS capabilities by providing additional features; utilities such as CED and DOSKEY improve command-line editing beyond what COMMAND.COM offers, and Microsoft CD-ROM Extensions (MSCDEX) facilitate access to CD-ROM drives.

Certain TSRs offer rudimentary task-switching functionality. The shareware application Back and Forth (1990) permitted users to save the state of an active program to disk, load a different one, and toggle between them—albeit with slow performance due to reliance on disk I/O. Genuine multitasking required more advanced software like DESQview, which operated effectively only on processors of at least the 386 generation.

Software

Development tools

See also

Further reading

  • IBM Corp., "IBM DOS Release 2.10 Cloth bound retail hard board box," January 1984, 1st edition, IBM Corp., Item Number 6183946
  • IBM Corp., "Disk Operating System User's Guide (DOS Release 2.10)," January 1984, 1st edition, Microsoft Corp., 100 pages with color illustrations, Item Number 6183947
  • IBM Corp., "Disk Operating System Manual (DOS Release 2.10)," January 1984, 1st edition, Microsoft Corp., 574 looseleaf pages in a three-ring binder, Item Number 6183940
  • Mueller, Scott. Upgrading and Repairing PCs, Eighth Edition, 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=LPT3&oldid=29048"