iirc, the installer is 16-bit, there's problems with too much disk space and/or too much ram, and then there's cryptic error messages. Oh and the please don't run this on WindowsNT message.
We did find something 3rd party that uses the assets, so all wasn't lost, but ...
Windows has a reputation for amazing back compat, and it's pretty good, but it's not really surprising to find things that don't work. Especially games from that era, there are common issues that come up a lot, but afaik, there's no microsoft compat option to lie about disk space, ram, or vram ... or it doesn't automatically trigger at least.
Crysis Wars, Word '03, the Saboteur are all in a similar boat.
They're not address aware, meaning they overallocate at launch, and Windows handling of 32bit compatibility is dead end code that hasn't been worked on in decades. These are 64bit executables, with 32bit memory mapping inside them.
But yeah, games that do outright crash are pretty easily patchable and most likely already have been.
Try running a real-mode Windows program on a modern version of Windows.
You only have to copy-paste one .exe file and then you can launch your app from Windows, that’s it. Sounds perfectly reasonable.
There is no magic
The hardware may be willing but the software is now incapable.
I don't recall seeing a technical justification, however I suspect it's related to what CPU state transitions are allowed; protected mode (32bit) is allowed to swap to "virtual-8086" mode, which I guess is how real mode applications were run (rather than the processor completely turning off virtual memory, or completely emulating a CPU a la qemu).
IA32e mode (Intel's name for X64) however is not allowed to transition into virtual-8086 mode[0]; it has to drop the processor into 32 bit mode first. That would chop off the top level of page tables, so short of something you do to affect the whole machine, that sounds like a non-starter for running an application.
[0] Intel software developer manual 3, 2.2
Not building NTVDM for 64-bit Windows was a major departure from previous strategy and marks a clear regression in Microsoft's attitudes toward backwards compatibility.
Yeah... but for what purpose should it have been kept? Anyone with a legitimate need to run 16 bit software on a modern Windows machine can always go for virtualization or emulation. The effort required in supporting that technology is far from zero, and old code to work with legacy stuff - no matter in which project - is always a fruitful source of security exploits.
Whether it should have been kept for a technical reason is secondary, in my mind, to eroding the confidence their Customers had that old software would continue to work.
The market doesn't seem to give a damn so I guess they made the right call.
16 bit programs dont seem to work at all though - you need wine or dosbox