Oldest GUI application that still runs on Windows 11
- ID
- 39802
- Status
- summarized
- Published
- 27 Oct 2026, 1:56 AM
- Fetched
- 27 Oct 2026, 9:07 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://blog.enlyth.com/posts/oldest-windows-gui-app-win-11/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 4.5
- Created
- 27 Oct 2026, 9:08 AM
- Tags
- Audience
- developers
What happened
The author set out to find the oldest GUI application that still runs unmodified on Windows 11, first landing on FREECELL.EXE dated 22-Feb-93 via Win32s, then digging through early NT 3.1 pre-releases on the Internet Archive to find CDPLAYER.EXE from Build 347, linked 16-Nov-1992 — roughly 34 years old and playable once a small cdemu.dll fakes a CD-ROM drive with dummy audio. Earlier 1991-era builds fail because they use a draft PE format, and builds up to mid-1992 use cdecl instead of stdcall for Win32 calls, so arguments get popped twice and the program crashes. CDPLAYER.EXE survives because it links against the system crtdll.dll, which Windows 11 still ships in SysWOW64; 16-bit apps are out of scope on 64-bit Windows (no NTVDM) unless you use something like otvdm.
Why it matters
This is a curiosity, not a decision you need to make this week — but the concrete mechanism is worth noting: a 1992 binary still runs because Windows kept both the stdcall ABI and crtdll.dll in SysWOW64 for three decades, while sibling binaries from the same build crash purely on a calling-convention change. If you ship long-lived binaries, native plugins, or a plugin ABI, that is the actual durability variable — not your source code.
Discussion angle
Windows carries crtdll.dll and the stdcall ABI for 30+ years so a 1992 CD player still launches — what is the equivalent cost/benefit for your own stack, and where have you chosen to break compatibility instead?