Hubbry Logo
Virtual DOS machineVirtual DOS machineMain
Open search
Virtual DOS machine
Community hub
Virtual DOS machine
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Virtual DOS machine
Virtual DOS machine
Virtual DOS machine
View on Wikipedia
from Wikipedia

Virtual DOS machines (VDM) refer to a technology that allows running 16-bit/32-bit DOS and 16-bit Windows programs when there is already another operating system running and controlling the hardware.

Overview

[edit]

Virtual DOS machines can operate either exclusively through typical software emulation methods (e.g. dynamic recompilation) or can rely on the virtual 8086 mode of the Intel 80386 processor, which allows real mode 8086 software to run in a controlled environment by catching all operations which involve accessing protected hardware and forwarding them to the normal operating system (as exceptions). The operating system can then perform an emulation and resume the execution of the DOS software.

VDMs generally also implement support for running 16-bit and 32-bit protected mode software (DOS extenders), which has to conform to the DOS Protected Mode Interface (DPMI).[1]

When a DOS program running inside a VDM needs to access a peripheral, Windows will either allow this directly (rarely), or will present the DOS program with a virtual device driver (VDD) which emulates the hardware using operating system functions. A VDM will systematically have emulations for the Intel 8259A interrupt controllers, the 8254 timer chips, the 8237 DMA controller, etc.[1]

Concurrent DOS 8086 emulation mode

[edit]

In January 1985 Digital Research together with Intel previewed Concurrent DOS 286 1.0,[2] a version of Concurrent DOS capable of running real mode DOS programs in the 80286's protected mode.[2] The method devised on B-1 stepping processor chips, however, in May 1985 stopped working on the C-1 and subsequent processor steppings shortly before Digital Research was about to release the product. Although with the E-1 stepping Intel started to address the issues in August 1985, so that Digital Research's "8086 emulation mode" worked again utilizing the undocumented LOADALL processor instruction,[3][4] it was too slow to be practical. Microcode changes for the E-2 stepping improved the speed again.[5][6] This early implementation can be seen as a predecessor to actual virtual DOS machines.

Eventually, Concurrent DOS 286 was reworked from a potential desktop operating system to become FlexOS 286 for industrial use in 1986.[7][8] It was also licensed by IBM for their 4680 OS in 1986.[9][10]

When Intel's 80386 with its virtual 8086 mode became available (as samples since October 1985 and in quantities since June 1986), Digital Research switched to use this to run real mode DOS programs in virtual DOS machines in protected mode under Concurrent DOS 386 1.0 (February 1987)[11] and FlexOS 386 1.0 (June 1987).[12] However, the architecture of these multiuser multitasking protected mode operating systems was not DOS-based by themselves.

Concurrent DOS 386 was later developed to become Multiuser DOS (since 1991) and REAL/32 (since 1995). FlexOS 386 later became 4690 OS in 1993.

DOS-based VDMs

[edit]

In contrast to these protected mode operating systems, DOS, by default, is a real-mode operating system, switching to protected mode and virtual 86 mode only on behalf of memory managers and DOS extenders in order to provide access to extended memory or map in memory into the first megabyte, which is accessible to normal DOS programs.

DOS-based VDMs appeared with Microsoft's Windows/386 2.01 in September 1987.[13] DOS-based virtual DOS machines were also present in Windows 3.0, 3.1x and Windows for Workgroups 3.1x running in 386 Enhanced Mode as well as in Windows 95, 98, 98 SE and ME. One of the characteristics of these solutions running on top of DOS is that the memory layout shown inside virtual DOS machines are virtual instances of the DOS system and DOS driver configuration run before the multitasker is loaded, and that requests which cannot be handled in protected mode are passed down into the system domain to be executed by the underlying DOS system.

Similar to Windows 3.x 386 Enhanced Mode in architecture, EMM386 3.xx of Novell DOS 7,[1][14] Caldera OpenDOS 7.01,[14][15] DR-DOS 7.02[16] (and later) also uses DOS-based VDMs to support pre-emptive multitasking of multiple DOS applications, when the EMM386 /MULTI option is used.[14][15][16] This component has been under development at Digital Research / Novell since 1991[nb 1] under the codename "Vladivar" (originally a separate device driver KRNL386.SYS[1][14] instead of a module of EMM386). While primarily developed for the next major version of DR DOS, released as Novell DOS 7 in 1994,[1][14] it was also used in the never released DR DOS "Panther" and "Star Trek" project in 1992/1993.

OS/2 MVDM

[edit]

Multiple virtual DOS machines (MVDM) are used in OS/2 2.0 and later since 1992.[1][4] OS/2 MVDMs are considerably more powerful than NTVDM. For example, block devices are supported, and various DOS versions can be booted into an OS/2 MVDM.[17] While the OS/2 1.x DOS box was based on DOS 3.0, OS/2 2.x MVDMs emulate DOS 5.0.[1]

Seamless integration of Windows 3.1 and later Win32s applications in OS/2 is a concept looking similar on surface to the seamless integration of XP Mode based on Windows Virtual PC in Windows 7. A redirector in a "guest" VDM or NTVDM allows access on the disks of the OS/2 or NT "host". Applications in a "guest" can use named pipes for communication with their "host".[18]

