Back then you couldn't just bug the game developer to issue an update patch, and anything significant breaking between Windows versions affects Windows adoption and not the adoption of the software the user is actually interested in. We see the latter even today, with Windows 8 being a failure for how much it changed and broke user workflows and Windows 11 getting a decent bit of pushback too.
In a way this realization is what's finally making Linux viable for gaming. Instead of expecting developers to bring compatibility and bug fixes, have the system provide it and suddenly you can even have an entire gaming console designed for PC gaming on Linux, thus also giving you enough momentum for developers to make adjustments so their game runs better on the compatibility layer.
We're talking early 90s. Not only were automatic updates not a thing, manual updates were hardly thing. If Windows wanted SimCity to work on their new windows release, the only option was to make the new windows release work with SimCity, not the other way around.
Yeah. I had this version of SimCity. It came on floppy disk. I had a 14.4k modem at the time (or maybe still the stock 2400?) the only way for MSFT to make this work was to add code like this. Honestly we still do it sometimes. Emulators routinely emulate bugs because those bugs were never fixed in the real systems.
The hack being described was very very old, this is exactly what the AppCompat system does in Windows now. AppCompat shims only apply to specific versions of specific apps (or get rolled up into "layers" which is what you get when you mark an app to "Run under XP compatibility"), and don't end up affecting other ones
Yep. It’s just the first version of AppCompat. Now you get to pick a set of bugs and behaviors. It’s actually a pretty great idea to isolate problematic software.
That'd break SimCity updates, and probably trigger antivirus warnings, and annoy Maxis devs and lawyers...
Whereas "we'll tweak our OS to suit your app to ensure it doesn't break with an upgrade"? That just wins loyalty from the game devs, users, and everyone involved except purist-coder types.
And it makes operating systems larger, more bug prone and harder to maintain.
There is a reason that Apple was able to port the core of iOS and many of the APIs to watches, phones, tablets, set top boxes, monitors (the latest Apple monitor runs iOS on an iPhone 11 era processor with 64GB RAM).
Yeah, but there's also a reason why you can still run most Windows 95-era apps on today's PCs, vs not being able to run most 2-year-old games on M1 Macs. Rosetta is pretty amazing but it's far from actual compatibility.
Apple's approach to backward compatibility is very different from Microsoft's.
It's not uniquely a Microsoft thing, either. Nvidia's driver updates frequently (in fact almost always) have game-specific optimizations. Antivirus and firewall apps frequently have to make exceptions for certain apps. WINE and Proton operate on per-game optimizations. Input controller managers (like Steam's profiles) have different settings per game. DirectX itself does a lot of backward compatibility stuff, AND allow different versions to coexist on the same PC (vs the relatively tiny market that exists for Metal or Vulkan).
All these things contribute to PC gaming vastly outselling the tiny Mac gaming market. As a Mac user, I wish that weren't so! But MS's approach is way better for devs and users in that case, even at the cost of the Windows APIs and libs being huge with a decades-long tail.
As a user of a current ARM MacBook Pro 16 inch and a former x86 MacBook Pro, being able to have a battery that last 20 hours, doesn’t get hot, nor does it sound like a 747 when I launch Slack, I very much appreciate Apple being able to transition processors.
Also seeing that the iOS game market dwarfs the PC game market in revenue and number of titles (if not quality), I think Apple made the right choice.
Microsoft has been unsuccessful trying to get Windows on ARM to be viable for years before Apple did it and has failed partially because of the behemoth that Windows is.
Speaking of Windows and backwards compatibility. There are at least 8 different ways to define a string in Windows depending on which API you are calling. String handling in C is one of the biggest causes of security vulnerabilities on any platform.
> There is a reason that Apple was able to port the core of iOS and many of the APIs to
Microsoft can do this and just exclude the compatibility patches. All of those various windows versions and non-desktop OSes (eg windows phone, Xbox) are certainly the same thing. Porting an OS already means you’re picking what you want, and reusing the kernel. This isn’t that special.
Regarding maintainability, I’m not sure it’s “better”. It’s a liability to depend on mac software and update your mac. Ask how many photographers (or pick a profession) keep an old mac lying around for that one version of photoshop (pick your software) they need that doesn’t work on new macs. What’re the odds old mac is getting security updates and is well maintained?
(Also a nit, the monitor has 64gb of storage not ram).
Apple has ported its entire OS - not just parts - since the introduction of OS X to three different architectures. Should Apple still keep a PPC compatibility layer? If they had ported Carbon to 64 bit, would Adobe have ever moved over to modern MacOS frameworks?
Even further back, should Apple keep supporting OS 9? 68K processors?
How is the ARM transition for Windows working out no matter how hard Microsoft tries?
By changing the system they have a flag they can turn on for any applications that would be helped by a similar hack. It's not like use after free was a particularly rare event in mid 90s code.
You mean, like watch for an install of SimCity, and modify the game's files? I don't have enough experience in hardware and PCs to know if that was at all possible or practical.
Could also be interesting in a world where most PCs ran anti-virus tools of various different vendors.
Imagine Microsoft adding a magic “we’re the good guys” handshake to their OS that would all those anti-virus tool say “go ahead and do whatever you want”.
Honestly you could probably do it today, but back then it would have been a lot harder. You’d have to find every buggy use after free. Just easier to change the allocator for it. Probably how you’d do it today under emulation.
I remember the days of going down to my friends store because he had a modem and knew which BBSes would have software downloads. I had to bring my own floppy disk because those things cost money.
Yeah... I've put well over 10k hours into writing FOSS and consistently encounter this attitude there, too. I never imagined we could get this far tolerating such frequent contempt for both end-users and their advocates, such as interface designers. If your PR poses even a theoretical future inconvenience to developers, good luck getting it merged, regardless of the user benefit. Until this changes, user-facing open source alternatives will always be alternatives rather than the standard.
Not just devs and end users, but also devs and other devs. Not in rejecting pulls but changing API's like renaming functions, removing functions, swapping argument positions, changing the complete workflow of a library, etc... without care. The amount of breakage in the OSS world is just ridiculous.
I'm probably biased because I deal with a lot of Javascript where this sort of behaviour is rampant.
It’s easy to optimize for developer convenience when you aren’t getting paid to do the work… arguably it’s the only way non-profit open source software can progress at all on average. The tails are heavy, though.
A workaround does not necessitate tech debt. "Workaround" is a conflated term - it basically implies something works differently than one might expect, which is subjective. Anyway, what is the alternative? Saying "that's not my problem"? Users don't care about who is technically at fault, they care about a well functioning product.
The alternative is to let it break and force developers to update their software.
Doing that allowed Apple to not have to maintain 32 bit compatibility which allowed Apple to make the operating system smaller (all shared libraries have to be duplicated including in memory) and allowed Apple to completely remove 32 bit support in the later ARM processors.
…and forced me to stop using some favorite iOS apps because they didn’t get updated — in one case because the developer had died. Windows is certainly more user-friendly in that respect.
"Tech debt" is doing things quickly now with the price that you have to clean up (i.e. invest more time) later, hence the word "debt". This is sometimes a good trade-off, just as financial debt is. Not everything that looks a bit ugly is "tech debt".
And yes, it's ugly, but reality is ugly so we have to deal with it.
I would have more sympathy for that if Windows 95 were just suddenly dropped out of the sky to some rock music, but my experience with MSDN is that they are quite liberal with access to beta versions so software vendors can test their products before the unwashed masses get it
And I say this as someone who remembers the binders full of CDROMs that arrived, so not just "download this iso" modern day conveniences
Let's say SimCity took advantage of this beta program and fixed their buggy software. Great!
Now how do you get that fixed software to every user who bought a SimCity CD or floppies? Remember, most of your users don't have a modem and there is no widespread internet infrastructure at the time of the Windows 95 release.
You're arguing who is truly at fault, but as a consumer with less sophistication than "MSDN Subscriber" who are you going to blame when Win95 doesn't run your favorite software?
Those who prioritize code correctness over user experience will soon find themselves in that blessed paradise where they never have to worry about user experience anymore... because there are no more users.
Microsoft made most of its money back then in two ways - corporations and individuals buying Windows upgrades and bundling Windows with new computers.
If Windows got a reputation for being incompatible with apps, people wouldn’t upgrade.
iOS doesn’t really have that problem. New phones are always going to come with new operating systems and if your app doesn’t run on the new OS, users are going to blame the app developers.
Also most of the incompatibility with apps and new operating systems comes from developers using unpublished APIs. Apple is very strict about not allowing developers to use unpublished methods [1].
[1] I refuse to use the term “private APIs”. An API is a documented method that the platform vendor documents and promises to support
In a way this realization is what's finally making Linux viable for gaming. Instead of expecting developers to bring compatibility and bug fixes, have the system provide it and suddenly you can even have an entire gaming console designed for PC gaming on Linux, thus also giving you enough momentum for developers to make adjustments so their game runs better on the compatibility layer.