Hubbry Logo
DOS APIDOS APIMain
Open search
DOS API
Community hub
DOS API
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
DOS API
DOS API
DOS API
View on Wikipedia
from Wikipedia

The DOS API is an API which originated with 86-DOS and is used in MS-DOS/PC DOS and other DOS-compatible operating systems. Most calls to the DOS API are invoked using software interrupt 21h (INT 21h). By calling INT 21h with a subfunction number in the AH processor register and other parameters in other registers, various DOS services can be invoked. These include handling keyboard input, video output, disk file access, program execution, memory allocation, and various other activities. In the late 1980s, DOS extenders along with the DOS Protected Mode Interface (DPMI) allow the programs to run in either 16-bit or 32-bit protected mode and still have access to the DOS API.

History of the DOS API

[edit]

The original DOS API in 86-DOS and MS-DOS 1.0 was designed to be functionally compatible with CP/M. Files were accessed using file control blocks (FCBs). The DOS API was greatly extended in MS-DOS 2.0 with several Unix concepts, including file access using file handles, hierarchical directories and device I/O control.[1] In DOS 3.1, network redirector support was added. In MS-DOS 3.31, the INT 25h/26h functions were enhanced to support hard disks greater than 32 MB. MS-DOS 5 added support for using upper memory blocks (UMBs). After MS-DOS 5, the DOS API was unchanged for the successive standalone releases of DOS.

The DOS API and Windows

[edit]

In Windows 9x, DOS loaded the protected-mode system and graphical shell. DOS was usually accessed from a virtual DOS machine (VDM) but it was also possible to boot directly to real mode MS-DOS 7.0 without loading Windows. The DOS API was extended with enhanced internationalization support and long filename support, though the long filename support was only available in a VDM. With Windows 95 OSR2, DOS was updated to 7.1, which added FAT32 support, and functions were added to the DOS API to support this. Windows 98 and Windows Me also implement the MS-DOS 7.1 API, though Windows Me reports itself as MS-DOS 8.0.

Windows NT and the systems based on it (e.g. Windows XP and Windows Vista) are not based on MS-DOS, but use a virtual machine, NTVDM, to handle the DOS API. NTVDM works by running a DOS program in virtual 8086 mode (an emulation of real mode within protected mode available on 80386 and higher processors). NTVDM supports the DOS 5.0 API. DOSEMU for Linux uses a similar approach.

Interrupt vectors used by DOS

[edit]

The following is the list of interrupt vectors used by programs to invoke the DOS API functions.

Interrupt vector Description Version Notes
20h Terminate program 1.0+ Implemented in DOS kernel
21h Main DOS API 1.0+ Implemented in DOS kernel
22h Program terminate address 1.0+ Return address in calling program
23h Control-C handler address 1.0+ Default handler is in the command shell (usually COMMAND.COM)
24h Critical error handler address 1.0+ Default handler is in the command shell (usually COMMAND.COM)
25h Absolute disk read 1.0+ Implemented in DOS kernel, enhanced in DOS 3.31 to support up to 2 GB partitions
26h Absolute disk write 1.0+ Implemented in DOS kernel, enhanced in DOS 3.31 to support up to 2 GB partitions
27h Terminate and stay resident 1.0+ Implemented in COMMAND.COM in DOS 1.0, DOS kernel in DOS 2.0+
28h Idle callout 2.0+ Called by DOS kernel when waiting for input
29h Fast console output 2.0+ Implemented by the built-in console device driver or a replacement driver like ANSI.SYS
2Ah Networking and critical section 3.0+ Called by DOS kernel to interface with networking software
2Bh Unused
2Ch Unused
2Dh Unused
2Eh Reload transient 2.0+ Implemented in COMMAND.COM
2Fh Multiplex 3.0+ Implemented in DOS kernel and various programs (PRINT, MSCDEX, DOSKEY, APPEND, etc.) depending on subfunction number

DOS INT 21h services

[edit]

The following is the list of functions provided via the DOS API primary software interrupt vector.

AH Description Version
00h Program terminate 1.0+
01h Character input 1.0+
02h Character output 1.0+
03h Auxiliary input 1.0+
04h Auxiliary output 1.0+
05h Printer output 1.0+
06h Direct console I/O 1.0+
07h Direct console input without echo 1.0+
08h Console input without echo 1.0+
09h Display string 1.0+
0Ah Buffered keyboard input 1.0+
0Bh Get input status 1.0+
0Ch Flush input buffer and input 1.0+
0Dh Disk reset 1.0+
0Eh Set default drive 1.0+
0Fh Open file 1.0+
10h Close file 1.0+
11h Find first file 1.0+
12h Find next file 1.0+
13h Delete file 1.0+
14h Sequential read 1.0+
15h Sequential write 1.0+
16h Create or truncate file 1.0+
17h Rename file 1.0+
18h Reserved 1.0+
19h Get default drive 1.0+
1Ah Set disk transfer address 1.0+
1Bh Get allocation info for default drive 1.0+
1Ch Get allocation info for specified drive 1.0+
1Dh Reserved 1.0+
1Eh Reserved 1.0+
1Fh Get disk parameter block for default drive 1.0+
20h Reserved 1.0+
21h Random read 1.0+
22h Random write 1.0+
23h Get file size in records 1.0+
24h Set random record number 1.0+
25h Set interrupt vector 1.0+
26h Create PSP 1.0+
27h Random block read 1.0+
28h Random block write 1.0+
29h Parse filename 1.0+
2Ah Get date 1.0+
2Bh Set date 1.0+
2Ch Get time 1.0+
2Dh Set time 1.0+
2Eh Set verify flag 1.0+
2Fh Get disk transfer address 2.0+
30h Get DOS version 2.0+
31h Terminate and stay resident 2.0+
32h Get disk parameter block for specified drive 2.0+
33h Get or set Ctrl-Break 2.0+
34h Get InDOS flag pointer 2.0+
35h Get interrupt vector 2.0+
36h Get free disk space 2.0+
37h Get or set switch character 2.0+
38h Get or set country info 2.0+
39h Create subdirectory 2.0+
3Ah Remove subdirectory 2.0+
3Bh Change current directory 2.0+
3Ch Create or truncate file 2.0+
3Dh Open file 2.0+
3Eh Close file 2.0+
3Fh Read file or device 2.0+
40h Write file or device 2.0+
41h Delete file 2.0+
42h Move file pointer 2.0+
43h Get or set file attributes 2.0+
44h I/O control for devices 2.0+
45h Duplicate handle 2.0+
46h Redirect handle 2.0+
47h Get current directory 2.0+
48h Allocate memory 2.0+
49h Release memory 2.0+
4Ah Reallocate memory 2.0+
4Bh Execute program 2.0+
4Ch Terminate with return code 2.0+
4Dh Get program return code 2.0+
4Eh Find first file 2.0+
4Fh Find next file 2.0+
50h Set current PSP 2.0+
51h Get current PSP 2.0+
52h Get DOS internal pointers (SYSVARS) 2.0+
53h Create disk parameter block 2.0+
54h Get verify flag 2.0+
55h Create program PSP 2.0+
56h Rename file 2.0+
57h Get or set file date and time 2.0+
58h Get or set allocation strategy 2.11+
59h Get extended error info 3.0+
5Ah Create unique file 3.0+
5Bh Create new file 3.0+
5Ch Lock or unlock file 3.0+
5Dh File sharing functions 3.0+
5Eh Network functions 3.0+
5Fh Network redirection functions 3.0+
60h Qualify filename 3.0+
61h Reserved 3.0+
62h Get current PSP 3.0+
63h Get DBCS lead byte table pointer 3.0+
64h Set wait for external event flag 3.2+
65h Get extended country info 3.3+
66h Get or set code page 3.3+
67h Set handle count 3.3+
68h Commit file 3.3+
69h Get or set media id 4.0+
6Ah Commit file 4.0+
6Bh Reserved 4.0+
6Ch Extended open/create file 4.0+