Due to a technical limitation, DOS and 16-bit Windows applications under OS/2 were unable to see more than 2 GB of hard drive space;[19] this was fixed in ArcaOS 5.0.4.[20]

Windows NTVDM

[edit]
COMMAND.COM running in the NTVDM of Windows 10

NTVDM is a system component of all IA-32 editions of the Windows NT family since 1993 with the release of Windows NT 3.1. It allows execution of 16-bit Windows and 16-bit / 32-bit DOS applications. The Windows NT 32-bit user-mode executable which forms the basis for a single DOS (or Windows 3.x) environment is called ntvdm.exe.[1]

In order to execute DOS programs, NTVDM loads NTIO.SYS which in turn loads NTDOS.SYS, which executes a modified COMMAND.COM in order to run the application that was passed to NTVDM as command-line argument. The 16-bit real-mode system files are stripped down derivations of their MS-DOS 5.0 equivalents IO.SYS, MSDOS.SYS and COMMAND.COM[1] with all hard-wired assumptions on the FAT file system removed and using the invalid opcode 0xC4 0xC4 to bop down into the 32-bit NTVDM to handle the requests.[1] Originally, NTDOS reported a DOS version of 30.00 to programs,[1] but this was soon changed to report a version of 5.00 at INT 21h/AH=30h and 5.50 at INT 21h/AX=3306h to allow more programs to run unmodified.[1] This holds true even in the newest releases of Windows; many additional MS-DOS functions and commands introduced in MS-DOS versions 6.x and in Windows 9x are missing.

There was a well-known issue within NTVDM in Windows 2000, where the lack of the NT branding resulted in frequent crashes and instabilities, spurred by the 2-month-long debate between Bill Gates and Jim Allchin.[21]

16-bit Windows applications by default all run in their own thread within a single NTVDM process. Although NTVDM itself is a 32-bit process and pre-emptively multitasked with respect to the rest of the system, the 16-bit applications within it are cooperatively multitasked with respect to each other. When the "Run in separate memory space" option is checked in the Run box or the application's shortcut file, each 16-bit Windows application gets its own NTVDM process and is therefore pre-emptively multitasked with respect to other processes, including other 16-bit Windows applications. NTVDM emulates BIOS calls and tables as well as the Windows 3.1 kernel and 16-bit API stubs.[22] The 32-bit WoW translation layer thunks 16-bit API routines.

32-bit DOS emulation is present for DOS Protected Mode Interface (DPMI) and 32-bit memory access. This layer converts the necessary extended and expanded memory calls for DOS functions into Windows NT memory calls. wowexec.exe is the emulation layer that emulates 16-bit Windows. Windows XP added Sound Blaster 2.0 emulation.[23] 16-bit virtual device drivers and DOS block device drivers (e.g., RAM disks) are not supported. Inter-process communication with other subsystems can take place through OLE, DDE and named pipes.

Since virtual 8086 mode is not available on non-x86-based processors (more specifically, MIPS, DEC Alpha, and PowerPC) NTVDM is instead implemented as a full emulator in these versions of NT, using code licensed from Insignia's SoftPC.[1] Up to Windows NT 3.51, only 80286 emulation is available. With Windows NT 4.0, 486 emulation was added.[24]

NTVDM is not included with 64-bit versions of Windows or ARM32 based versions such as Windows RT or Windows 10 IoT Core. The last version of Windows to include the component is Windows 10, as Windows 11 dropped support for 32-bit processors.

Commands

[edit]

The following 16-bit commands for MS-DOS subsystem are included with Windows XP.[18]

Security issue

[edit]

In January 2010, Google security researcher Tavis Ormandy revealed a serious security flaw in Windows NT's VDM implementation that allowed unprivileged users to escalate their privileges to SYSTEM level, noted as applicable to the security of all x86 versions of the Windows NT kernel since 1993. This included all 32-bit versions of Windows NT, 2000, XP, Server 2003, Vista, Server 2008, and Windows 7.[25] Ormandy published a proof-of-concept exploit for the vulnerability.[26] Prior to Microsoft's release of a security patch, the workaround for this issue was to turn off 16-bit application support, which prevented older programs (those written for DOS and Windows 3.1) from running. 64-bit versions of Windows are not affected since the NTVDM subsystem is not included.[27][28] Once the Microsoft security patches had been applied to the affected operating systems the VDM could be safely reenabled.[nb 2]

Limitations

[edit]

A limitation exists in the Windows XP 16-bit subsystem (but not in earlier versions of Windows NT) because of the raised per-session limit for GDI objects which causes GDI handles to be shifted to the right by two bits, when converting them from 32 to 16 bits.[29] As a result, the actual handle cannot be larger than 14 bits and consequently 16-bit applications that happen to be served a handle larger than 16384 by the GDI system crash and terminate with an error message.[29]

