How to Run Old Programs on Windows 11 (Even 16-Bit Apps From 1985)

The 32-bit FreeCell that Microsoft bundled with Win32s still runs on a current Windows 11 install. No patches, no emulator. You double-click FREECELL.EXE, dated 22-Feb-93, and deal a hand. enlyth went looking for the oldest GUI app that still launches on Windows 11, and that was the clean winner at 33 years and 8 months old.

If you allow one helper, the record goes back further. REVERSI.EXE from Windows 1.01, dated 15-Nov-1985, launches on Windows 11 through otvdm. So a 1985 app runs on a 2026 OS. Your accounting tool from 2004 still refuses to start, though, and that's the part worth explaining.

If an old program won't run on Windows 11 and compatibility mode did nothing, start here. Below: why old software fails, a PowerShell one-liner that tells you which kind of failure you have, and the fixes in the order I'd try them: compatibility settings, missing runtimes (VB6, DirectX, .NET 3.5), otvdm for 16-bit apps, DOSBox, and a VM as the last resort.

Why old software won't start on Windows 11

Windows 11 only ships as a 64-bit OS, and 64-bit Windows has never run 16-bit code. Microsoft's own KB is blunt about it: x64 versions of Windows don't support 16-bit programs, 16-bit processes, or 16-bit components. NTVDM, the piece that ran DOS and Win16 apps on 32-bit NT, was never included in 64-bit editions and isn't supported on x64 or ARM at all.

That one rule explains a lot of the "it worked on XP" reports. The other usual causes:

• A 16-bit installer for a 32-bit app. The program would run fine, but the SETUP.EXE that installs it is 16-bit.
• Missing runtimes: VB6 controls, old DirectX DLLs like d3dx9_43.dll, .NET Framework 3.5, old Visual C++ redistributables.
• Admin assumptions: apps that write into C:\Program Files or HKLM because nobody stopped them on Windows 98.
• Display assumptions: 256-colour palettes, fixed 640x480 layouts, no DPI awareness.

The display one sounds cosmetic until it bites. In the Hacker News thread, mattbee describes a Windows 3.1 kids' game that started on Windows 11 but drew a mostly black screen, because its 256-colour palette changes no longer worked. Fixing it took a virtual GDI layer, plus fixes for a 32-bit disk-space overflow and threading bugs that only appeared on multi-core CPUs. So "still launches" is a pretty low bar.

Step zero: check if the EXE is 16-bit, 32-bit or DOS

Don't start ticking boxes in the Compatibility tab until you know whether the EXE is DOS, 16-bit Windows or 32-bit Windows. The executable header tells you. Paste this into PowerShell:

$b   = [IO.File]::ReadAllBytes("C:\old\APP.EXE")
$off = if ($b.Length -ge 0x40) { [BitConverter]::ToInt32($b, 0x3C) } else { 0 }
if ($off -le 0 -or $off -ge $b.Length - 6) { "MZ only: DOS program" }
else {
  $sig = [Text.Encoding]::ASCII.GetString($b, $off, 2)
  if ($sig -eq "PE") { "PE, machine 0x{0:X4}" -f [BitConverter]::ToUInt16($b, $off + 4) }
  else { $sig }
}

How to read the output:

• NE means 16-bit Windows (Windows 1.x to 3.x era). Go to otvdm below.
• PE, machine 0x014C means 32-bit x86. This should run natively, so the problem is a dependency, permissions or the installer.
• PE, machine 0x8664 means 64-bit. Not an age problem.
• MZ only, LE, or two random characters usually means DOS or a DOS extender (plain DOS EXEs often have garbage at offset 0x3C). Go to DOSBox.

Error messages and their usual fixes

Symptom	Likely cause	Fix
"Unsupported 16-Bit Application"	Win16 or DOS binary	otvdm (Win16) or DOSBox (DOS)
Setup fails, the app itself is 32-bit	16-bit InstallShield stub	Microsoft's 16-bit InstallShield Support package
MSCOMCTL.OCX / component not registered	VB6 extended control missing	Copy the OCX and register it with the 32-bit regsvr32
d3dx9_43.dll not found	Legacy DirectX SDK runtime	DirectX End-User Runtimes (June 2010)
Prompt to install .NET Framework 3.5	App targets .NET 1.1 to 3.5	Enable .NET 3.5, or use the standalone installer on 26H1
Crashes saving settings	Writes to protected paths	Run as administrator, or install outside Program Files
Tiny, blurry or clipped UI	No DPI awareness	High DPI override

1. Compatibility mode, and why it usually isn't enough

Right-click the EXE, open Properties > Compatibility. On Windows 11 you get compatibility modes from Windows 95 to Windows 8, plus reduced color mode (8-bit or 16-bit), 640x480, and "Run this program as an administrator". Microsoft's guided version is under Settings > System > Troubleshoot > Other troubleshooters > Program Compatibility Troubleshooter (steps).