Operating systems with native support

[edit]

Operating systems with DOS emulation layer

[edit]

Other emulators

[edit]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

DOS API

View on Grokipedia
from Grokipedia
The DOS API is an application programming interface that originated with , a developed by at Seattle Computer Products in 1980, and was subsequently adopted and extended in , PC DOS, and other compatible systems for x86-based personal computers. It provides essential services to applications, including file and device input/output, , program execution, and system , primarily through software interrupts that allow user programs to invoke operating system functions without direct hardware access. Designed initially for compatibility with CP/M-like environments using File Control Blocks (FCBs) in 1.0 (released in 1981), the evolved significantly with 2.0 (1983) to support hierarchical file systems, handle-based file operations, and larger memory addressing, enabling more sophisticated applications on IBM PC compatibles. The core of the revolves around Interrupt 21h (INT 21h), where the AH register specifies the function code (e.g., 01h for keyboard input, 3Dh for opening a file by ), supplemented by other interrupts like 20h for program termination and 25h/26h for direct disk reads/writes. Key features include the Disk Transfer Area (DTA) for buffering file data, error handling via and return codes (e.g., 02h for "file not found"), and later extensions in 3.0+ (1984 onward) for networking, extended information (function 59h), and international character support. This interrupt-driven model facilitated the development of a vast ecosystem of DOS software, from utilities to games, until the API's partial emulation in 32-bit Windows environments and its eventual obsolescence with the rise of graphical operating systems in the .

Overview

Definition and Purpose

The DOS API is a set of system calls that enables applications to access core operating system services in and compatible environments. It provides a standardized interface for managing resources such as files, , devices, and processes, allowing programs to perform tasks like opening files, allocating blocks, reading keyboard input, and executing other programs without directly interfacing with hardware. This ensures that software remains portable across different x86-based systems, promoting consistency in application behavior regardless of underlying machine specifics. At its core, the DOS API is invoked primarily through software 21h (INT 21h), which acts as the central dispatcher for DOS functions. Developers specify the desired service by setting the function code in the AH register (e.g., 00h for program termination or 3Dh for opening a file ) and passing additional parameters via other registers like DX or BX, after which the is executed to transfer control to the DOS kernel. This mechanism supports over 60 functions, categorized into areas such as file and directory management, character I/O, allocation, and information retrieval, with results returned in registers and errors signaled via the . The -based design leverages the x86 architecture's efficiency for real-mode operations, minimizing overhead while enabling comprehensive interaction. The primary purpose of the DOS API is to streamline for by offering a unified, extensible framework that abstracts hardware complexities and ensures compatibility across DOS versions from 1.0 onward. It facilitates the creation of robust, system-integrated applications—such as utilities for , text editors, and games—by handling essential I/O operations, process control, and in a predictable manner. This interface was instrumental in establishing as the dominant platform for early personal computing, empowering developers to build efficient that could evolve with OS enhancements while maintaining support for legacy software.

Historical Significance

The DOS API, primarily accessed through the software interrupt INT 21h, emerged as a foundational element of personal computing by providing a standardized interface for essential operating system services in the early 1980s. Designed initially for and adapted into 1.0 in 1981, it drew heavy inspiration from the operating system, incorporating similar file access mechanisms and command structures to facilitate developer familiarity and porting of existing software. This compatibility was crucial during the PC's launch, as it allowed programmers accustomed to 8-bit systems to quickly adapt to the 16-bit architecture, thereby accelerating the growth of for the new platform. The API's significance lies in its role as the backbone for the explosive expansion of the PC software ecosystem throughout the and into the . By offering simple, efficient calls for file management, memory allocation, and device I/O—implemented in compact assembly code within the DOS kernel—it enabled the creation of thousands of programs, from tools to , that ran on millions of IBM-compatible machines. Its interrupt-based design, leveraging the x86's vector table, minimized overhead in memory-constrained environments, making it ideal for single-tasking systems where direct hardware access was common but OS mediation was needed for portability. This standardization not only dominated the market by the mid- but also fostered third-party development, including utilities and drivers, that extended DOS's capabilities without requiring deep system modifications. Historically, the DOS API's enduring impact is evident in its influence on subsequent operating systems and backward compatibility efforts. It served as a bridge to graphical environments like early Windows versions, where emulated INT 21h calls preserved legacy applications, ensuring a smooth transition for the installed base. By establishing conventions like 8.3 filenames and device-independent I/O, it shaped industry norms for file systems and APIs, leaving a legacy in modern systems through tools like DOSBox and the open-sourcing of MS-DOS code in 2018, which aids historical research and education.

