According to Raymond Chen, this usually happens when software relies on undocumented APIs or undefined behavior. When Windows removes undocumented APIs or changes behavior not covered by the documentation, such apps break and people blame Microsoft. For example, I remember one app used to programmatically find some kind of "Print" menu in Windows' desktop environment and call it to implement printing functionality. When Microsoft changed the UI of the desktop (shuffled the menu items around) the app broke and people immediately blamed Microsoft, even though the app is to blame because the exact location of the menu item was never supposed to be a public contract. If an app is a widely used one, Microsoft usually used to create "shims" which detected funky behavior like that and corrected it to make the app work again. I think they don't do it anymore after Windows 8, that's why apps started breaking more frequently.
If your plan is to maintain decades of backwards compatibility with software from thousands of third parties, it's going to involve maintaining some originally-undocumented behaviors that people exploited. That's what the wine developers got themselves into willingly, and it's what the Windows devs are increasingly shirking.
It's a question of priorities. Microsoft must have realised these edge cases were slowing development down and how many people really want to run a game or a CD burner software from 1998?
Of course, this could all have been avoided with a proper universally understood spec like POSIX but it's too late for that now. (And POSIX never had graphics or sound support, which shows how big that project would be, with the churn of the PC hardware from 2D to 3D &etc)
The hardware is also starting to protest - no way to run 16 bit instructions in x86_64 mode on a 64 bit processor.
You can run 16 bit code in long mode just fine. It's just a different GDT entry like 32 bit code is. Windows didn't cut 16 but mode because of the processor ut because they took the opportunity to increase the max HANDLE table size greater than 16 bit code can address.
Just want to point out that not all 16-bit code can run unhindered in long mode. You can run 16-bit protected mode code. But long mode dropped the V8086 mode that made easily emulating 16-bit real mode possible.
But you can switch in and out of long mode, so it is also possible to basically do whatever you want. And you also have hardware virtualization. It is a political decision to drop compatibility for 16 bit Windows and DOS (i.e. it was too much programming effort), don't blame the hardware.
I think this is the price they are(were?) willing to take. If they don't take backward compatibility seriously. Windows won't exist now at first place.
> According to Raymond Chen, this usually happens when software relies on undocumented APIs or undefined behavior.
This may have been the case, but it no longer is. DirectDraw and other _official_ APIs have been removed from Windows, providing no official replacement (other than the ones coming from Wine itself!), and leaving hundreds of programs in the dust.
DirectDraw has been deprecated for a long time, but it's still there, and it still works. I regularly run games using it on Win11, e.g. https://triumph.net/ageofwonders (1999)
Most old games do not work because of old graphics apis. Wine emulates these apis on top of modern graphic apis. Windows users usually need to use wrappers, or wined3d from wine.
Thanks a lot, but d3d8 and d3d9 seemingly have no effect, while ddraw fails with "The procedure entry point DDKMTOpenAdapterFromLuid could not be located in the dynamic link library gdi32.dll.", then game's mandatory launcher does open, but then an access violation when trying to launch the game itself from it...
However, I sympathize with the general funkiness of running old games. It's very difficult to play the original Diablo 2 through Wine unless you emulate a virtual desktop, which is frustrating to set up. If you're willing to give it another try, the Lutris script should handle almost everything needed to configure it right: https://lutris.net/games/command-conquer-red-alert-2/
>A lot of games, Red Alert 2 off the top of my head. Never got it running even in compatibility mode and changing the bit depth.
Mate, I played Red Alert 2 off the original 1999(?) ISO last month on my Windows 11 installation. I had to copy some missing deprecated Direct Draw DLLs that don't ship with modern Windows anymore and everything worked.
If you would have Googled the issue, you would have found tons of forum and reddit posts explaining how to run it on modern Windows.
You can't expect modern Windows to ship 20+ year old DLLs that allow running Windows 98 APIs as that's a major security vulnerability since older APIs had direct hardware/memory access without any kind of checks and balances. But if you Google a bit, the workarounds for compatibility are available.
Also, a lot of games and apps in those days would basically "hack" Windows and hook into various process and drivers in non standard ways and use various undocumented APIs so it's no wonder they don't work in later versions of windows anymore regardless of the compatibility setting you use.
You just can't claim that Windows has "backwards compatibility" if you have to "Google" for it. In a recent article about Linux backwards compatibility, I pointed out that OSS support was terrible, which meant that many games would no longer run out of the box even if statically linked (actually, static linking made the problem harder). It doesn't matter that lack of OSS is a trivially fixable problem (much easier that having to fish for libraries), it still means Linux is _not_ backwards compatible.
> I had to copy some missing deprecated Direct Draw DLLs that don't ship with modern Windows anymore and everything worked.
You literally had to copy the ddraw DLL from the Wine project, thereby solidly proving the OP's point: Wine has these days better compatibility than Windows.
> You can't expect modern Windows to ship 20+ year old DLLs
One can excuse it however one sees fit but this shows that Windows has lost the backwards compatibility edge that it may once had.
>You just can't claim that Windows has "backwards compatibility" if you have to "Google" for it. [...] One can excuse it however one sees fit but this shows that Windows has lost the backwards compatibility edge that it may once had.
I completely disagree with your line of thinking. If modern Windows would have shipped with all possible legacy DLLs, ancient visual C++ libraries and DirectX versions needed for running every possible 20+ year old piece of software, then everyone would claim windows is unnecessary bloated. Would you even want such bloat by default on all installations just for the handful of users who need to run 20+ year old software?
The current situation is a good compromise between compatibility and bloat.
Windows 11 can run 20+ year old software natively without virtualization but it's up to you to separately download the deprecated legacy DLLs that your 20+ year software requires. Also, looking at it relative to competition from Apple, it's incomparably better at backwards compatibility than MacOS. And Xbox is also better at emulating the 360 era games on the modern systems than Sony is at emulating the PS3.
> The current situation is a good compromise between compatibility and bloat.
By this logic, any operating system has perfect backwards compatibility, since you just have to fix whatever's broken ... even when the compatibility shims come from 3rd parties! Linux has perfect backwards compatibility, you just have to download this patched Gtk+ binary from this guy, etc.
Whatever the excuse is, they have dropped their backwards compatibility story. It was part of their official, published ABI, and now it isn't. All the excuses are as bogus as they are on any operating system. Apple also claims they drop backwards compatibility to avoid "bloat", but it is just that, an excuse.
And "bloat" is quite a bogus excuse, too, since it could for example offer to auto-download the required components like it does for previous .NET framework releases. Or even put an updated version on their download site (e.g. as with winhelp). Or just made it a Windows-independent redistributable (e.g. CRTs). One could have an argument if this was the case. (Apple did auto-downloads at some point). Yet here they just didn't care and 3rd parties like Wine had to come in fill the holes.
Not to mention this is not what people have in mind when they think "bloat"; after all, Wine manages to provide all these APIs and sizes at significantly less than a barebones Windows installation.
>By this logic, any operating system has perfect backwards compatibility, since you just have to fix whatever's broken
The issue with your logic is you only see things as black or white while, while backwards compatibility is various shades of gray, depending on factors that are mostly beyond Microsoft's control.
Modern Windows cannot account for all possible APIs, DLLs and hacks/workarounds that were used by every developer 20+ years ago, including non standard libraries and APIs, so of course you might need to download some missing DDLs regardless. Even if you use Wine, you could still have to do that to run Red Alert 2 or other such apps. That doesn't mean backwards compatibility does not exist, it means it's not a guaranteed 100% success rate out of the box, depending mostly on what libraries, APIs and hacks the original app developer employed.
And the excuses are not bullshit, but are a matter of money and return on investment and ratio of bloat plus freedom the app developers took at the time which isn't available on Modern windows for security reasons (Windows till and including XP was unsecure as f*ck, I don't think you want to have all those functions the developers of the time exploited, for better or worse, exposed in your modern installation of Windows just for 100% backwards compatibility).
Microsoft can't be expected to ship every single outdated and insecure 20+ year old DLL and undocumented API with every copy of Windows, which is a non issue as the last fifteen F-500 cooperate sys-admins in the world who still need to run 20+ year old corporate apps on modern windows will definitely have the knowhow to copy some DLLs they trust to C:/System32 so their crusty corporates app will work. It's not too hard, to copy some files, is it?
The 32 bit C++ executables I wrote in highschool for windows 95, still run right now on Windows 11 out of the box without any patches or issues. So backswords compatibility exists on windows live and well against your opinion that it doesn't. End of story.
> Modern Windows cannot account for all possible APIs, DLLs and hacks/workarounds that were used by every developer 20+ years ago, including non standard libraries and APIs,
> Microsoft can't be expected to ship every single outdated and insecure 20+ year old DLL and undocumented API with every copy of Windows,
This is not the point. The point is software using the _official API_ of that operating system. It's not about software which was using undocumented or 3rd party libraries. That's a strawman.
> And the excuses are not bullshit
They may not be bullshit, but they are literally valid for every operating system. I don't care what the argument is when my complain is that Windows is becoming worse in backwards compatibility than literally Wine itself.
> The 32 bit C++ executables I wrote in highschool for windows 95, still run right now on Windows 11 out of the box without any patches or issues. So backswords compatibility exists on windows live and well against your opinion that it doesn't. End of story.
And you started your argument about "black and white" vs "shades of gray"....
"My C++ executables run" is quite the low bar. I can also run my a.out executables from the 90s in Linux, and I'm assuming a similar level of compatibility with macOS . The Tcl files from my thesis in the 90s still work without a problem, too, even the GUI...
But I complained loudly when my Loki games stopped working on my Linux DE, and I complain loudly when my 2000s games stop working on Windows 8/10, and trying to justify this by saying "Security! Bloat! Tradeoffs" is as absurd on Windows as it is for a Linux desktop.
> You can't expect modern Windows to ship 20+ year old DLLs that allow running Windows 98 APIs as that's a major security vulnerability since older APIs had direct hardware/memory access without any kind of checks and balances.
That doesn't make sense. If those old DLLs could bypass some security protections in Windows than that would be still a major vulnerability in recent Windows itself.
No; the point is that if a USER SPACE library can compromise the security of Windows the operating system _in any way_ then that by definition is a Windows issue, not an issue of the library.
E.g., Wine ships other implementations of the same libraries and this causes zero extra security problems in Linux.
>Wine ships other implementations of the same libraries and this causes zero extra security problems in Linux.
Because Windows malware can't infect Linux, so why would that be a security issue for Linux? But if you run Windows, you definetly don't want to sideload and use unmaintained libraries and APIs that are 20 years out of date.
Why would be sideloading an "unmaintained library" be a security issue for Windows ?
To put it simply, it doesn't really matter what libraries you ship, they _cannot_ cause _new_ security issues in the operating system, by simple definition of user space.
And Windows malware can definitely infect Linux. That was not my claim.
Old games require being run as Administrator. In addition, user/kernel isn't the important security boundary you think it is. My tax returns, my pictures, my passwords, all of the data I actually care about is stored in files accessible in user space.
> My tax returns, my pictures, my passwords, all of the data I actually care about is stored in files accessible in user space.
So are the passwords of everyone logging in to this very website (stored in user space). I think you are confusing user/privilege separation with kernel-userspace separation.
You have not yet made a point. How can distributing a user-space shared library, no matter how fully loaded with ancient security holes, decrease the amount of security of your system?
We literally have this on Chen's today: https://devblogs.microsoft.com/oldnewthing/20221011-00/
Totally sure malware authors are going to compromise the files of an ancient game in order to trigger some bug in a library to get to your tax returns. No way they will not just change the game exec or something.
> How can distributing a user-space shared library, no matter how fully loaded with ancient security holes, decrease the amount of security of your system?
They probably want to put pressure on publishers to use newer libraries that don’t need administrative permission, so hopefully eventually getting a version of the program that doesn’t need admin. Encouraging better security hygiene.
I agree that user-space compromise is still really really really bad.