This tab is overrated. Picking "Windows XP (Service Pack 3)" helps apps that check the OS version and bail out, and it smooths over some permission problems. It doesn't install a missing DLL, and it can't turn a 16-bit binary into a 32-bit one. Two boxes in it do more real work than the version dropdown:

• Run as administrator, for apps that insist on writing next to their own EXE.
• Change high DPI settings > Override high DPI scaling behavior, then try "System" or "System (Enhanced)" for old UIs that look broken on a 150% scaled laptop.

If the app ran on Windows 7, try the "Windows 7" mode first, then work backwards.

2. Install the runtime it actually needs

In practice a missing dependency is a far more common culprit than a version check.

With VB6 apps, the core runtime (msvbvm60.dll and friends) ships in Windows 11, and Microsoft says it's supported for the lifetime of the OS. The controls are another matter. Files like mscomctl.ocx, comdlg32.ocx and msflxgrd.ocx are "extended files" that each app was supposed to ship itself, and plenty of old installers did that badly. They're 32-bit, so register them from an elevated prompt with the 32-bit regsvr32:

copy MSCOMCTL.OCX C:\Windows\SysWOW64\
C:\Windows\SysWOW64\regsvr32.exe C:\Windows\SysWOW64\MSCOMCTL.OCX

Some controls, like threed32.ocx and graph32.ocx, are on Microsoft's unsupported list. If your app depends on them, you're on your own.

Old games that throw d3dx9_*.dll, XInput 1.3 or XAudio 2.7 errors need Microsoft's DirectX End-User Runtimes (June 2010). It's directx_Jun2010_redist.exe, about 95.6 MB, and it doesn't touch the DirectX version built into Windows. Get it from Microsoft, not from a "dll download" site.

For .NET 1.1 to 3.5 apps, on most Windows 11 builds you can tick ".NET Framework 3.5" in Turn Windows features on or off. That's changing: starting with Windows 11 26H1 (build 28000), .NET 3.5 is only available as a standalone installer and can't be added as a Windows component. It still works, it's just one more step that a 2009 app's installer won't know about.

Last case: the app is 32-bit and only the installer is 16-bit InstallShield, install Microsoft's 16-bit InstallShield Support package first, then run setup again.

3. otvdm (winevdm): run 16-bit Windows apps on 64-bit Windows 11

otvdm is a modified winevdm, the Wine-based 16-bit Windows emulator, ported to 64-bit Windows and licensed under GPL-2.0. It's how REVERSI.EXE from 1985 runs on Windows 11. Setup:

1. Download a release from the GitHub releases page.
2. Right-click install.inf and choose Install (or run the "install" shortcut).
3. Double-click your Win16 EXE as usual. You can also drag it onto otvdm.exe, or launch otvdmw.exe.

If it complains about VCRUNTIME140.dll, install the 32-bit Visual C++ 2017 redistributable. If a Windows update resets the registry hooks, run the install step again. To remove it, run uninstall.reg.

enlyth said using it "does feel like cheating", and that's fair. From the user's side it's the closest thing to the NTVDM that 64-bit Windows never had. The README is clear that its DOS support is incomplete and sends you to DOSBox for DOS programs.

4. DOSBox for DOS programs

DOS apps have needed an emulator on 64-bit Windows since the start. Use DOSBox Staging or DOSBox-X rather than the original DOSBox, which has gone years between releases. Basic use:

mount c C:\dos
c:
cd WP51
wp.exe

5. A VM, last

Microsoft's official workaround for 16-bit software is to dual-boot a 32-bit Windows on a separate disk. Please don't. Put Windows XP or 32-bit Windows 10 in Hyper-V or VirtualBox, give it no network unless it really needs one, and snapshot it. Both are past end of support, so treat the VM like a museum exhibit and keep it off the internet. Microsoft itself recommends turning NTVDM off in enterprise environments for security reasons.

The cutoff is 16-bit code

The 1993 FreeCell result shows how deep Win32 compatibility goes. Anything 32-bit has a decent chance, and anything 16-bit needs a translator. If you maintain one of these apps at work, the order above (check the header, fix the runtime, then emulate) will get most of them running in an afternoon. Leaving one running for another ten years is a separate decision, and probably a worse one.

So what's the oldest program you still run every day, and what did it take to keep it alive? And if you think the VM should be the first step, not the last, I'd like to hear why.

Sources

• enlyth, Oldest GUI application that still runs on Windows 11 and the HN discussion
• Microsoft Learn, 64-bit Windows doesn't support 16-bit programs (KB896458)
• Microsoft Learn, NTVDM and 16-bit app support
• Microsoft Learn, Support statement for Visual Basic 6.0
• Microsoft Learn, Install .NET Framework 3.5
• Microsoft, DirectX End-User Runtimes (June 2010)
• otya128/winevdm on GitHub