Historical Development

Origins in 86-DOS and MS-DOS

The DOS API originated with the development of 86-DOS, a disk operating system created by Tim Paterson at Seattle Computer Products (SCP) in April 1980. Initially named Quick and Dirty Operating System (QDOS), it was designed to provide basic file management and I/O capabilities for the Intel 8086 microprocessor, filling a gap left by the absence of a commercially available CP/M port for 16-bit systems at the time. 86-DOS implemented a file allocation table (FAT) file system, which differed from CP/M's approach but allowed for more efficient disk handling on floppy media. This system was refined and renamed 86-DOS by late 1980, with version 0.33 being the first commercially shipped release by SCP in December of that year. The core of the DOS API in 86-DOS was its programming interface, deliberately engineered for compatibility with CP/M to facilitate the porting of existing 8-bit applications to the 8086 architecture. Drawing from Digital Research's CP/M reference manual, Paterson replicated the functionality of CP/M's Basic Disk Operating System (BDOS) calls, which handled tasks such as file I/O, console operations, and program loading. However, 86-DOS adapted this interface for the segmented memory model of the 8086, using 16:16 far pointers and invoking functions primarily through the software interrupt INT 21h rather than CP/M's CALL 5 mechanism. This interrupt-based approach, while less common in some contemporary systems, enabled efficient context switching and was marked as the preferred method in 86-DOS documentation, with CALL 5 supported but deprecated. The API supported file control blocks (FCBs) for compatibility, though it introduced enhancements like direct sector access for better performance on 8-inch and 5.25-inch floppies. No source code from CP/M was copied; the implementation was original, written in 8086 assembly language over approximately three months, from April to July 1980. In July 1981, Microsoft acquired the rights to 86-DOS from SCP for $50,000 in an outright purchase, following an initial non-exclusive licensing agreement earlier that year for $25,000 (totaling $75,000 paid to SCP), renaming it MS-DOS and further developing it into version 1.0, which was licensed to IBM as PC-DOS for the IBM PC released in August 1981. The API remained largely unchanged in this transition, retaining INT 21h as the primary entry point for system services, including the foundational function calls for character I/O (e.g., AH=01h for keyboard input), file operations (e.g., AH=3Dh for opening files), and program termination (AH=4Ch). Microsoft's adaptations focused on integrating it with IBM's hardware, such as adjusting the command prompt to "A>" to mimic CP/M more closely at IBM's request, while preserving the interrupt-driven model that became the hallmark of the DOS API. This continuity ensured that early MS-DOS applications could leverage the established interface without major rewrites, establishing its role as a bridge between 8-bit and 16-bit computing eras.

Evolution Through DOS Versions

The DOS API, primarily accessed through INT 21h, originated in early versions of in 1980 with a limited set of functions (00h-29h) focused on basic console I/O, file operations using File Control Blocks (FCBs), and program termination, supporting single-tasking on floppy-based systems. 1.0, released later that year, retained this core with minor additions like function 1Fh for getting the Disk Parameter Block (DPB) in version 1.1, emphasizing simplicity for early PC compatibility. These early functions prioritized character and block device handling, such as AH=01h for keyboard input and AH=40h for file writes, but lacked support for hierarchical file systems or advanced . MS-DOS 2.0 in marked a significant expansion, introducing over 30 new INT 21h functions (2Fh-57h) to accommodate subdirectories, hard disk support, and file handles as an alternative to FCBs, enabling path-based operations like AH=39h (create directory) and AH=3Dh (open file by handle). This version shifted toward a more robust , adding memory allocation via AH=48h-49h and interrupt vector management (AH=25h-35h), which facilitated device drivers and TSR programs. Function 4Bh for program execution was initially implemented in , reflecting the 's growing role in supporting installable device drivers and I/O redirection. Subsequent releases in the 3.x series (1984-1987) enhanced networking and sharing capabilities, with MS-DOS 3.0 adding functions like AH=5Ch for file locking, AH=59h for extended error information, and AH=44h subfunctions (e.g., 08h-0Bh) for device control and removable media checks, addressing multi-user environments and larger storage. MS-DOS 3.1 introduced network redirection (AH=5Eh-5Fh) and code page support (AH=6600h), while 3.3 added AH=67h to increase file handle limits and AH=68h for disk commits, improving performance on systems with up to 32MB RAM under FAT12/16. These changes emphasized API extensibility for peripherals and internationalization. MS-DOS 4.0 (1988) introduced enhancements like AH=6Ch for flexible file open/create, but its API additions were limited and often unstable. An experimental multitasking variant from the mid-1980s (separate from the 1988 release) included features like AH=87h for process identification, though it saw very limited adoption due to bugs and was not part of the standard release. By MS-DOS 5.0 (1991), the API focused on memory optimization, adding AH=3306h for true version reporting, AH=5800h-5803h for upper memory block (UMB) allocation via HIMEM.SYS, and AH=440Dh subfunctions for media sensing, supporting expanded memory up to 16MB and better 286/386 compatibility. MS-DOS 6.0 (1993) introduced no major new INT 21h functions but extended the API indirectly through INT 2Fh for DoubleSpace compression and power management, maintaining backward compatibility while prioritizing disk tools like SCANDISK. The final standalone MS-DOS 6.22 (1994) solidified the API with refinements to existing functions for FAT16 volumes up to , but the API's evolution culminated in MS-DOS 7.0 (1995, integrated in ), which added AH=71h for (LFN) support via VFAT, AH=7300h-7305h for (IFS) management, and AH=5704h-5707h for extended file times, enabling 8.3-to-long name conversions and paths in a 32-bit context. Later variants like MS-DOS 7.1 in OSR2 extended IFS calls further, marking the API's transition to emulation layers in hybrid environments while preserving core INT 21h for legacy applications.

Technical Specifications

Interrupt Vector Table Usage