In general, VDM and similar technologies do not satisfactorily run most older DOS games on today's computers. Emulation is only provided for the most basic peripherals, often implemented incompletely[citation needed]. For example, sound emulation in NTVDM is very limited. NT-family versions of Windows only update the real screen a few times per second when a DOS program writes to it, and they do not emulate higher resolution graphics modes. Because software mostly runs native at the speed of the host CPU, all timing loops will expire prematurely. This either makes a game run much too fast or causes the software not even to notice the emulated hardware peripherals, because it does not wait long enough for an answer.

Absence in x64 and AArch64 architectures

[edit]

In an x86-64 CPU, virtual 8086 mode is available as a sub-mode only in its legacy mode (for running 16- and 32-bit operating systems), not in the native 64-bit long mode.[30] NTVDM is not supported on x86-64 editions of Windows,[31] including DOS programs,[32] because NTVDM uses VM86 CPU mode instead of the Local Descriptor Table in order to enable 16‑bits segment required for addressing.[33] NTVDM is also unavailable on AArch64 (or ARM64) versions of Windows (such as Windows RT), because Microsoft did not release a full emulator for this incompatible instruction set like it did on previous incompatible architectures.

While NTVDM is not supported on x86-64 and AArch64 versions of Windows, they can still be run using virtualization software, such as Windows XP Mode in non-home versions of Windows 7 or VMware Workstation. Other methods include using ReactOS-derived NTVDM,[34] or OTVDM (WineVDM), a 16-bit Windows interpreter based on MAME's i386 emulation and the 16-bit portion of the popular Windows compatibility layer, Wine (see the section on WineVDM below).[35]

WineVDM

[edit]

A VDM is included in Wine and CrossOver for Linux and Mac OS X, known as WineVDM (also known as OTVDM). It has also been ported to Windows itself, as 64-bit versions of Windows do not include the NTVDM subsystem (see above).[36][non-primary source needed]

See also

[edit]

Notes

[edit]

References

[edit]

Further reading

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

Virtual DOS machine

View on Grokipedia
from Grokipedia
A Virtual DOS Machine (VDM), also known as NTVDM in the context of Windows NT-based operating systems, is a protected environment subsystem designed to emulate the operating system and 16-bit Windows environments, allowing legacy 16-bit DOS and Windows applications to run within 32-bit Windows architectures. Introduced as part of the lineage starting with in 1993, VDM provides by creating isolated virtual machines that translate 16-bit instructions and calls into native 32-bit operations without requiring . The subsystem operates by launching a dedicated VDM —typically ntvdm.exe—for each 16-bit application, which isolates the legacy code to prevent interference with the host system's 32-bit processes and enhances security through execution. In multi-session environments like Server, multiple VDM instances can run concurrently, though they do not share code across sessions to maintain isolation, resulting in higher resource consumption compared to native 32-bit applications due to the translation overhead. For 16-bit Windows (Win16) applications, VDM leverages (WOW) layering to handle and , simulating the original Windows 3.x environment while integrating with the Win32 . Historically, VDM technology originated in IBM's OS/2 operating system with OS/2 2.0 in 1992 as a means to support DOS applications on protected-mode platforms, influencing Microsoft's implementation in Windows NT to address enterprise needs for legacy software compatibility. Over time, its relevance diminished with the introduction of 64-bit Windows editions (lacking NTVDM support since Windows XP 64-bit in 2003), and as of 2025, following the end-of-life of Windows 10 on October 14, 2025, native NTVDM support is discontinued in actively supported Windows versions, though third-party emulators and workarounds persist for running DOS-era programs. Key APIs like VDMEnumTaskWOWEx and process creation flags such as CREATE_SEPARATE_WOW_VDM enable developers to manage and debug VDM instances, underscoring its role in debugging and enumeration of 16-bit tasks.

Overview

Definition and Purpose

A Virtual DOS Machine (VDM) is a virtualized environment that emulates the application programming interface (API) of or PC DOS, enabling 16-bit DOS applications to execute on 32-bit or higher architectures lacking native real-mode hardware support. This emulation occurs within a protected-mode process, where the VDM provides a simulated DOS kernel and hardware abstraction layer, allowing legacy software to interact with system resources as if running on original 8086-based systems. The primary purpose of a VDM is to ensure for legacy DOS software in modern multitasking operating systems, permitting these applications to run alongside native programs without requiring a full into a separate DOS environment. By isolating each DOS session in its own —typically limited to 1 MB for the application while leveraging services—a VDM prevents crashes or faults in one DOS program from destabilizing the host system or other running applications. This isolation enhances system stability and resource sharing in protected-mode environments. At its core, a VDM relies on the virtual 8086 (V86) mode of processors, introduced in the Intel 80386, which simulates real-mode execution within a protected-mode context. In V86 mode, the processor sets the VM flag in the EFLAGS register to execute 8086-compatible instructions directly on a virtualized 1 MB , while trapping sensitive operations (such as interrupts and I/O) for emulation by the host operating system. This hardware-assisted allows DOS applications to perform direct hardware access, such as video output or disk I/O, through virtual device drivers that mediate between the guest and host. VDMs target legacy applications from the and that depend on real-mode operations, including text-based utilities for , classic games requiring direct graphics hardware manipulation, and for or . Early precursors, such as Concurrent DOS, laid groundwork for this approach by introducing multitasking for DOS sessions on 286 processors.

