p.enthalabs

16-bit Windows (Windows 1.x, 2.x, 3.0, 3.1, etc.) on 64-bit Windows

128 points · 9 visible top comments · 2026-10-27 01:15:04 UTC

github.com · Read Story HN original

Comments

orionblastar · 2026-10-27 01:22:09 UTC
Finally, 16-bit Windows support for 64-bit Windows.
bitwize · 2026-10-27 02:58:47 UTC
Winevdm has been out a while.
yako21000 · 2026-10-27 04:34:00 UTC
Oh my good, windows 3.1x.... good old times and a word application that never crashed!
tonyedgecombe · 2026-10-27 07:10:35 UTC
>a word application that never crashed!

You must have lived in a different reality to me.

yako21000 · 2026-10-27 08:45:25 UTC
Haha, well at least for what I used Word at this time, it didn't crash on windows 3.1x. But I was pretty young then, so I didn't do much with it.
gschizas · 2026-10-27 09:18:56 UTC
Windows 3.x crashed all the time. And when it didn't crash, some resource memory or whatever filled constantly. When I installed Windows 95 (which wasn't perfect, far from it), a friend of mine asked me "so, how often do you reboot", and until that time I hadn't really realized that I "rebooted" Windows 3.11 a few times per day because the memory just filled up and I really had to.