The (IVT) in is a fixed in low that maps interrupt numbers to the addresses of their corresponding handlers, enabling the operating system and applications to respond to hardware events, software requests, and system services. In the x86 real-mode architecture underlying DOS, the IVT resides at physical addresses 0000:0000 through 0000:03FF, occupying the first 1,024 bytes of RAM. This table consists of 256 entries, one for each possible interrupt from 00h to FFh, with each entry formatted as a 4-byte far pointer: the low word (2 bytes) holds the offset address of the interrupt service routine (ISR), and the high word (2 bytes) holds the segment address. During system initialization, the sets initial vectors in the IVT for hardware interrupts (e.g., 08h for the and 0Ch-0Fh for serial ports) and basic services, after which takes control and modifies specific entries to point to its own routines. DOS reserves and initializes vectors for interrupts 20h through 27h across all versions, with later releases like DOS 3.10 extending this to 0Fh through 3Fh to accommodate additional device and system needs. The core DOS API, accessed primarily via software interrupt INT 21h, relies on the IVT entry at offset 84h (21h × 4) to dispatch function calls for operations such as file I/O, memory allocation, and process control; when a program issues INT 21h with the appropriate AH register value (e.g., 09h for string output), the CPU consults the IVT to jump to DOS's multiplexed handler. Applications interact with the IVT indirectly through DOS-provided functions to ensure compatibility and avoid direct memory manipulation, which could destabilize the system. To retrieve an interrupt vector, programs invoke INT 21h with AH=35h and the interrupt number in AL, returning the handler's segment in ES and offset in BX. Conversely, to install a custom handler—such as for TSR (terminate-and-stay-resident) programs hooking keyboard input via —developers use INT 21h with AH=25h, specifying the interrupt number in AL and the new handler address in DS:DX; this updates the corresponding IVT entry atomically. is recommended for non-replacement hooks, where the custom ISR calls the original vector (saved via the get function) before returning, preserving DOS and functionality. Direct IVT access at 0000:0000 is possible but discouraged, as DOS may relocate or protect parts of low memory in extended versions.
InterruptIVT Offset (Hex)Typical DOS Usage
20h80hProgram terminate
21h84hDOS function dispatcher (core )
22h88hCtrl-Break handler
23h8ChCtrl-C/DOS fatal abort
24h90hCritical error handler
27h9ChUnused (reserved)
This table illustrates select reserved vectors; full details span 20h-3Fh in DOS 3.x, emphasizing the IVT's role in encapsulating system behavior for portable access.

INT 21h Function Calls

Interrupt 21h is the primary software interrupt through which applications request a broad array of operating system services, including file and directory operations, console , allocation, control, and device management. To invoke a service, a program loads the desired function number into the AH register (ranging from 00h to FFh), sets additional parameters in other registers such as AL, BX, CX, DX, DS:DX, or ES:BX as required by the specific function, and then executes the INT 21h instruction. The kernel examines the AH value to dispatch the appropriate handler, returning results via specified registers or flags; for instance, many functions clear the (CF=0) on success and set it (CF=1) with an in AX on failure. This mechanism provided a layer, abstracting hardware details and promoting portability across PC-compatible systems. The INT 21h interface originated in (the precursor to ) and was carried over into 1.0 in 1981, initially featuring about 30 functions focused on character I/O, basic disk operations, and (FCB)-based file handling for compatibility; these early calls used simple success/failure indicators like AL=00h (success) or AL=FFh (error). 2.0 (1983) marked a major expansion, introducing over 50 new functions to support hierarchical file systems, pathnames, and handle-based I/O, while deprecating FCB methods in favor of more flexible handles (non-negative integers representing open files or devices). Error reporting improved with the and standardized AX error codes (e.g., 02h for file not found, 05h for access denied). Later versions built on this foundation: DOS 3.0 (1984) added extended error details via function 59h, including error class, action, and locus; DOS 3.1 (1984) incorporated network redirection and sharing modes; and DOS 4.0 (1988) enhanced device IOCTL subfunctions for logical drive mapping and media checks. By 6.22 (1994), the set exceeded 100 functions, including support for long filenames and double-space compression, though core calls remained backward-compatible. This evolution reflected the growing complexity of PC environments, from single-user floppy-based systems to networked, hard-disk-equipped machines. Functions under INT 21h are conceptually grouped into categories, each addressing distinct aspects of system interaction, with representative examples illustrating typical usage. Character I/O functions handle console and device communication, often supporting redirection to files or peripherals. Disk and directory operations manage storage access and organization, evolving from flat to hierarchical structures. File management shifted from FCB to handle-based for efficiency and concurrency. Memory and process controls enabled dynamic allocation and program execution, crucial for multitasking-like behaviors in TSR (terminate-and-stay-resident) programs. Device and system functions provided finer control over hardware and configuration. While not all AH values are assigned (e.g., 10h-13h, 1Ah-16h are unused in standard MS-DOS), extensions from OEMs like Novell NetWare added network-specific calls (e.g., AH=E0h+ for connection services). Programmers were advised to check the Carry flag post-call and use function 59h (DOS 3.0+) for detailed diagnostics, as basic error codes alone often lacked context for troubleshooting.
CategoryRepresentative Functions (AH Value)Description and Key RegistersDOS VersionNotes
Character I/O01h: Input with Echo
02h: Output Character
09h: Output String		01h: None in; AL=character out (waits, echoes).
02h: DL=character in; none out.
09h: DS:DX=$-terminated string in; none out.		1.0+Support Ctrl-C break (INT 23h); redirectable to files/devices. Function 0Ah provides buffered line input for up to 255 characters.
Disk Operations0Eh: Select Drive
19h: Get Current Drive
36h: Get Free Space		0Eh: DL=drive (0=A) in; AL=drives out.
19h: None in; AL=drive out.
36h: DL=drive in; AX=sectors/cluster, BX=free clusters, etc. out.		1.0+ (36h: 2.0+)0Dh resets disk buffers. Function 36h computes space in sectors, essential for space checks before writes.
File Management3Ch: Create/Truncate
3Dh: Open
3Fh: Read
40h: Write		3Ch: DS:DX=path, CX=attributes in; AX=handle out (CF=1 on error).
3Dh: AL=mode (0=read), DS:DX=path in; AX=handle out.
3Fh: BX=handle, CX=bytes, DS:DX=buffer in; AX=bytes read out.
40h: Similar to 3Fh, but AX=bytes written out.		2.0+Handles range 0-255; 3Eh closes (BX=handle in). DOS 3.0+ adds sharing in 3Dh (e.g., AL=bit 4 for deny-write). Replaces FCB methods like 0Fh (open FCB).
Directory Management39h: Create (MKDIR)
3Ah: Remove (RMDIR)
3Bh: Change (CHDIR)
47h: Get Current Path		39h/3Ah/3Bh: DS:DX=path in; none out (CF=1, AX=error on fail).
47h: DL=drive, DS:SI=64-byte buffer in; buffer filled out.		2.0+Paths up to 63 chars + null; 47h prepends drive letter (e.g., "C:\DIR"). Function 56h renames files across directories.
Process Control00h: Terminate
31h: Terminate & Stay Resident
4Bh: Execute Program		00h: None in; terminates with code 00h.
31h: AL=code, DX=paragraphs to keep in; stays resident.
4Bh: AL=00h (exec)/03h (load), DS:DX=program, ES:BX=param block in; none out.		1.0+ (31h/4Bh: 2.0+)4Ch (2.0+) is preferred terminate (AL=code in). 4Bh requires param block for environment, command line, FCBs; supports overlays.
Memory Management48h: Allocate
49h: Free		48h: BX=paragraphs in; AX=segment out (CF=1, BX=max avail. on fail).
49h: ES=segment in; none out.		2.0+Paragraph=16 bytes; 4Ah resizes (BX=handle, ES=segment in). Critical for dynamic apps; failure often due to fragmentation.
System Information2Ah: Get Date
30h: Get Version
59h: Get Extended Error		2Ah: None in; CX=year-1980, DH=month, DL=day, AL=weekday out.
30h: None in; AL=major, AH=minor, BX=512-byte flag (3.0+), CX=version (3.0+).
59h: None in; BX=error code, etc. out (after failed call).		1.0+ (59h: 3.0+)2Ch similar for time. 30h OEM in BH (e.g., 00h=MS). 59h provides class (e.g., 01h=write fault), action (e.g., 01h=abort).
These categories encapsulate the API's versatility, with handle-based functions preferred for their efficiency and support for /redirection, while FCB calls lingered for legacy compatibility. Detailed register conventions and subfunctions (e.g., AH=44h for with AL subcodes like 00h for get device info) are outlined in official programmer references, emphasizing the need for version checks via 30h to ensure compatibility. The robustness of INT 21h allowed DOS to power millions of applications, from utilities to , until its gradual in 32-bit Windows environments.