Historical Context

During the , dominated personal computing as the primary operating system for PC compatibles, but it operated exclusively in , severely limiting its capabilities to 640 kilobytes of for applications and providing no native support for multitasking. This constraint stemmed from the processor's 20-bit addressing scheme, which allowed only 1 of total , with the upper 384 kilobytes reserved for system ROM, video , and expansion hardware to ensure hardware expandability. As software demands grew for more memory-intensive and concurrent operations, these real-mode limitations became a significant barrier to advancing toward protected-mode operating systems capable of leveraging larger memory spaces and true multitasking. The introduction of Intel's 80386 microprocessor in October 1985 marked a pivotal technological shift, enabling protected-mode execution with a 32-bit that supported up to 4 gigabytes of physical memory and 64 terabytes of through segmentation and paging. Central to this was the processor's , which allowed real-mode DOS code to run within isolated, protected environments under a multitasking host OS, trapping direct hardware accesses and interrupts to prevent system-wide instability. This hardware foundation addressed the growing need for with the vast DOS software ecosystem while supporting the transition to more robust 32-bit operating systems. In response to DOS's shortcomings, IBM and Microsoft initiated a joint development effort for OS/2 in 1985, culminating in the release of OS/2 1.0 in December 1987, which introduced basic DOS compatibility sessions on 80286 processors but supported only a single session at a time and suffered from poor integration due to the lack of advanced virtualization. Early attempts to run DOS applications on these multitasking systems often resulted in crashes or required reboots, as DOS programs directly manipulated hardware without memory protection, risking corruption of the host environment and highlighting the need for virtualized isolation. The partnership frayed by 1990 amid disputes over direction and licensing, leading Microsoft to pursue Windows NT independently, released in 1993, while IBM advanced OS/2 2.0 in 1992—both paths relying on 80386-enabled emulation to sustain 16-bit DOS application support amid the shift to protected-mode architectures.

Early Implementations

Concurrent DOS 8086 Emulation Mode

The 8086 Emulation Mode in Concurrent DOS, developed by , enabled the execution of multiple real-mode DOS tasks within a multitasking operating system environment on 80386 processors emulating an 8086/8088 environment, serving as an early mechanism for concurrent program operation without full . This mode integrated PC-DOS and compatibility, allowing users to run standard DOS applications alongside native Concurrent tasks through a that managed processor time slices among active programs. Released as part of Concurrent PC DOS 386 in late , the emulation mode leveraged the 80386 processor's capabilities to support up to four virtual consoles, each hosting an independent DOS session via time-sliced scheduling at intervals of approximately 1/60th of a second. It permitted expanded allocation beyond the conventional 640 KB limit of standard DOS systems, typically several megabytes per task when using compatible expanded boards such as those from AST, facilitating early multitasking on 386-based hardware. Device arbitration features prevented conflicts, such as simultaneous printer access, while background tasks like print spoolers operated without dedicating a console. The mode utilized the 80386's to emulate real-mode tasks within a environment, providing isolation between tasks and reducing risks from faulty applications compared to pure real-mode operation, though direct hardware access could still cause issues. Programs bypassing calls, such as those writing directly to video , often failed to coexist properly in windows, leading to display conflicts or instability. As a precursor to more robust virtual DOS machines, it prioritized compatibility and basic concurrency over comprehensive .

DOS-Based Virtual DOS Machines

DOS-based virtual DOS machines represent early attempts to introduce multitasking capabilities directly within the MS-DOS and PC DOS environments, enabling users to run and switch between multiple DOS sessions or applications without full operating system overhauls. These extensions relied on software-based techniques to simulate , primarily through task switchers that suspended and resumed programs, bridging the gap from single-tasking DOS to more advanced systems like OS/2. Key examples include the Task Swapper utility in 5.0, released in 1991, which integrated with the MS-DOS Shell to allow loading and switching between up to 13 applications by swapping their memory images to disk or expanded memory. Similarly, 6.0, released in 1991, incorporated TaskMAX, a terminate-and-stay-resident (TSR) program that supported switching among up to 20 tasks, including multiple instances of the same application or separate DOS command interpreters. These tools operated on non-preemptive multitasking principles, where programs ran cooperatively until manually switched or interrupted, often using TSR mechanisms to remain in and into DOS interrupts for context switching. In 5.0's Task Swapper, users activated switching via hotkeys like within the Shell, which froze the current task and loaded another from a swap file, optimizing for systems with limited RAM by leveraging expanded standards like EMS if available. TaskMAX in extended this with enhanced management, moving tasks between conventional, expanded, and via XMS drivers, and supporting features like data copying between applications and customizable swap files for disk-based storage of inactive sessions. This approach provided pseudo-virtualization by maintaining isolated task environments, though it was limited to software emulation without hardware support, prone to conflicts from incompatible TSRs or overlaps. Microsoft's historical reluctance to fully integrate native multitasking into stemmed from challenges encountered in developing the multitasking variant of 4.0 in the mid-1980s, which supported preemptive tasking and but faced compatibility issues with existing software and lacked OEM adoption, leading to its abandonment in favor of the joint IBM-Microsoft project. As a result, 5.0's Task Swapper served as a lightweight, built-in solution reliant on third-party-like TSR techniques, while competitors like filled gaps with more robust tools such as TaskMAX until the shift to protected-mode operating systems. These DOS-hosted innovations acted as precursors to true virtual DOS machines, demonstrating the feasibility of session isolation on real-mode kernels but highlighting the need for in later implementations.

