See also<p><a href="https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/" rel="nofollow noreferrer">https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...</a><p>one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
Raymond Chen has been providing an inside perspective on this for decades: <a href="https://devblogs.microsoft.com/oldnewthing/" rel="nofollow noreferrer">https://devblogs.microsoft.com/oldnewthing/</a>
A fun side-effect of the "general" stability of Windows APIs is that Win32/DX has become a very stable and reliable "universal" API for Linux (and other OSes) via the massive amount of work put into Wine/Proton. I keep seeing games drop their Linux-native releases in favor of just shipping for proton.
It's not insane, it's my expectation for a tool. My hammer still works perfectly well with nails I bought 30 years ago.<p>It's impossible to build on shifting foundations that are constantly breaking backward compatibility. You eventually spend all your time maintaining instead of creating.<p>Then you have to go reinvent your wheel, and in my experience as a user your shiny new one isn't necessarily better.<p>Most of the software I use is more than 10 years old. Some is still updated, some is not (or went cloud and left me happily behind).
I used to believe this, but no longer.<p>Any Steam game that used the "Games for Windows – Live" service, and wasn't updated since the service shut down in 2014, would fail to launch on Windows 10 & later, because the DLLs for the service were removed. For a time, folks were able to download the DLL from third-party sites, but that doesn't work now.
Even more “insanity”:<p>z/OS (aka OS360 aka MVS) supports programs going back to the 60s and I just talked with a DE at IBM who is still using a program compiled circa Apollo 11 mission.
Its famously determined, but I feel that a DOS CLI app isnt much of a challenge since the DOS subsystem is essentially ossified. What would be the result if, say, you tried to run something DOS-y that was demanding or an early Win16 app? Say, Zortech C++ from 1986 with the Pharlap DOS extender or Minesweeper from windows 3.1. Would they work?
That shouldn't be considered remotely impressive. It should be seen as routine and expected, and if it doesn't work, that should be considered a hugely humiliating and unacceptable fail.<p>To be clear, I am not saying that it's not impressive in the shitshow that is 2023. I am saying what norms we should work towards.
Someone’s gonna come and say that linux has that too, and while technically true it’s quite hard in practice.<p>The kernel abi is stable, everything else is pure chaos, and this is mostly due to how applications are usually packaged in linux: your app could load (as long as it’s not in a.out format) but then would fail at loading most libraries. So effectively you <i>need</i> a whole chroot with the reference linux distro (or other runtime in general) and I’m not so sure you could find archives of 30 years old distros.<p>And I’m assuming that the kernel abi hasn’t actually changed a single bit and that no other interfaces changed either (stuff like /proc or /sys - /sys wasn’t even there 30 years ago i think).<p>And if you’re running an Xorg app, I wouldn’t bet my lunch on that level of protocol-level compatibility.
I've always been sad that my old Mac software just won't run. It's one thing for Apple to move to new architectures. Maybe that was necessary. But when the emulators break after a few years, well, that's the part that bugs me.<p>Microsoft's devotion to its customers shouldn't be so amazing-- it's the way that every company should behave.
yes it can run things that don't use much of the API surface (just using libc? probably fine)<p>however try running a game from the Windows 95/98 days and you've got a maybe 50/50 chance of it working<p>e.g. they changed the return code from BitBlt from 95/98 -> XP, they used to return the number of scanlines but switched it to a boolean<p>same with the heap management functions, directory traversal functions, etc
I wish there was a backwards compatibility option to give applications a “virtual display” which runs in a window, for old programs which only know how to run fullscreen at 1024x768.
FWIW, Beavis and Butthead in Virtual Stupidity (1995) runs perfectly fine in Windows 10/11 with compatibility mode enabled. No need to test anything else as that's arguably the apex of software (and humanity's collective output).<p><a href="https://www.myabandonware.com/game/mtv-s-beavis-and-butt-head-in-virtual-stupidity-a1c" rel="nofollow noreferrer">https://www.myabandonware.com/game/mtv-s-beavis-and-butt-hea...</a>
I have always believed this has been one of the primary reasons for which Windows won decisively against MacOS.<p>Apple has never had a problem throwing away their customers’ investment in their ecosystem. I was at a company with several hundred Macs when the transition away from PowerPC happened. It was just brutal. And costly. Not just hardware, software too.<p>And, what for? From a business perspective, you can do the same fundamental work woth both systems. The difference are: My investment is protected in one case and not the other. We have a bunch of Macs here. Only where absolutely necessary and for multi-platform testing.<p>As much as MS is maligned by purists, the truth of the matter is they have always protected their customers by having a remarkable degree if backwards compatibility, which isn’t easy to achieve and maintain.
My windows 11 upgrade experience was one of the smoothest ever. I was playing AOE, got a notification that my machine is eligible for upgrade, paused and saved the game, did the update and resumed.
Microsoft's commitment to backwards compatibility is definitely one of the strengths of the Windows platform. On the flipside, it's also at the root at the insanity that is the forbidden word list in MS Teams channel names.<p><a href="https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams#channel-names" rel="nofollow noreferrer">https://learn.microsoft.com/en-us/microsoftteams/limits-spec...</a>
Lots of Microsoft app compat success stories out there, but plenty of breakage too. One example: I had to create IndirectInput [1][2] to fix Myst on Windows. Microsoft refused (via private email thread with leadership) to take responsibility for what is clearly an appcompat bug and were borderline jerks to me about it too. Oh well.<p>[1] <a href="https://github.com/riverar/IndirectInput">https://github.com/riverar/IndirectInput</a><p>[2] <a href="https://support.gog.com/hc/en-us/articles/360019256854-Myst-IV-Revelation-launch-problems-on-Windows-10?product=gog" rel="nofollow noreferrer">https://support.gog.com/hc/en-us/articles/360019256854-Myst-...</a>
Does Linux have this backwards compatibility? What about macOS?<p>I know instruction sets changed from PowerPC to Intel to ARM, so probably not macOS at least. But this is a CLI and I doubt old system calls changed
I have a command line Windows binary compiled over 30 years ago (June 1996) that <i>won't</i> run on Windows 10 (64 bit). Windows complains, "ANAGRAMS.EXE is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher."<p>Is this issue specific to Windows 10, and would it work on Windows 11?
I'm ashamed to admit I really like windows 11.<p>Telometry and other questionable things aside, I've loathed and detested every UI change that Microsoft has done since Windows 7.<p>I unequivocally believe that windows 7 was peak windows UX. Every subsequent version, I've limped by using classicshell and then openshell.<p>Windows 11 is the first windows release where I didn't feel the need to install something to bring me back to the late 2000s.<p>My only pet peeve is not allowing me to create accounts that don't tie into outlook. Yes I know there are tricks to bypass this but I shouldnt have to do that.
Meanwhile my new Android Pixel phone will run literally none of the Android apks I bought 5 years ago on humble bundle because it's 64-bit only and they're all 32-bit.
I fail to see why 30 years should be considered extraordinary when in the physical world we have standards that ensure compatibility for much much longer than that.<p>If anything, software has it easier: you can layer emulation layer on emulation layer and then only have to adapt the outer layer for whatever pointless changes you are making to the current system.
Ha, the version of ZIP that I use was built in 1996, and I was using a version of 'ls' that I wrote for NT 3.1 -- maybe 1993 or so -- until a couple of years ago.<p>These programs don't use DLLs, and frankly there's little reason they for them to stop working.
I'm going to go ahead and say operating systems that <i>don't</i> work this way are the exception. Running a 30 year old binary isn't all that big a deal. Pretty much every mainstream system does so every day in its day to day operation.
This is fun and related
"chain of fools 2017"
<a href="https://www.youtube.com/watch?v=PH1BKPSGcxQ">https://www.youtube.com/watch?v=PH1BKPSGcxQ</a>
Surely there's some kind of legacy Windows containerization / subsystem / emulation technology that would automagically handle such things by now?
This works for win32 apps too. It's what gtk should have strived to be. New features should have never been prioritized over API stability. What a shame.
It's sad that the windows kernel and API aren't even that bad, but Microsoft insists on shipping as much bloatware and spyware as they can. Do I really have to use a debloater to have a usable OS?
I mean, Windows 10 comes baked-in with 30 y.o interfaces all over the damn place, this is hardly surprising. They've been poorly applying thin coats of paint for ages.
All the people on that Twitter thread getting butthurt about it and complaining that Windows' backwards compatibility is a bad thing... WTF koolaid have they been drinking?<p>I don't often sing Microsoft's praises but backwards compatibility is something they get absolutely right: something they've <i>always</i> got right. Everything doesn't have to be changing and breaking all the time and, to me, it's a mark of maturity when an organisation can maintain compatibility so as not to inconvenience - and introduce unbudgeted (and sometimes very high) costs to - users, integrators, and consumers. Top marks, Microsoft.
What I find so frustrating is that Windows, under the hood, is so solid.<p>It's just the UI with Bing/Ads/telemetrics/etc integration is so crap, like they've ruined a solid OS with crappy surface level stuff.
That's cute and all, but it's fucking gzip. It doesn't have complex dependencies.<p>Pretty sure Linux could run a 30 year old gzip binary too. I've never needed to do that with gzip but I have definitely run binaries of a similar vintage without issue.<p>Windows backwards-compatibility fails miserably on non-trivial programs, you're generally pretty lucky if you can get something from the XP-era or older to work out of the box.
Is it? Maybe insane in a bad way.<p>Right click on windows desktop had what now 3 different menus that might show depending on what you want to do. Oh. And let’s not talk about how much of what you see just covers the stuff up from 1998. Still rendering the old stuff only to have a slightly larger menu render right on top of it.