Other DOS Interrupts

In addition to the primary INT 21h interface, MS-DOS provided several other interrupts for specific system services, program termination, error handling, and low-level operations. These interrupts were essential for early DOS programming, enabling developers to interact directly with the operating system kernel for tasks not covered by the multiplexed functions of INT 21h. They were invoked via the x86 interrupt instruction and relied on the DOS for dispatch. INT 20h served as the basic program termination interrupt in versions 1.0 and later. When invoked, it ended the current program's execution, closed open files, released memory allocated to the program, and returned control to the DOS command interpreter (). The code segment register (CS) was expected to contain the segment address of the program's segment prefix (PSP) at the time of invocation, ensuring proper cleanup. This interrupt was simpler than the corresponding INT 21h function (AH=4Ch) but lacked support for return codes, making it suitable for rudimentary batch files or early applications. The INT 22h interrupt vector defined the program termination address, a callback routine executed upon program exit in 1.0 and subsequent versions. DOS stored this vector in the PSP at offset 000Ah, allowing developers to specify custom cleanup code, such as deallocating resources or logging events, before full termination. Unlike direct invocation, INT 22h was primarily configured via INT 21h calls (e.g., AH=25h to set the vector) and triggered automatically during exit sequences initiated by INT 20h or INT 21h. This mechanism facilitated orderly shutdowns in multi-tasking-like environments or terminate-and-stay-resident (TSR) programs. INT 23h handled Ctrl-Break (or Ctrl-C in later versions) interrupts, introduced in 1.0. When a user pressed these keys during program execution, the system vectored to the handler installed at INT 23h, typically allowing the program to abort gracefully or ignore the signal. The handler received the current registers on the stack and could return with clear to resume execution or set to terminate the program. Developers often set this vector using INT 21h (AH=25h) to implement custom signal handling, enhancing user interactivity in console applications. For critical errors, such as disk I/O failures or hardware faults, invoked INT 24h starting from version 1.0. This interrupt provided an error-handling vector stored in the PSP at offset 000Eh, where the handler could choose to abort (return 00h in AL), retry (01h), fail (02h), or ignore (03h) the operation. Parameters passed included the in AH, device code in DI, and drive in DL. Custom handlers allowed applications to recover from media errors or implement logging, bypassing the default abort-to-DOS behavior. Low-level disk access was facilitated by INT 25h for absolute sector reads and INT 26h for writes, both available from 1.0. INT 25h read a specified number of sectors (in CX, or FFFFh for maximum) from an absolute logical sector (in DX:BX) on the drive in DL, storing data at ES:BX; it supported partitions up to 32 MB in early versions and extended to 2,047 MB in DOS 3.31+. Similarly, INT 26h performed writes with the same parameters, requiring carry flag clear on success (error code in AX if failed). These interrupts bypassed the for direct block device manipulation, useful for bootloaders, formatters, or disk utilities, though they risked if misused. INT 27h enabled terminate-and-stay-resident (TSR) functionality in 1.0 and later, allowing a program to end execution while keeping a portion of its code in for later invocation. Parameters included the size of the resident portion in DX (in paragraphs) and an optional module name in ES:SI. Upon invocation, DOS deallocated non-resident but preserved the TSR segment, installing hooks into other interrupts (e.g., INT 09h for keyboard) for background services like pop-up menus or drivers. This was a foundational mechanism for extending DOS without kernel modifications. Finally, INT 2Fh acted as the multiplex interrupt for DOS extensions and installable device drivers, multiplexed by the value in AX to select subfunctions. Introduced in MS-DOS 2.0, it supported checks for installed utilities (e.g., AX=0100h for PRINT.COM in DOS 3.0+), file queue management (AX=0101h to submit files for printing), and internal DOS services (e.g., AX=1200h for redirector checks). Later versions added subfunctions for keyboard mapping (AX=AD80h in DOS 3.3+) and command installers (AX=AE00h). This interrupt was crucial for TSRs and third-party extensions to coexist, forming the basis for DOS's modular architecture.