OS/2 Implementation

Multiple Virtual DOS Machines (MVDM)

The Multiple Virtual DOS Machines (MVDM) subsystem debuted with 2.0 in March 1992, developed by as a core component for running multiple DOS applications concurrently within a 32-bit protected-mode operating system. This represented a significant advancement over the single-session DOS Compatibility Box in earlier versions, enabling isolated execution of legacy DOS software alongside native and Windows applications without compromising system stability. MVDM leveraged the 80386 processor's capabilities to provide a fully virtualized environment, marking 's independent evolution of the platform following the 1990 split from . At its core, each MVDM instance operates in a separate virtual 8086 (V86) mode, emulating an 8086/8088 environment within to ensure isolation between sessions and the host kernel. This architecture uses protected-mode tasks for and per-VDM state management, preventing one DOS application from interfering with others or native processes. Sessions are preemptively multitasked by the OS/2 scheduler, supporting simultaneous execution in windowed or full-screen modes; within multi-application VDMs (MAVDMs), handles interactions among DOS programs. DOS interrupts are handled through software emulation via virtual device drivers like VPIC.SYS (Virtual Programmable Interrupt Controller), which translates hardware events and routes them at privilege level 3 for efficient processing. MVDM integrates seamlessly with OS/2's Workplace Shell, allowing users to launch and manage DOS sessions as desktop objects with customizable settings via the DOS Settings dialog, such as video mode and allocation. Each session supports up to 630 KB of base in , plus the 64 KB High Memory Area (HMA), Upper Memory Blocks (UMBs) from 640 KB to 1 MB, and via XMS 2.0 (up to system limits, often configured to 16 MB or more) and expanded via LIM EMS 4.0 (up to 32 MB). It emulates DOS APIs from versions 3.3 through 5.0, including all documented interrupts like INT 21h for services and INT 31h for DPMI 0.9 mode switching, while supporting terminate-and-stay-resident (TSR) programs and device drivers in UMBs. This preemptive design provided superior stability for DOS multitasking compared to Windows 3.1's model, where a hung application could disrupt the entire system.

Features and Capabilities

The Multiple Virtual DOS Machines (MVDM) subsystem in offers core features that facilitate the execution of DOS applications alongside native OS/2 programs. It supports both full-screen and windowed DOS sessions, allowing users to switch modes for optimal interaction, such as using Alt+Home for toggling in certain configurations. Printer and redirection enables DOS output to route through OS/2's spooler or virtual device drivers, integrating legacy printing and communication needs with the host system's resources. sharing further bridges environments by permitting text and graphics exchange between VDMs, OS/2 Presentation Manager applications, and Windows sessions, with shortcuts like Ctrl+Esc for full-screen "Copy All" operations. MVDM's capabilities extend to robust and resource access, supporting EGA and VGA via virtual drivers like VVGA.SYS and VEGA.SYS, which ensure compatibility for graphical DOS software in both single-plane background modes and foreground displays. Sound is managed through OS/2's native audio drivers, including PC speaker access (limited to one VDM at a time via toggles like HW_NOSOUND) and CD-ROM audio support with VCDROM. Networking integration occurs via NDIS drivers and named pipes, enabling DOS applications to utilize OS/2's LAN resources, although exclusive adapter access may apply in multi-VDM scenarios. The system accommodates multiple concurrent VDMs through pre-emptive multitasking, with each session allocated isolated EMS and XMS memory objects, constrained primarily by overall system resources. Unique to MVDM is its tight coupling with the Win-OS/2 environment, where 16-bit Windows applications execute in separate or shared VDMs for seamless desktop integration, often mandating VGA mode to leverage full graphical fidelity. This architecture provides enhanced crash isolation over traditional DOS extenders, as VDMs run in with dedicated memory spaces and handling; a in one session impacts only that VDM, preserving system stability without risking the entire kernel or other processes.

Windows NT Implementation

NTVDM Subsystem

