The DOS API

How to read this

If a DOS game starts, opens its data files, launches overlays, saves, and exits back to the shell, it is mostly living on this page. BIOS calls still handle hardware like keyboard, video, disk sectors, timers, and sound devices; INT 21h is the DOS contract layered above that hardware.

All recognized calls

This is every AH value the current INT 21h dispatcher recognizes. Supported means the behavior is backed by real state or disk data in LainDOS. Partial, narrow, compat, and stub mean the call exists for the compatibility surface games and tests currently need, but it should not be read as full MS-DOS coverage.

Subfunction boundaries

A recognized AH value does not always mean every AL subfunction exists. These are the narrow edges users are most likely to notice when a program probes DOS behavior.

Ready for text-mode installers, utilities, and the LainDOS shell.

These calls are the classic DOS way to print strings, read keys, poll the keyboard, and select the current drive. LainDOS routes them through the same console layer that writes to VGAVGAThe PC video standard LainDOS and the demos use for text and graphics output. text memory and COM1COM1The first PC serial port. LainDOS uses it as the primary machine-readable debug log., so user-visible text also appears in the serial logserial logCaptured COM1 text output, used by tests to detect PASS, FAIL, exceptions, and unhandled DOS calls. when useful.

For end users this means simple command-line tools, batch files, and setup programs have the basic terminal behavior they expect. It is not a full ANSI terminal, but it covers the plain DOS console style used by the current test ladder.

The core file API is in place for real game data and save writes.

This is the compatibility surface most games hit first: make and remove directories, change directory, create/open/close/read/write/seek files, delete, rename, get or set attributes, get or set file timestamps, create temporary files, create-new, and commit writes.

LainDOS deliberately handles real FAT writeback here: truncating an existing writable file frees its old cluster chain, writes update file size and directory metadata, rename refuses read-only/open files, and commit flushes both the directory entry and FAT.

Shell-launched COM/EXE programs, overlays, TSR exits, and PSP probes are supported.

When SHELL.COM starts another program, it uses EXEC. LainDOS loads the child image, builds a PSPPSPThe DOS data block placed before each program, holding terminate vectors, the job file table, command tail, and environment pointer., supplies the command tail and child-owned environment, inherits the parent's fixed PSPPSPThe DOS data block placed before each program, holding terminate vectors, the job file table, command tail, and environment pointer. handle table, applies EXE relocations, and restores the parent after the child exits.

The default environment includes COMSPEC, PATH, PROMPT, and a conventional SB16SB16Sound Blaster 16 audio hardware. QEMU exposes the DSP path with -device sb16; some games also need the separate -device adlib OPL path. BLASTER string so games launched under QEMUQEMUThe default fast emulator for automated LainDOS builds, tests, monitor probes, and game smoke runs.'s -device sb16 can detect the emulator-provided sound card.

For users this is why typing midemo at A:\> works instead of needing a direct-boot image. The same path also supports overlay loads, TSR-style keep-process exits used by runtime helpers such as DPMIDPMIDOS Protected Mode Interface, the service layer many protected-mode DOS programs expect from an extender or host. hosts, and set/get PSPPSPThe DOS data block placed before each program, holding terminate vectors, the job file table, command tail, and environment pointer. probes used by older runtimes.

Directory searches work across the current directory and drive-qualified paths.

DOS programs do not get directory listings as one big array. They set a Disk Transfer AreaDTAThe DOS buffer where FindFirst/FindNext and some FCB calls return directory search results., call FindFirst with a wildcard and attribute mask, then call FindNext until DOS reports no more matches.

LainDOS stores search state in the DTADTAThe DOS buffer where FindFirst/FindNext and some FCB calls return directory search results. and understands root paths, subdirectories, drive-qualified relative paths, wildcard attributes, timestamps, and current-directory queries.

Older DOS programs may also use FCB FindFirst/FindNext. LainDOS covers the current-directory 8.3 search path needed by Civilization startup, including extended-FCB attribute masks, returning AL status and a drive byte plus raw directory entry at the DTADTAThe DOS buffer where FindFirst/FindNext and some FCB calls return directory search results..

Conventional-memory allocation is backed by a real MCB chain.

DOS games ask for memory in 16-byte paragraphs. LainDOS tracks those allocations with Memory Control Blocks, supports allocate/free/resize, and exposes allocation strategy so programs that probe DOS behavior see plausible first-fit, best-fit, and last-fit behavior.

This matters for older games and utilities that inspect the largest executable program size, allocate temporary buffers, or expect parent and child processes to release their memory cleanly.

Common DOS device checks and standard handles are implemented.

Programs often ask DOS whether a handle is a character device, whether input is ready, whether output can proceed, or whether a drive is removable/local. Those checks go through IOCTL rather than normal file reads.

LainDOS answers the IOCTL functions used by the current suite and maps DOS device names so tools can open CON, write to NUL, duplicate handles, or detect console readiness without creating fake files on disk.

Compatibility probes return stable DOS-like answers or explicit unsupported-LFN status.

Many programs do not immediately open files. They first ask DOS what version it is, what drive is current, how much disk space is free, what the date/time is, or where an interrupt vector points.

LainDOS answers these probes with DOS 3.30-style behavior where that helps old games, returns real disk-free counts from the FAT, keeps enough vector/date/verify state for installers and utilities to continue, and includes narrow FCB compatibility used by older probes and launchers.

Newer DOS-extender runtimes also hit internal and Windows-era compatibility probes. LainDOS now canonicalizes truename paths, returns a minimal DOS swappable-data-area pointer for AX=5D06h, and reports unsupported long-filename APIs with AX=7100h so DJGPP-style callers can fall back to 8.3 searches.

What is intentionally not complete

LainDOS is not trying to be a replacement for every DOS installation. It grows from target programs and regression tests, so unsupported APIs are treated as new compatibility work rather than hidden magic.