Compatibility in Windows

Support in Windows 9x

, encompassing , , and , provided robust native support for the DOS API through a hybrid 16/32-bit architecture that integrated a customized kernel for compatibility with legacy applications. This setup allowed DOS programs to execute DOS API calls, such as those via INT 21h, by leveraging to simulate a protected environment for multiple DOS sessions. Each DOS application ran in its own (VDM), isolating it from the 32-bit Windows subsystem while maintaining the illusion of direct hardware access. The boot process in relied on a modified core—version 7.0 for , 7.1 for and its updates, and 8.0 for —to handle initialization tasks like processing and before transitioning to the 32-bit kernel via WIN.COM. Once in , DOS API interrupts were intercepted and routed through the Manager, which uses the 16-bit IFSMGR.SYS driver to route calls like INT 21h for file I/O to the 32-bit file system components (such as IFSMGR.VXD) for operations on the underlying 32-bit , such as VFAT or FAT32. This manager ensured compatibility by syncing state variables across virtual machines and handling hooks from terminate-and-stay-resident (TSR) programs or 16-bit drivers via thunking to 16-bit code when necessary. Support extended to other DOS interrupts beyond INT 21h, managed by the Virtual Machine Manager (VMM) and Virtual Device Drivers (VxDs) operating at ring 0, which virtualized hardware resources like memory, keyboard, and display for DOS apps. For instance, ill-behaved DOS programs that attempted to manipulate the were contained within their VDM, preventing system-wide crashes and enabling concurrent execution of multiple DOS prompts. enhanced this with improved stability for DOS multitasking and better integration of USB support, while introduced minor refinements to the DOS 8.0 core for enhanced handling, though the core emulation remained consistent across the family. This architecture prioritized , allowing developers to invoke DOS services without modification, but it also introduced performance overhead from mode switches between real-mode DOS operations and protected-mode Windows execution. Real-mode mappers handled unrecognized 16-bit drivers by emulating DOS behavior, though this could degrade efficiency for disk-intensive tasks. Overall, Windows 9x's DOS API support bridged the gap between legacy software and modern multitasking, sustaining a vast ecosystem of DOS applications until the shift to the NT kernel in Windows 2000.

Emulation in Windows NT Line

The Windows NT line of operating systems, starting with Windows NT 3.1 released in 1993, provides backward compatibility for MS-DOS applications through the NT Virtual DOS Machine (NTVDM), a subsystem that emulates a DOS environment on 32-bit IA-32 architectures. NTVDM enables the execution of 16-bit DOS programs by creating isolated virtual machines where DOS applications run without direct access to the underlying NT kernel or hardware, ensuring system stability and security. This emulation layer is implemented via the ntvdm.exe process, which launches a separate instance for each DOS application, allowing multitasking while preventing interference with native 32-bit NT processes. At its core, NTVDM emulates the DOS API by leveraging the x86 processor's Virtual 8086 (V86) mode, which permits 16-bit real-mode code to execute within the protected 32-bit environment of NT. When a DOS application invokes DOS services—primarily through software interrupts such as INT 21h for file I/O, console operations, and program termination—these interrupts are trapped by the NT kernel's trap handlers, such as Ki386VdmDispatchInterrupt. The kernel then translates the interrupt into equivalent NT system calls, emulating the behavior using routines like PushInt to manage the interrupt frame on the user stack and dispatch the appropriate emulation logic. For instance, INT 21h functions are handled by mapping DOS-level requests to NT's native APIs for file handling and device I/O, while restricting direct hardware access to prevent privilege escalation. This trap-based virtualization ensures that DOS API calls, including the and other DOS interrupts like for disk access, are virtualized without compromising the host system's integrity. NTVDM's support persisted across the 32-bit Windows NT lineage, from Windows NT 3.1 through Windows XP and Server 2003, and continued in later versions like Windows 7, 8, and 10 (32-bit editions) as a Feature on Demand, though it entered maintenance mode with no new development. Native support ended with the conclusion of Windows 10 extended support on October 14, 2025. It faced limitations in performance for graphics-intensive or timing-sensitive DOS applications due to the overhead of emulation and restricted hardware emulation (e.g., partial Sound Blaster support via soft emulation). Support was entirely removed in 64-bit editions starting with Windows XP Professional x64 Edition, owing to the absence of V86 mode in 64-bit x86 processors, rendering NTVDM incompatible without third-party workarounds. Security vulnerabilities in the trap handlers, such as stack-based buffer overflows exploitable via crafted INT 21h calls, were addressed in patches like MS13-063, highlighting the subsystem's aging design.

Support in Other Operating Systems

Native Support

OS/2 versions 1.x offered native support for the DOS API via a dedicated compatibility environment called the DOS box, which enabled real-mode execution of DOS applications alongside the protected-mode OS/2 kernel. This was accomplished through microprocessor mode switching between protected and real modes, allowing DOS programs to access hardware via standard interrupts as if running on a standalone DOS system. The implementation provided high compatibility for DOS commands, utilities, and applications, including support for running Windows 2.03 in real mode. The DOS box in 1.0 and 1.21 utilized the to enable dual-mode applications that could operate under both DOS and without recompilation, leveraging shared file system structures for data interchange. Interrupt handling mimicked behavior, with the system isolating DOS sessions to prevent direct interference with processes, though real-mode operations could introduce stability risks due to potential overwrites or device conflicts. This native approach contrasted with later emulation-based methods in 2.0 and beyond, which used virtual-8086 mode for enhanced protection. DOS-compatible operating systems like implement the DOS API natively as open-source alternatives to , preserving the core application binary interface for seamless execution of legacy software. supports standard INT 21h calls and other interrupts, ensuring compatibility with most programs while adding modern extensions for larger storage and . and its variants, such as Novell DOS, also provide native DOS API implementation with enhancements like built-in multitasking via the DOSMGR API and improved handling, maintaining full with applications while supporting features beyond the original specification.

Emulation Layers