The NT Virtual DOS Machine (NTVDM) was introduced in in 1993 as a user-mode subsystem that emulates the environment on the kernel, enabling the execution of 16-bit DOS and Windows applications on 32-bit x86 systems. This component serves as a , allowing legacy software to run without direct access to the underlying NT kernel, thereby maintaining system stability. Technically, NTVDM relies on the VDM.EXE process to create an emulated DOS session and employs WOWEXEC.EXE to initiate 16-bit Windows applications through the (WoW) layer, which translates 16-bit calls to 32-bit NT APIs. It provides support for 5.0 APIs, ensuring broad compatibility with DOS-based programs while operating within isolated virtual machine instances. NTVDM integrates seamlessly with the Windows NT security model, executing DOS applications under the invoking user's security context to enforce access controls and prevent unauthorized operations. Available exclusively on x86 32-bit editions of the family, it reflects Microsoft's post-OS/2 development priorities, where the NT kernel emphasized enterprise-level stability and portability over extensive consumer-oriented DOS extensions following the 1990 split with .

Usage and Commands

In Windows NT environments, the NTVDM subsystem automatically launches the NTVDM.exe process as the host when a user executes a 16-bit DOS application, providing the necessary emulation layer for compatibility. Manual invocation of NTVDM occurs by running COMMAND.COM from a Windows command prompt, which initiates a DOS session within the emulated environment. The primary command for direct execution is NTVDM.exe followed by the target DOS executable, such as ntvdm.exe c:\dos\app.exe, allowing standalone launch of DOS programs outside of automated subsystem triggers. Environment configuration for each NTVDM instance is managed through CONFIG.NT and files, located in the %SystemRoot%\System32 directory, which parallel traditional DOS and AUTOEXEC.BAT files to set device drivers, paths, and variables like EMS memory allocation. These files are processed upon NTVDM startup to tailor the virtual machine's setup for specific applications. For practical deployment, users can create shortcuts with the target path %windir%\system32\ntvdm.exe c:\dos\app.exe to streamline access to legacy DOS software, ensuring the application runs in a dedicated NTVDM session. Batch files (.BAT) execute seamlessly within an active DOS prompt hosted by NTVDM, inheriting the configured environment from AUTOEXEC.NT. NTVDM integrates with 16-bit Windows applications through the (WOW) layer, which operates within the same NTVDM to enable Win16 program execution, often visualized as a "WOWBOX" subprocess in task management tools. Console output redirection is supported via standard DOS devices like CON, directing text to the hosting window for interactive use.

Security Considerations

The NTVDM subsystem in Windows NT-based operating systems presents several security risks, particularly due to its emulation of legacy 16-bit environments, which can lead to and other exploits when running DOS or 16-bit Windows applications. A notable involves insufficient verification of execution permissions for 16-bit files, allowing local users to bypass access controls and run arbitrary code with elevated privileges, such as level. This issue affects , , and , enabling attackers with local access to execute unauthorized programs through the NTVDM loader without proper checks. Additional risks stem from flaws in NTVDM's interaction with the Windows kernel, which can facilitate local or denial-of-service attacks. For instance, improper validation of calls in the VDM_TIB allows crafted 16-bit applications to trigger unhandled exceptions in the kernel's #GP trap handler, potentially executing arbitrary in kernel mode. Similarly, handling errors in NTVDM enable local attackers to corrupt kernel , leading to privilege elevation or system crashes via specially crafted applications. These vulnerabilities impact 32-bit versions of through , as NTVDM operates in user mode but relies on elevated I/O and hardware emulation that lacks the isolation of modern sandboxes like Windows Sandbox. Unpatched or legacy 16-bit applications running under NTVDM are also susceptible to attacks, as the subsystem's model for compatibility exposes processes to inter-app interference without contemporary protections like (ASLR). Direct hardware access emulation in NTVDM further exacerbates risks, as emulated and I/O operations can be abused to induce denial-of-service conditions by overwhelming system resources or triggering kernel panics, especially from malicious or poorly written DOS programs. Affected systems include and XP, where NTVDM's design prioritizes backward compatibility over strict isolation, allowing user-mode faults to propagate to kernel-level instability. Microsoft has addressed several NTVDM-related issues through security updates, such as MS10-015 for call validation flaws and MS13-063 for memory corruption vulnerabilities, which improve input validation and memory handling to prevent escalation. For systems not requiring 16-bit support, mitigation involves disabling NTVDM via ("Prevent access to 16-bit applications" under Administrative Templates) or registry edits, such as setting a DWORD value to disable the subsystem under HKEY_LOCAL_MACHINE\SOFTWARE[Microsoft](/page/Microsoft)\Windows NT\CurrentVersion\WowExec, thereby eliminating the on non-essential setups.

Limitations and Architectural Constraints