I had at the time some software that run constantly on Windows 3.x (that I don't remember the name of (L-something), but I'm sure I got it from some magazine, since I didn't get Internet at home before 1996) just to monitor memory (and it was also a good task manager/launcher). I stopped using that with Windows 95.

yako21000 · 2026-10-27 09:54:23 UTC
Oh that's kinda interessting. Well it was my fathers laptop that used it only for his classes (was a french teacher). So basically he only used Word and sometimes played minesweeper and I often wrote also texts with it. But nothing advanced. So we never run into memory issues, but god, did we have a lot of floppy disks!
gabmartini · 2026-10-27 05:34:32 UTC
Nice, I will be able to play Civ2 on Windows 11!

In related news, with the latest WINE on Linux 16 bits/32 bits applications are supported, so I was able to run my beloved Civilization 2 without problems.

krige · 2026-10-27 05:45:48 UTC
Civ2 - well, at least its Test of Time incarnation - has specific patches to keep it running without external tools.
haunter · 2026-10-27 06:59:45 UTC
Installed MS Office 2.0 some months ago with it just for fun. It actually works pretty well apart from the dictionary files, for some reason those are not recognized

https://files.catbox.moe/dy4bqy.png

I’ve used it for a week just I was curious:

1, is it good enough for modern day to day word processing (mostly emails)? Yes it is

2, can the modern word processors (Office 365, LibreOffice, Google Docs) recognize and open the files created with it? (doc, rtf anything but plain text) Yes they can

pjmlp · 2026-10-27 07:49:58 UTC
For work, not due to other requirements, however for personal documents I fully agree with your first point, MS Office 2.0 is good enough to type in some snail letters, school reports or CVs.
haunter · 2026-10-27 07:53:14 UTC
Also there is security. I think, I just guess, these old 16bit file formats are all exploitable to some extent
pjmlp · 2026-10-27 08:01:13 UTC
Yes, however if you are only using them privately as a modern typewriter for stuff that is anyway going to be sent on paper, there is less of a concern.

Now sharing files with others is another matter, and I fully agree.

londons_explore · 2026-10-27 08:11:04 UTC
Doubt you'd be storing important ssh keys on the same VM
pjmlp · 2026-10-27 08:14:47 UTC
You would be surprised on how some offshoring projects go, which anyway has zero to do with what I was talking about.
ale42 · 2026-10-27 11:29:43 UTC
It's not a VM, as far as I understand. Possibly OTVDM.
spider-mario · 2026-10-27 08:14:25 UTC
And a refreshingly straightforward UI compared to modern behemoths.
ant6n · 2026-10-27 10:10:50 UTC
The crazy thing is, if you have 10 office windows open on a MacBook with 16GB, it brings the system absolutely to its knees.

But the functionally most use would be mostly there with office 95 at the latest (except for syncing).

Why does software nowadays use 1000x the resources of software 25 years ago, but only provides minimally more useful features.

londons_explore · 2026-10-27 08:09:30 UTC
I really don't understand why Microsoft didn't build this when they released 64 bit windows.

16 bit windows wasn't complicated, and a simple VM and API translation layer could have kept compatibility going back 30+ years for not many engineering hours.

Yet instead they dropped 16 bit windows support and probably spent more engineering hours to support all the ancient software trying to update, and users who held back upgrading windows because they needed said ancient software, etc

my123 · 2026-10-27 08:26:03 UTC
being able to transfer HANDLEs across the 16/32-bit boundary notably for COM/OLE integration becomes a lot more painful

Microsoft says at https://learn.microsoft.com/en-us/windows/win32/winprog64/ru...:

> Note that 64-bit Windows does not support running 16-bit Windows-based applications. The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data. Attempts to launch 16-bit applications fail with the following error: ERROR_BAD_EXE_FORMAT.

winevdm on Windows eschews that level of integration, but perhaps MS should have shipped WoW16 with limitations instead of nothing.

vintagedave · 2026-10-27 12:01:15 UTC
Naive question from someone who's never written this sort of compatibility layer: couldn't a VDM map handles? They are opaque values. Change the value, basically, keep a 16-bit table mapping to the host OS's 32/64-bit real handles?

Edit: the readme has something very similar:

    wine based Win16->Win32 conversion codes:
    BOOL16 WINAPI DestroyWindow16( HWND16 hwnd )
    {
        return DestroyWindow( WIN_Handle32(hwnd) );
    }
I would guess that's what the WIN_Handle32 method/macro is doing.
lupical · 2026-10-27 08:36:52 UTC
On the other hand, I'd argue companies using 16-bit applications would be unwilling to upgrade to a 64-bit installation anyway. Microsoft decided it was better to push software developers to upgrade to Win32, given that 32-bit Windows already existed since 95.
da_chicken · 2026-10-27 09:22:21 UTC
Sure, but the 16-bit program that was still being used the most had to be setup.exe or install.exe. For many years it was common to distribute all software packages with a 16-bit installer because it's (slightly) smaller and it's never doing anything that would require 32-bit processing.

So, now, it's not unusual to find software from as late as 2005 that is actually 32-bit software, but it's in a 16-bit installer.

Indeed, it might be the only 16-bit application I've wanted to run other than Castle of the Winds and Scorched Earth.

mike_hearn · 2026-10-27 08:41:29 UTC
By the time 64 bit Windows comes around the only stuff still running 16 bit is on machines that will never be updated. Embedded boxes in industrial machinery that is itself no longer supported, that sort of thing. No point making it work if nobody will ever update to it.
mshish · 2026-10-27 14:55:19 UTC
Yeah and I would think wanting developers to update to 32/64 bit was also part of the equation.
xacky · 2026-10-27 10:53:12 UTC
Backwards compatibility has limits. When a piece of software has been abandoned for 30 years, there is very little commercial value in supporting it. Apple, Google and even Linux are more aggressive in dropping support. It's only IBM on mainframes with multi million contracts that is really going for backwards compatibility at any cost.
hypercube33 · 2026-10-27 14:46:03 UTC
They already had 32bit Win32 Windows on Windows (WoW) subsystems on all machines, even ARM64 to a point - the only thing I've seen that it didnt run out of the box was OpenGL which they have a (??!) Store app for Maya3d or something that does OpenGL to DirectX translation - and that seemed to work OK. The biggest issues I had with Windows on ARM64 was the lack of cooling.

Back on track - the 16 bit DOS and Windows stack is a lot different than Win32 - totally different windowing, drawing to the screen, and memory management is involved - it was probably pulled for security reasons and the most common one at Microsoft - "the guy who maintained this left or retired"

mschuster91 · 2026-10-27 10:40:43 UTC
For a moment I was scared about yet another AI slop "recomp" or qemu or whatever hack, but this is actually legit and dates back years before slop was even a thing.

Nice work.

tcsenpai · 2026-10-27 11:19:31 UTC
You can fit exactly four 16 bit Windows on 64-bit Windows
1970-01-01 · 2026-10-27 13:33:37 UTC
I understand the point is to be native but you can also just run them inside a very lightweight VM.
Grimeton · 2026-10-27 17:33:14 UTC
The 16bit support was removed with windows 2008. It wasn't just the "DOS" support (NTVDM). They also removed the last OS/2 and SFU layer with 2k8 iirc.