Emulation layers for the DOS API in operating systems primarily enable the execution of DOS applications and operating systems by translating DOS interrupts and system calls into native host operations, often without full . These layers emerged to support legacy software on modern platforms, particularly in environments where direct x86 execution is feasible. Unlike full emulators that simulate entire hardware, emulation layers like DOSEMU focus on providing a virtual DOS environment through kernel-supported modes, allowing DOS programs to run with minimal overhead by leveraging the host OS for I/O and resources. DOSEMU, developed starting in the early as an open-source project, serves as a seminal emulation layer for , enabling the booting of DOS variants such as , PC-DOS, and directly on x86 and systems. It utilizes 's vm86 mode—a kernel feature introduced in the 386 processor era—to execute DOS code in a virtualized 8086 environment, where the CPU runs real-mode instructions under supervision. This architecture traps hardware interrupts, including the critical INT 21h for DOS API functions like file handling, directory operations, and device I/O, by intercepting them via the vm86() syscall and mapping them to equivalents, such as file operations for disk access or termios for console input/output. For instance, INT 21h function 3Dh (open file) is emulated by invoking 's open() syscall with appropriate flags and paths from the emulated . The layer also emulates BIOS interrupts (e.g., INT 13h for disk services) and provides virtual devices for keyboard, video (via text-mode console or X11 integration), serial ports, and printers, using Linux drivers to bridge the gap. dosemu2, the actively maintained successor since around 2014, extends this with support for DPMI (DOS Protected Mode Interface) applications, allowing 32-bit DOS programs to access extended memory, and incorporates KVM acceleration on modern CPUs lacking vm86 support for near-native performance. It supports a range of DOS versions up to MS-DOS 6.22 and FreeDOS 1.4, with configuration files defining virtual hardware like floppy drives mapped to host directories. Limitations include incomplete support for certain graphics modes in early versions and dependency on 32-bit compatibility for full vm86 functionality on 64-bit kernels, though binary-only execution mode mitigates this for non-bootable apps. In other Unix-like systems such as and Solaris, dedicated DOS API emulation layers are scarce, with historical efforts like early Solaris DOS file system support focusing more on data compatibility than executable execution. Instead, users rely on portable emulators like , which simulate the full PC hardware stack including the DOS API but operate as user-space applications rather than integrated layers. For macOS, no native kernel-level emulation layer exists due to its Darwin foundation and ARM transition, leading to reliance on cross-platform tools like DOSBox-X or Boxer for DOS program compatibility, which emulate INT 21h and other interrupts through software interpretation without direct API translation. These approaches ensure legacy DOS software remains viable but highlight the Linux-centric nature of specialized emulation layers.

Modern Emulation and Legacy Applications

DOS emulators play a crucial role in preserving and accessing legacy DOS applications that rely on the DOS API, by simulating the x86 architecture, interrupt handling, and file system behaviors of historical PC-compatible systems. These tools enable modern hardware to execute software originally designed for , , or similar environments, often with enhancements for performance, graphics, and input compatibility. Among the most widely adopted are forks and extensions of the original , alongside more hardware-focused emulators like . DOSBox, first released in 2002, remains the foundational and most popular DOS emulator due to its simplicity and broad compatibility with DOS games and utilities. It emulates a complete x86 PC with DOS, supporting sound cards, VGA graphics, and key interrupts like INT 21h for file I/O and program execution. The project, hosted on , has garnered over 166 user ratings averaging 4.8 out of 5, reflecting its reliability for running titles such as on platforms including Windows, , and macOS. Its latest stable release, version 0.74-3 from 2019, includes security patches for vulnerabilities like CVE-2019-7165, ensuring safe execution of untrusted legacy code. is integrated into platforms like for seamless DOS game distribution, underscoring its enduring impact on retro computing preservation. DOSBox-X, a feature-rich fork originating from DOSBox SVN Daum in 2012, extends the original's capabilities for more accurate emulation of DOS API interactions, including support for DOS-based Windows versions like 3.x and 9x. It offers advanced hardware emulation for peripherals such as Voodoo cards, networking, and printing, making it suitable for both gaming and productivity applications that demand precise handling. Available for Windows, , macOS, and even DOS itself, DOSBox-X emphasizes historical fidelity and new DOS development, with ongoing updates as of 2025. Community discussions highlight its superiority for complex setups over vanilla DOSBox, particularly in audio emulation like OPL3. DOSBox Staging, launched as a modern continuation of around 2019, incorporates contemporary development practices while maintaining configuration compatibility. It excels in visual authenticity through zero-configuration CRT emulation, supporting modes from to SVGA at resolutions up to 4K, which enhances the rendering of DOS API-driven without manual tweaks. Key features include automatic display adjustments and improved event handling for users, with the latest stable release at version 0.82.2. This emulator is favored for its balance of performance and retro aesthetics in gaming scenarios. For users seeking cycle-accurate hardware simulation beyond variants, stands out as a low-level x86 emulator that recreates entire PC systems from the PC 5150 era through the PCI bus period. It supports alongside and early Windows, emulating processors from 8086 to with peripherals like controllers and interfaces via . The latest version, 5.2 released on October 26, 2025, builds on version 5.0 (August 2025) which introduced smoother mouse input and 3.0 enhancements, expanding its machine library to over 288 configurations. 's hypervisor-like interface differentiates it by prioritizing full-system accuracy over DOS-specific optimizations, appealing to enthusiasts emulating DOS API behaviors in authentic contexts. Emerging options like Pure Unleashed, a 2025 standalone release derived from the core DOSBox Pure, further diversify the landscape with features tailored for ease of use, such as ZIP archive game loading, save states, and experimental support up to 4K with Voodoo emulation. After five years of development, it provides controller mappings and CRT filters in a compact 1.5MB package for Windows, macOS, and , targeting portable retro gaming without broader ecosystem dependencies.

Use in Contemporary Software Development