The NT Virtual DOS Machine (NTVDM) subsystem imposes several core architectural limitations stemming from its reliance on the x86 Virtual 8086 (V86) mode for emulating 16-bit DOS environments. This mode is unavailable in 64-bit (x64) or ARM64 long mode architectures, rendering NTVDM unsupported on 64-bit editions of Windows, including all versions of Windows 11, which mandate x64 compatibility. Consequently, 16-bit DOS applications cannot run natively on these platforms without alternative emulation layers. Additionally, NTVDM supports emulated memory for DOS applications following standard DOS conventions, including extended memory (XMS) up to available system resources, though limited by the application's memory manager and configuration (e.g., via PIF files, often up to 64 MB or more for DPMI-hosted apps). In contrast to the OS/2 implementation, which supported multiple virtual DOS machines (MVDMs) for multitasking 16-bit sessions, each DOS application launches in its own separate NTVDM process, enabling multiple independent DOS environments to run concurrently within the same user session. This design choice simplifies resource management but may increase overhead for multiple apps compared to shared execution. Furthermore, NTVDM exhibits incompatibilities with (UAC), introduced in , where elevated privileges or UAC prompts can cause session instability or require disabling the feature for reliable operation of certain 16-bit applications. NTVDM's support lifecycle concluded with , the final 32-bit compatible edition, where mainstream servicing ended on October 14, 2025. Paid Extended Security Updates (ESU) are available through October 2028, offering security updates that may address NTVDM vulnerabilities. As of November 2025, no free updates or specific NTVDM revivals beyond ESU have been provided, aligning with the shift toward 64-bit-only architectures and modern application standards. These constraints, compounded by inherent security vulnerabilities that amplify exploitation risks in unpatched environments, have prompted users to resort to virtual machines for legacy DOS compatibility, though such workarounds introduce additional overhead.

Other Implementations and Alternatives

WineVDM

WineVDM serves as the 16-bit subsystem within the Wine compatibility layer, enabling the execution of legacy 16-bit Windows applications and DOS executables on non-Windows platforms such as and macOS. Developed as part of the open-source Wine project, it translates calls to equivalents in user space, avoiding the need for kernel-level or full . This approach allows WineVDM to integrate seamlessly with the host operating system's resources while providing a virtualized environment for older software. Technically, WineVDM builds on Wine's internal thunking layer, which functions similarly to Microsoft's (WOW) mechanism, facilitating communication between 16-bit Win16 applications and the 32-bit Wine runtime. For DOS executables, WineVDM detects the file type and delegates execution to , an integrated x86 emulator, ensuring compatibility for both text-mode utilities and graphical DOS programs. This integration was initially implemented in Wine development release 1.3.12 in January 2011, marking the project's shift from limited native DOS handling to leveraging for broader support. The subsystem operates entirely in user mode, prioritizing lightweight API translation over comprehensive system simulation. WineVDM's design emphasizes x86 architecture emulation via , with no native support for ARM-based systems, limiting its portability to x86/x64 hosts. As a core feature of Wine since version 1.7 and later stable releases, it has evolved to handle diverse legacy workloads, including early Windows 3.x applications. Key advantages include its cross-platform nature, enabling deployment across systems without platform-specific modifications, and its open-source status under the LGPL license, fostering community-driven improvements. Ongoing development as of 2025 continues to enhance legacy game compatibility, with Wine 10.16 introducing 16-bit application support in the new mode for better performance and stability in emulated environments.

Modern Third-Party Solutions

In the absence of official support for the NT Virtual DOS Machine (NTVDM) subsystem in 64-bit versions of Windows, including released in 2021, third-party developers have created open-source alternatives to enable running legacy DOS applications on modern operating systems. These solutions address the architectural constraints of native VDMs by providing emulation layers that mimic DOS environments with enhanced compatibility for x64, ARM64, and cross-platform use, often integrating seamlessly with contemporary hardware and features. DOSBox-X, an enhanced fork of the original DOSBox emulator, serves as a versatile third-party option for isolating and executing DOS programs, including support for DOS-based Windows versions like 3.x and 9x. It offers accurate x86 emulation in a contained environment, suitable for both gaming and productivity applications, and runs on Windows, , and macOS without requiring full virtualization. Community-driven since its inception as a DOSBox extension, DOSBox-X has evolved to include features like integration and configurable hardware emulation, making it a popular choice for users seeking VDM-like isolation on unsupported platforms. vDOS provides a lightweight, Windows-hosted specifically designed to replicate NTVDM functionality on 64-bit systems, allowing text-based DOS applications to run in a virtualized PC with direct access to the host and peripherals. Developed for non-gaming use cases, it automatically detects and launches DOS or 16-bit Windows executables, optimizing for business and legacy software that previously relied on NTVDM. As of May 2025, vDOS version 2025.05.01 remains actively maintained, with updates ensuring compatibility with and later, filling the gap left by Microsoft's deprecation of 16-bit support. OTVDM (also known as otya128/winevdm) is an open-source port of WineVDM to 64-bit Windows, enabling the execution of 16-bit Windows applications (Windows 1.x to 3.x) and DOS executables directly on modern Windows systems without full virtualization. It emulates the Win16 environment using Wine's libraries in user mode, supporting graphical and text-based legacy software, and integrates with the for seamless launching. Actively developed as of 2025, OTVDM offers features like installer support and bug fixes for specific applications, serving as a lightweight alternative to NTVDM for Windows users. NTVDMx64, a of the original NTVDM initiated in , extends DOS application execution to 64-bit Windows by emulating the 16-bit subsystem natively, enabling users to run executables like .com and .exe files directly from the desktop. This tool integrates with the Windows environment, preserving behaviors such as console output and printer redirection, though it requires administrative installation and may exhibit performance limitations on high-end hardware due to its emulation overhead. Updated as of April 2025, it continues to receive fixes for compatibility with recent Windows updates. Similarly, the davidly/ntvdm project, active in the 2020s, offers a modern reimplementation supporting x64 and ARM64 Windows, as well as and macOS, with low CPU usage for running DOS BASIC interpreters and command-line tools. For more comprehensive setups, third-party solutions increasingly incorporate full virtualization via tools like , where users can install complete DOS operating systems such as or in isolated virtual machines, providing VDM-equivalent separation without native OS dependencies. This approach has gained traction post-2021, as open-source communities emphasize containerized emulation to enhance security against legacy code vulnerabilities, reflecting a broader trend away from Microsoft's unsupported NTVDM toward portable, auditable alternatives.

