This article has the bones of something interesting, but the style is too barren and the content really needs to be fleshed out more. I feel like if a human had written it, they would have thought of more to write. Like a human wouldn't be content with two paragraph section about K&R C without actually writing about difficulties encountered with this, parts that were interesting to implement and parts that weren't, et cetera. A human would look at that and go "ok but, what is the point to this, what makes this interesting?"
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.
I agree, another example is the line ‘lots of things had to be done by hand’. I think a more human narrative would be describing the discovery that thing X that we take for granted was missing and tell the story of figuring it out.
Giving them the benefit of the doubt though, perhaps they were aiming for brevity.
I respect your tastes but, as a human, I like the objectivity in the article. I actually couldn't care less about the backstory and I tend to skip articles that wander around without getting to the point. I prefer to read a book when I want that.
In other words, different people sometimes want different things...
Ok, but brevity is the soul of wit. That's part of my point, this is a long form article with no content. If a human had written it, it would simply have been two to four paragraphs instead! "I made a thing, and it was cool the api stayed the same" rather than this really long winded article saying nothing at all.
While I haven't daily driven Windows in years and am usually the first to criticize Microsoft. You have to give credit where credit is due; Windows backwards compatibility is simply nuts. I had never run into compatibility issues with programs or games built for older Windows version, nor have I heard of anyone who did.
To be fair, that is not a backwards compatibility problem and is because the games were designed with an unnecessary reliance on a third party service to run.
I'd like to know which ones you've had issues with. I've compiled a collection of hundreds of Windows games from ~96-2006 and I've only run into one that's required an appcompat flag (carmageddon 2).
My dad had trouble getting the Panzer General / other General Series to run.
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.
Dark Messiah of Might and Magic, and a lot of other early Source games will just outright crash.
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.
Intel backwards compatibility has meant that real mode is still with us more of less, but to give context to people who aren't as familiar: real mode was superseded by protected mode with the introduction of the 80286, in 1982.
Yes, as sibling noted, 64bit Windows dropped support for running 16bit applications (which require real mode).
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.
Yes, that was removed with the 64-bit versions of Windows. My understanding is because they were using a compatibility layer to run 16-bit apps, and with 64-bit Windows they changed that compatibility layer to run 32-bit apps. But I'm not a Windows internals expert so I could be mistaken.
That link says NTVDM uses the CPUs virtual-8086 mode, rather than emulating a CPU; NTVDM's approach can't be done on a CPU that's in 64bit mode (per Intel's docs), the CPU would have to be stepped back into protected mode first (which isn't the same as when you run a 32bit application in a 64bit OS, that's a separate compatibility state within 64bit mode).
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.
> 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.
My observation is the "old Microsoft" would have kept it in and supported it because that's how they rolled. The lack of NTVDM in x64 Windows signaled a change that the commitment to compatibility is now on shaky ground.
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.
I've been using otvdm (aka winevdm) and it is very good. It works like the original ntvdm did when running on non-x86 platforms. It emulates the processor and translates 16-bit api calls into 32-bit api calls so things work as you'd expect.
It might be stable, but when Vista came around, there was a huge change to how Window Rects worked. Something so basic got a big breaking change.
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.
To be fair, the C standard for types is pretty dreadful. How big is an int? A long? Want an integer type that matches the size of a pointer? <stdint.h> did fix a lot of the issues, but people targeting an early C version don't have this header available.
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's not (reasonably) possible to do so though, because it would break so, so much legacy code. The only thing you can do is to add new functionality (e.g. the difference between A and W APIs - A is ASCII, W is UTF-16) or to shoehorn crap onto existing interfaces (again, A APIs to which you pass UTF-8 and pray for the best), but you cannot delete any publicly exposed API or modify existing types.
> That was probably the most surprising part of the entire experiment: internally, Windows has changed enormously over the decades, yet the application interface has stayed so stable that code written in the mid-1980s still looks completely familiar.
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.
Who exactly in the Linux world is supposed to get paid wonderfully to keep mountains of old cruft and technical debt in working order? Not to say I'm insensitive to your point, but when whole UI frameworks are amateurs' passion-projects, the practical burden of maintenance has very real implications. That's essentially the whole story behind the Linux desktop losing Xorg.
In the end, it's always the old problem, how to properly fund open source projects.
Maybe with the current political events and subsequent changes in priorities we'll see EU governments ponying up some money under "digital sovereignty" programs - but given the rabid opposition to systemd (funded by RedHat), I fear that any attempt by the EU to get some order into the chaos will be met with just the same toxicity.
> Maybe with the current political events and subsequent changes in priorities we'll see EU governments ponying up some money
Those wheels are already spinning at a fast pace, the French government has its own NixOS-based distro for public servants¹, teams-up with the German and Dutch governments to develop a productivity suite as to not rely on MSOffice², NLNet sponsors many "infrastructure-level" initiatives though NGI Zero³ (many in the area of networking, computer design, federated/P2P communication protocols, …)
The key question is, who will call the shots? That's the most pressing problem with many open-source projects without commercial backers - they completely lack focus, unless there is either some sort of BDFL providing the guardrails (be it Linus Torvalds, Guido van Rossum, Daniel Stenberg, Fabrice Bellard or the other usual suspects), or someone backed by serious financial firepower uses said influence (i.e. Lennart Poettering of systemd).
Particularly something like an office / productivity suite is ripe for conflicts. One group of users (i.e. stingy governments) want something that can run on computers that would be more fitting in a museum. Other groups want pixel-perfect compatibility with Microsoft products, even if it results in a ton of extra work. Others don't want LDAP support for the email client's address book, but instead other stuff like an integration into Okta or whatever other SaaS. And either someone will get empowered to make such decisions by everyone involved... or it will be a lot of money wasted or a lot of chaos.
Thanks, we (Linux/BSD) users cannot bring up this topic often enough.
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.
OSS is essentially more chaotic as everyone as his/her own ideas. It’s not too different in a corporation but when someone is in control it’s easier to centralize things.
This article has the bones of something interesting, but the style is too barren and the content really needs to be fleshed out more. I feel like if a human had written it, they would have thought of more to write. Like a human wouldn't be content with two paragraph section about K&R C without actually writing about difficulties encountered with this, parts that were interesting to implement and parts that weren't, et cetera. A human would look at that and go "ok but, what is the point to this, what makes this interesting?"
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.
I agree, another example is the line ‘lots of things had to be done by hand’. I think a more human narrative would be describing the discovery that thing X that we take for granted was missing and tell the story of figuring it out.
Giving them the benefit of the doubt though, perhaps they were aiming for brevity.
I respect your tastes but, as a human, I like the objectivity in the article. I actually couldn't care less about the backstory and I tend to skip articles that wander around without getting to the point. I prefer to read a book when I want that.
In other words, different people sometimes want different things...
Ok, but brevity is the soul of wit. That's part of my point, this is a long form article with no content. If a human had written it, it would simply have been two to four paragraphs instead! "I made a thing, and it was cool the api stayed the same" rather than this really long winded article saying nothing at all.
While I haven't daily driven Windows in years and am usually the first to criticize Microsoft. You have to give credit where credit is due; Windows backwards compatibility is simply nuts. I had never run into compatibility issues with programs or games built for older Windows version, nor have I heard of anyone who did.
Some games that ran on Vista, can run under Wine, but not on Windows 11. The backwards compatibility story has changed in the last few years.
Games for Windows, can’t play any of those anymore without cracking them since the severs got turned off.
To be fair, that is not a backwards compatibility problem and is because the games were designed with an unnecessary reliance on a third party service to run.
I'd like to know which ones you've had issues with. I've compiled a collection of hundreds of Windows games from ~96-2006 and I've only run into one that's required an appcompat flag (carmageddon 2).
My dad had trouble getting the Panzer General / other General Series to run.
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.
Dark Messiah of Might and Magic, and a lot of other early Source games will just outright crash.
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.
Heroes of Might and Magic 3
> I had never run into compatibility issues with programs or games built for older Windows version
Try running a real-mode Windows program on a modern version of Windows.
Intel backwards compatibility has meant that real mode is still with us more of less, but to give context to people who aren't as familiar: real mode was superseded by protected mode with the introduction of the 80286, in 1982.
I believe Microsoft removed support for 16bit Windows applications some time ago.
The hardware may be willing but the software is now incapable.
Yes, as sibling noted, 64bit Windows dropped support for running 16bit applications (which require real mode).
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
Yes, that was removed with the 64-bit versions of Windows. My understanding is because they were using a compatibility layer to run 16-bit apps, and with 64-bit Windows they changed that compatibility layer to run 32-bit apps. But I'm not a Windows internals expert so I could be mistaken.
You just need to install 86Box as a compatibility layer. Everything runs perfectly.
You only have to copy-paste one .exe file and then you can launch your app from Windows, that’s it. Sounds perfectly reasonable.
86box is a PC emulator, not a compatibility layer.
The official compatibility layer of Microsoft works the same way as 86box: https://betawiki.net/wiki/NTVDM
There is no magic
That link says NTVDM uses the CPUs virtual-8086 mode, rather than emulating a CPU; NTVDM's approach can't be done on a CPU that's in 64bit mode (per Intel's docs), the CPU would have to be stepped back into protected mode first (which isn't the same as when you run a 32bit application in a 64bit OS, that's a separate compatibility state within 64bit mode).
For sure.
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.
> 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.
My observation is the "old Microsoft" would have kept it in and supported it because that's how they rolled. The lack of NTVDM in x64 Windows signaled a change that the commitment to compatibility is now on shaky ground.
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.
A ton of things broke for me when they restricted writing to the program files directory with XP.
Lots of old games dont work anymore, but you can still run them by compabtibility modes.
16 bit programs dont seem to work at all though - you need wine or dosbox
16-bit windows applications aren't supported natively by 64-bit windows, but OTVDM (based on Wine code) will run most of them fine.
I've been using otvdm (aka winevdm) and it is very good. It works like the original ntvdm did when running on non-x86 platforms. It emulates the processor and translates 16-bit api calls into 32-bit api calls so things work as you'd expect.
https://github.com/otya128/winevdm
winevdm allows me to run all 3.11 apps on windows :) Its amazing - works even for 32bit era.
The game is known as Qix, Xonix (title of a clone) is not a common name for the game.
Yet whenever I take a look at some random React/mobile project it is impossible to build after upgrade.
The M6 Bolt has been around since it was first standardized in 1898.
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.
Just fwiw, it built and ran ok on windows 10, with tcc. 64 bit exe...
Excellent article. The stability of the Win32 API is a gold standard.
\
It might be stable, but when Vista came around, there was a huge change to how Window Rects worked. Something so basic got a big breaking change.
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.
So em dash.
Winapi has exploded the last years in terms of functionality, still it was never sanitized to follow any C standard in terms of types.
To be fair, the C standard for types is pretty dreadful. How big is an int? A long? Want an integer type that matches the size of a pointer? <stdint.h> did fix a lot of the issues, but people targeting an early C version don't have this header available.
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 make sense.
Use Windows Implementation Library to clean things up and get some RAII on handle types: https://github.com/microsoft/wil
It's not (reasonably) possible to do so though, because it would break so, so much legacy code. The only thing you can do is to add new functionality (e.g. the difference between A and W APIs - A is ASCII, W is UTF-16) or to shoehorn crap onto existing interfaces (again, A APIs to which you pass UTF-8 and pray for the best), but you cannot delete any publicly exposed API or modify existing types.
> That was probably the most surprising part of the entire experiment: internally, Windows has changed enormously over the decades, yet the application interface has stayed so stable that code written in the mid-1980s still looks completely familiar.
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.
Who exactly in the Linux world is supposed to get paid wonderfully to keep mountains of old cruft and technical debt in working order? Not to say I'm insensitive to your point, but when whole UI frameworks are amateurs' passion-projects, the practical burden of maintenance has very real implications. That's essentially the whole story behind the Linux desktop losing Xorg.
In the end, it's always the old problem, how to properly fund open source projects.
Maybe with the current political events and subsequent changes in priorities we'll see EU governments ponying up some money under "digital sovereignty" programs - but given the rabid opposition to systemd (funded by RedHat), I fear that any attempt by the EU to get some order into the chaos will be met with just the same toxicity.
> Maybe with the current political events and subsequent changes in priorities we'll see EU governments ponying up some money
Those wheels are already spinning at a fast pace, the French government has its own NixOS-based distro for public servants¹, teams-up with the German and Dutch governments to develop a productivity suite as to not rely on MSOffice², NLNet sponsors many "infrastructure-level" initiatives though NGI Zero³ (many in the area of networking, computer design, federated/P2P communication protocols, …)
¹: https://github.com/rlahfa-dinum/securix ²: https://www.opendesk.eu/en ; https://lasuite.numerique.gouv.fr/ ³: https://nlnet.nl/project/
Money is one thing, it's desperately needed.
The key question is, who will call the shots? That's the most pressing problem with many open-source projects without commercial backers - they completely lack focus, unless there is either some sort of BDFL providing the guardrails (be it Linus Torvalds, Guido van Rossum, Daniel Stenberg, Fabrice Bellard or the other usual suspects), or someone backed by serious financial firepower uses said influence (i.e. Lennart Poettering of systemd).
Particularly something like an office / productivity suite is ripe for conflicts. One group of users (i.e. stingy governments) want something that can run on computers that would be more fitting in a museum. Other groups want pixel-perfect compatibility with Microsoft products, even if it results in a ton of extra work. Others don't want LDAP support for the email client's address book, but instead other stuff like an integration into Okta or whatever other SaaS. And either someone will get empowered to make such decisions by everyone involved... or it will be a lot of money wasted or a lot of chaos.
Thanks, we (Linux/BSD) users cannot bring up this topic often enough.
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.
OSS is essentially more chaotic as everyone as his/her own ideas. It’s not too different in a corporation but when someone is in control it’s easier to centralize things.
Ah but what about (dun dun dun) “innovation”