In contemporary software development, the DOS API remains relevant primarily through , an open-source DOS-compatible operating system that enables developers to create, compile, and run new programs targeting legacy environments or low-resource hardware. includes a suite of modernized tools such as the NASM assembler (version 2.16.03) for x86 code generation and compilers like Open Watcom and , allowing developers to write applications that leverage DOS interrupts like INT 21h for file I/O and system services. These tools support writing utilities, games, and custom software, with available under open licenses for modification and extension. Educational applications represent another key use, where serves as a platform in university courses to teach low-level programming, handling, and operating system concepts. For instance, students can develop programs that interact directly with hardware via DOS API calls, such as for disk operations, fostering understanding of real-mode execution on modern virtual machines. This approach is particularly valuable for illustrating historical computing paradigms while running on contemporary hardware like x86 emulators. In embedded systems, the DOS API finds niche application in resource-constrained devices requiring deterministic behavior and direct hardware access. Modules like the embeddedTS TS-4400, preloaded with 1.2, allow developers to program in C/C++, Pascal, or , using API functions for interfacing with peripherals such as USB, , and ISA buses without the overhead of a full modern OS. Developers compile code on host machines and deploy via USB or Ethernet, enabling single-purpose applications like industrial controllers that boot directly into custom DOS-based software. Similarly, minimal configurations—limited to a kernel, configuration file, and one application—support embedded tasks such as point-of-sale systems or interfaces, where the API's simplicity ensures reliability in environments with as little as 8 MB RAM. Recent advancements, including the FreeDOS 1.4 release in 2025, enhance development support with an updated FreeCOM shell, improved package management akin to tools, and fixes to extenders like HDPMI for better interrupt handling (e.g., INT 25h/26h for direct disk access). These updates facilitate the creation of new DOS utilities and ensure compatibility with modern hardware, sustaining the API's utility for specialized, lightweight software projects.

References

  1. https://computerhistory.org/blog/microsoft-ms-dos-early-source-code/
  2. https://www.pcjs.org/documents/books/mspl13/msdos/encyclopedia/section5/
  3. https://www.pcjs.org/documents/books/mspl13/msdos/dosref40/#1.1-introduction
  4. https://www.pcjs.org/documents/books/mspl13/msdos/dosref40/#1.10.2-calling-a-function-request
  5. https://www.pcjs.org/documents/books/mspl13/msdos/dosref40/#chapter-1-system-calls
  6. https://www.pcjs.org/documents/books/mspl13/msdos/dosref40/#chapter-4
  7. https://www.os2museum.com/wp/dos/dos-1-0-and-1-1/
  8. https://devblogs.microsoft.com/commandline/re-open-sourcing-ms-dos-1-25-and-2-0/
  9. http://www.os2museum.com/wp/86-dos-was-an-original/
  10. https://arstechnica.com/gadgets/2017/07/ibm-pc-history-part-2/
  11. https://www.historylink.org/File/2118
  12. https://pcdosretro.gitlab.io/doshist.txt
  13. https://www.pcjs.org/documents/books/mspl13/msdos/encyclopedia/#section-v-system-calls
  14. http://www.techhelpmanual.com/831-dos_versions.html
  15. https://www.pcjs.org/documents/books/mspl13/msdos/encyclopedia/#appendix-a-ms-dos-version-3.3
  16. https://betawiki.net/wiki/Multitasking_MS-DOS_4
  17. https://bitsavers.org/pdf/ibm/pc/dos/6138536_DOS_3.10_Technical_Reference_Preliminary_Feb85.pdf
  18. https://thestarman.pcministry.com/asm/mbr/IVT.htm
  19. https://www.pcjs.org/documents/books/mspl13/msdos/encyclopedia/section2/
  20. https://www.ctyme.com/rbrown.htm
  21. https://www.ctyme.com/intr/int-21.htm
  22. https://www.ctyme.com/intr/int-20.htm
  23. https://www.ctyme.com/intr/int-22.htm
  24. https://www.ctyme.com/intr/int-23.htm
  25. https://www.ctyme.com/intr/int-24.htm
  26. https://www.ctyme.com/intr/int-25.htm
  27. https://www.ctyme.com/intr/int-26.htm
  28. https://www.ctyme.com/intr/int-27.htm
  29. https://www.ctyme.com/intr/int-2f.htm
  30. https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24063
  31. https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/july/under-the-hood-happy-10th-anniversary-windows
  32. https://learn.microsoft.com/en-us/windows/compatibility/ntvdm-and-16-bit-app-support
  33. https://j00ru.vexillium.org/slides/2013/zeronights.pdf
  34. https://www.os2museum.com/wp/os2-history/os2-1-0/
  35. https://www.weather.gov/media/wrh/online_publications/TAs/ta9211.pdf
  36. https://www.freedos.org/
  37. https://hackaday.com/2025/08/06/jennys-daily-drivers-freedos-1-4/
  38. https://www.retrotechnology.com/dri/dri_wein.html
  39. https://handwiki.org/wiki/Software:DR-DOS
  40. http://www.dosemu.org/
  41. https://pages.cs.wisc.edu/~robj/dosvirtualized.doc
  42. http://www.dosemu.org/docs/README-tech/1.1.3.7/
  43. https://man.archlinux.org/man/dosemu.bin.1.en
  44. https://github.com/dosemu2/dosemu2
  45. https://archive.fosdem.org/2018/schedule/event/dosemu_and_freedos_past_present_future/attachments/slides/2466/export/events/attachments/dosemu_and_freedos_past_present_future/slides/2466/dosemu_freedos.pdf
  46. https://forums.freebsd.org/threads/freebsd-and-dos-emulation.73579/
  47. https://www.usenix.org/publications/library/proceedings/sf94/full_papers/forin.pdf
  48. https://dosbox-x.com/
  49. https://www.dosbox.com/
  50. https://sourceforge.net/projects/dosbox/
  51. https://www.vogons.org/viewtopic.php?t=106507
  52. https://www.dosbox-staging.org/
  53. https://86box.net/
  54. https://www.tomshardware.com/video-games/retro-gaming/dosbox-pure-unleashed-is-ready-for-windows-mac-and-linux-computers-after-five-years-in-development-enhanced-standalone-release-no-longer-restricted-to-being-a-retroarch-core
  55. https://sourceforge.net/p/freedos/news/2024/05/nasm-21603/
  56. https://arstechnica.com/gadgets/2024/06/30-years-later-freedos-is-still-keeping-the-dream-of-the-command-prompt-alive/
  57. https://www.embeddedts.com/products/TS-4400
  58. https://opensource.com/article/21/6/freedos-embedded-system
  59. https://hackaday.com/2025/04/08/freedos-1-4-released/
  60. https://www.freedos.org/download/announce.html
Add your contribution
Related Hubs
User Avatar
No comments yet.