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.
Try running a real-mode Windows program on a modern version of Windows.
The hardware may be willing but the software is now incapable.
You only have to copy-paste one .exe file and then you can launch your app from Windows, that’s it. Sounds perfectly reasonable.
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.
16 bit programs dont seem to work at all though - you need wine or dosbox
Imagine if Linux stuck to that same level of interface compatibility. Think of the thousands of man-hours lost to rewriting perfectly good code just chasing the new shiny thing. In an OS built by volunteers we're wasting all developers' time to rebuild their software for the new interface, instead of having on developer spend time to keep the old interface working with the new implementation. And don't try to go "uhm akchyually Linux is the kernel and the kernel is stable", nobody cares. I mean the whole OS, from the kernel to the GUI layer. Is it any surprise that the best tools on Linux are all console programs using the POSIX interface, which has remained stable for the lifetime of the OS? I would go as far as to say that GTK is the Linux Desktop's original sin (followed closely by Qt). Motif and CDE were already established as the Unix GUI API, they should have been reimplemented with an optional separate GTK-native API. Maybe the next generation will learn from our mistakes.
I totally understand, that it cannot work unless money is there, which simply is not, in the Linux desktop world. Compatibility is expensive, hard work and not much fun.
I do not think, this will ever change, in the end, the web/Electron has won, desktop operating systems are less important compared to mobile, so who should invest in a stable GUI platform for Linux?
By now, basically all applications I rely on are CLI programs (posix), web or Electron and a few simple GUI tools (PDF viewer, ...) which can easily replaced.
How is the saying: If you want a portable GUI application for Linux, target Win32 and run it via Wine.
Windows type names have stayed mostly stable since Win32, but some of them are still misleading. DWORD, UINT and ULONG are all 32-bit unsigned integer types. But in C#, "ulong" is a 64-bit type despite having the same name, this leads to making mistakes when transcribing Win32 type names into C# code.
Windows came up with its type names before <stdint.h> existed, so you won't see any uint32_t in there, just DWORD.
It is not enough to simply say you have done something interesting (which is all that this blog post amounts to), we as humans want to know the story of it, it's that that makes it interesting. You can't get that story if you're just vibecoding it, much like how the one person involved in Wolfram Alpha spent a lot of tokens on an LLM that constructed alternative forms of logic, and came away from it thinking that it was worthless, the entire time wasted, because there was absolutely no way for a human to interact with it, those logics had no story or analogies or anything for a human to latch on to.
Giving them the benefit of the doubt though, perhaps they were aiming for brevity.
In other words, different people sometimes want different things...
\
Before Vista, there were two rects, the Window Rect (which included the title bar, menu bar, and the resize border), and the Client Rect, which includes the work area of the window.
Once Vista came around, Window Rects became completely different. After a window becomes shown, the Window Rect expands outwards (around 8 pixels or so) to include a drop shadow and larger resize area. So it's no longer just Window Rect and Client Rect, now there's a third rect called the DWM Extended Frame Bounds, and that corresponds to what the Window Rect used to be on earlier versions of Windows.
To try to make things more compatible, the Window Rect will behave like older versions of windows before the window is shown, and there is no way to access DWM Extended Frame Bounds before a window is shown. But once a window is shown, your Window Rect is bigger now, and in a different location. Programs that try to move the window will instead move it to a location 8 pixels down-right of the target location. Programs that try to resize the window will instead make it 16 pixels too narrow and short. If a program tried to remember the difference between the Client Rect and Window Rect, suddenly that number changed just because the window got shown.
So newer programs need to ask for the DWM Extended Frame Bounds to get an idea of where their window actually is. And it also happens that DWM Extended Frame Bounds are not DPI adjusted, but the Window Rect and Client Rect are. So you need to DPI adjust it into a coordinate system which matches the Window Rect. Now you finally have your three rects, and can properly place a window somewhere on the screen.
An M6 nut from then will fit a bolt made today, and vice versa.
Compatibility over a long time period isn't hard to achieve. Simply don't mess with the standard - don't break what doesn't need fixing.