References

  1. https://learn.microsoft.com/en-us/windows/compatibility/ntvdm-and-16-bit-app-support
  2. https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
  3. https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/terminal-server-startup-connection-application
  4. https://learn.microsoft.com/en-us/windows/win32/api/vdmdbg/nf-vdmdbg-vdmenumtaskwowex
  5. https://www.pcmag.com/encyclopedia/term/virtual-dos-machine
  6. https://archive.org/download/gg243731/gg243731_OS2_V2_0_Vol_2_DOS_and_Windows_Environment.pdf
  7. https://pdos.csail.mit.edu/6.828/2018/readings/i386.pdf
  8. https://www.filfre.net/2017/04/the-640-k-barrier/
  9. https://www.xtof.info/the-640k-memory-limit-of-ms-dos.html
  10. https://www.tomshardware.com/tech-industry/semiconductors/intel-386-at-40
  11. https://bitsavers.trailing-edge.com/components/intel/80386/231746-001_Introduction_to_the_80386_Apr86.pdf
  12. https://www.os2museum.com/wp/os2-history/os2-timeline/
  13. https://arstechnica.com/information-technology/2019/11/half-an-operating-system-the-triumph-and-tragedy-of-os2/
  14. http://www.bitsavers.org/pdf/digitalResearch/concurrent/Dahmke_Using_Concurrent_PC_DOS_1986.pdf
  15. https://bitsavers.org/pdf/digitalResearch/concurrent/1126-2004-001_Concurrent_DOS_386_Users_Guide_Nov87.pdf
  16. https://groups.google.com/g/comp.os.cpm/c/nkmmXatScLk
  17. http://jeffpar.github.io/kbarchive/kb/072/Q72182/
  18. https://bitsavers.trailing-edge.com/pdf/novell/dr_dos/DR_DOS_6.0_User_Guide_2ed_199108.pdf
  19. https://hackaday.com/2023/08/09/myth-tested-dos-cant-multitask/
  20. https://opensource.microsoft.com/blog/2024/04/25/open-sourcing-ms-dos-4-0
  21. https://starfrost.net/blog/001-mdos4-part-1/
  22. https://www.os2museum.com/wp/os2-history/os2-2-0/
  23. http://bitsavers.org/pdf/ibm/pc/os2/OS2_2.x/redbooks/GG24-3731-00_OS2_V2.0_Vol_2_DOS_and_Windows_Environment_199204.pdf
  24. https://www.edm2.com/index.php/Guide_to_Multitasking_Operating_Systems:Overview_of_the_OS/2_Operating_System
  25. https://www.os2museum.com/wp/nt-and-os2/
  26. https://www.file.net/process/ntvdm.exe.html
  27. https://betawiki.net/wiki/NTVDM
  28. http://smallvoid.com/article/winnt-autoexec-config.html
  29. https://learn.microsoft.com/en-us/answers/questions/3165307/editing-config-nt-for-win-10-32-bit-to-enable-ems
  30. https://nvd.nist.gov/vuln/detail/CVE-2002-2401
  31. https://nvd.nist.gov/vuln/detail/CVE-2010-0232
  32. https://nvd.nist.gov/vuln/detail/CVE-2013-3198
  33. https://learn.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-063
  34. https://j00ru.vexillium.org/slides/2013/zeronights.pdf
  35. https://www.vogons.org/viewtopic.php?t=15030
  36. https://github.com/leecher1337/ntvdmx64
  37. https://www.geekstogo.com/forum/topic/223053-ntvdmexe-stopped-working/
  38. https://support.microsoft.com/en-us/windows/windows-10-support-has-ended-on-october-14-2025-2ca8b313-1946-43d3-b55c-2b95b107f281
  39. https://learn.microsoft.com/en-us/windows/whats-new/extended-security-updates
  40. https://wiki.winehq.org/Wine_User%27s_Guide
  41. https://www.winehq.org/announce/1.3.12
  42. https://www.phoronix.com/news/OTAzMw
  43. https://gitlab.winehq.org/wine/wine/-/releases/wine-10.16
  44. https://dosbox-x.com/
  45. https://dosbox-x.com/wiki/
  46. https://vdos.info/
  47. https://vdos.info/FAQs.pdf
  48. https://filehippo.com/download_vdos/
  49. https://github.com/otya128/winevdm
  50. https://github.com/davidly/ntvdm
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.