ExeBrowser

Why won't my old program run on Windows 11?

By Andrew Nakas · Published August 17, 2026 · ~8 minute read

You double-click something that worked fine for years and get one of a small set of unhelpful outcomes: a dialog saying the app "can't run on your PC", an installer that dies halfway, a window that opens and immediately vanishes, or nothing at all. Windows is famously good at backwards compatibility, which makes it more confusing when a program simply refuses.

There are really only about six reasons, and they fail in distinguishable ways. Once you know which one you have hit, the fix is usually obvious — and in two of the six cases there is no fix on Windows 11 at all, which is worth knowing before you spend an evening on it.

1. It's a 16-bit program, and 64-bit Windows cannot run those at all

This is the big one, and the one people waste the most time on. Anything written for Windows 3.1 — and a surprising amount of software from the mid-90s that was merely sold for Windows 95 — is a 16-bit executable. Running those required a subsystem called NTVDM, and NTVDM only ever existed in 32-bit editions of Windows. Windows 11 ships in 64-bit form only. There is no setting, no compatibility mode and no optional feature that brings it back.

The symptom is specific enough to diagnose from: "This app can't run on your PC. To find a version for your PC, check with the software publisher." If you see that exact message on a program from the early 90s, it is almost certainly 16-bit, and no amount of right-click → Properties → Compatibility will change the answer.

The fix is emulation or translation rather than configuration. A virtual machine running 32-bit Windows works; so does a browser-based Wine build configured for the 16-bit era, which is how the Windows 3.x-era titles on this site run — JezzBall, Chip's Challenge and Rodent's Revenge all need that path. There's a longer write-up in running 16-bit Windows 3.x software in 2026.

2. It's actually a DOS program, and you've been misreading the box

Plenty of software from 1990–1995 shipped in a Windows-branded box while being a DOS program that Windows merely launched for you. A DOS executable never calls the Windows API at all, so modern Windows has nothing to run it with — and neither does Wine, which is worth saying because people often try Wine first and conclude their file is corrupt.

DOS software needs a DOS emulator, and the answer is DOSBox, which is what nearly every re-release of a classic PC game on Steam or GOG is quietly using. We hit this distinction constantly: Prince of Persia and Jazz Jackrabbit are DOS originals, and the only way to play them in a browser is a source port or a DOS emulator, not a Windows compatibility layer.

3. The installer is broken, not the program

Very often the software itself is fine and the setup program is what fails — because installers do unusual things: writing to protected registry hives, registering drivers, invoking MSI custom actions, checking for an OS version that stopped existing. An installer that dies with a cryptic MSI error number tells you nothing about whether the application would have run.

The move is to skip the installer entirely and unpack it. Most legacy installers are just archives with a wrapper, and general-purpose extractors will open them: 7-Zip handles a lot of self-extracting EXEs directly, innoextract handles Inno Setup, cabextract handles CAB-based ones, and an MSI can be unpacked with msiexec /a. We wrote a full walkthrough in how to extract files from an old installer. Once unpacked, a great many old apps are portable — small utilities in particular tend to be a single EXE with no registry dependencies at all.

4. It needs a runtime nobody has installed any more

An awful lot of 2000s Windows software isn't self-contained. It expects a runtime to already be on the machine, and the ones it expects are no longer there by default:

• .NET Framework 3.5. Not installed by default on Windows 11. It's still available as an optional Windows feature, which is the easiest fix on this whole page — but if the runtime is missing, the app typically dies at launch with no useful message. Paint.NET's classic builds are the canonical example; in our own testing they will not start without it.
• Visual Basic 6 runtime. An enormous amount of small business and shareware software from 1998–2004 is VB6, and needs MSVBVM60.DLL and friends.
• Visual C++ redistributables. The classic MSVCR71.DLL not found error. Each compiler version had its own redistributable and none of them are guaranteed present.

The tell here is a missing-DLL dialog naming a specific file. That is good news, because a named DLL is a searchable, fixable problem.

5. Its copy protection was retired by Microsoft

This one surprises people, because the program is fine and the protection scheme is what's broken. Several 2000s disc-based protection systems worked by installing a kernel driver, and those drivers were security liabilities. Microsoft stopped supporting the SafeDisc driver in Windows 10 and it does not run on Windows 11; several SecuROM-era schemes are in the same position.

So a legitimately purchased game, with its original disc, refuses to start — not because of the game but because a component Microsoft deliberately removed is missing. Where the publisher has since released a patched or DRM-free version, that is the fix. Where they haven't, a virtual machine running an older Windows is the realistic option, and it's one reason the DRM-free re-releases on GOG exist at all.

6. It draws with a graphics API that no longer really exists

Old software often talks to the display through interfaces that modern Windows only pretends to still support. DirectDraw and early Direct3D are emulated on top of modern drivers rather than run directly, and old OpenGL paths are patchy depending on your GPU vendor. The results are recognisable: wrong colours, a palette that inverts when you alt-tab, a window that renders black, or a game that runs at an absurd speed because it assumed a slower machine.

This category is also the one that resists browser-based approaches most stubbornly. In our own compatibility testing the graphics-heavy applications were consistently the failures — Blender's classic builds need a real OpenGL context and don't get one, and VLC loads its interface but can't get video output working. Text and 2D software, by contrast, is the most reliable category there is.

So what should you actually try, in order?

Cheapest first:

What we found testing this at scale

We ran more than fifty classic Windows programs through a browser-based Wine build and published every result, including the failures. The pattern that came out of it matches the six causes above almost exactly, and it is more predictable than "old software is a lottery" suggests.

Small 32-bit utilities from roughly 1995–2008 are the sweet spot and mostly just work — 7-Zip, Calculator, AbiWord, Gnumeric. The reliable failures are the ones with a structural reason: 64-bit-only builds like KeePassXC, .NET dependencies, heavy GTK or Qt frameworks like Inkscape, and anything needing real 3D or network access. Age turns out to be a poor predictor. What the program asks the operating system for is the whole story.

If you want the short version of which categories survive, the compatibility guide covers it, and the per-application guides record what actually happened when we tried each one — including the ones that didn't work, which are usually the more useful pages.

Keep reading

• Running 16-bit Windows 3.x software in 2026The subsystem 64-bit Windows removed, and the ways around it.
• Extract files from an old installerWhen setup.exe is the only thing that's broken.
• Run old software without a VMWhen a browser tab is enough.