Hacker News new | ask | show | jobs
by simonsarris 1366 days ago
Thanks for your work, Dale.

IMO this was good practice to keep the web running smoothly at the time.

It is reminiscent of Windows 95's specific code to see if SimCity is running, and allocate memory differently if it was.

> Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.

from: https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

5 comments

When I was at Apple in the mid 90's (Before Steve) I remember the Mac OS source code had tons of special app checks, mostly for various Microsoft (also others) apps that did odd things, so that older versions would keep running. When they were working on Copland, I thought it was nuts to write a new OS from scratch, but still do reimplement the hacks so that everything would still run. Good thing it all went away.
They’re still there. IIRC there’s a whole workflow/category in Radar for it.
Wait, I thought the only workflow supported by radar was ticket filed -> ticket ignored -> product eventually EOL -> ticket closed
probably only a 50/50 chance it gets closed tbh. Either way it's in a black hole to the reporter so they'll never know.

(I actually liked radar though, as bug trackers go - by far the best internal tool apple has imo)

My astonishment is that Microsoft knew about SimCity. I was 15 in 1995 and I thought the world was so big that Microsoft couldn’t possibly know about the myriad of software that their OS could run.

It turns out the world was so small that Microsoft could, probably, inventory less than a hundred products that made 99% users happy.

Raymond Chen talked about how periodically the devs were tasked with getting a handful of software purchased at CompUSA or w/e out of a grocery cart, opening them up, installing them and testing that they worked with the then-unreleased Win95.
Move slow and don't break things
If you want to make the big bucks, move fast and don’t break things.
When people don't have the ability to update for very low cost
> I thought the world was so big that Microsoft couldn’t possibly know about the myriad of software that their OS could run.

At large enough scale, 1 in a million is next Tuesday - https://learn.microsoft.com/en-us/archive/blogs/larryosterma...

The comparison is apt. The multiprotocol thick client platforms we call "web browsers" are easily on par with operating systems in both their complexity, and their mission criticality. LoC has never been a great comparison measure, but I'd anticipate that all current evergreen browsers have more lines of code than Windows 95 did.
Very cool and very swag, but down this road lies nightmares. I respect the dedication to backwards compat but we shouldn’t pretend this kind of thing has no cost.
Yeah why fix bugs when you can just enshrine the bug as a feature.

Backwards compatibility like this is a mistake.

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.
But then why not let windows patch simcity, instead of changing the system, just asking.
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.
Thanks for then explanation!!
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.

> 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 also routinely breaks software compatibility with zero apologies.
64 GB of storage, 4 GB of RAM.
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.
>like watch for an install of SimCity, and modify the game's files?

Yes exactly! Technically easy, a Lawyers thing maybe?

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.
Legal reasons.
I remember the days of burning all sorts of updates for software to cd or DVD
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.
What you call a “mistake” is actually just having empathy for the user. User experience is king.

It’s not tech debt, it’s a feature.

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.
Boxed software Microsoft: if it breaks, then Microsoft is wrong.

FOSS and new Microsoft: if it breaks, have you tried pulling the latest? Yes? Then it's a bug in your expectations.

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.

> I'm probably biased because I deal with a lot of Javascript where this sort of behaviour is rampant.

It's overall. The size of libraries in a linux system [1] has grown steadily over the years wirhout bringing anything useful.

The QT and GTK libraries are the perfect example of incompatibilities and bad design.

[1] Slackware which did not changed much in term of offered programs over the years.

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.
If you write the program for yourself, yes. Why then bother with an OSS licence ?
Surely it’s both? Some technical debt can be okay just like some personal or corporate debt can be okay.
Every piece of code you write automatically becomes code you have to maintain. It’s tech debt.
I agree that it's empathy for the user, but I'd say it's a workaround, and as such it's tech debt.
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.

If you play a lot of SimCity on Windows 3.1, then you upgrade to Windows 95 and SimCity stops working, who are you going to blame?
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?
MSDN ? In windows 95 ?
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.
A-list apps have always received special treatment.

MacOS and Windows are both full of app-specific hacks to ensure that misbehaving but popular apps continue to work between system versions.

Correct. And not even always only A list.
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

It's the difference of an OS targeted exclusively (at the time) for home users vs one for academia and web servers.
software distribution had a quite different model in that era.
Nowadays yes, back then this was the more reasonable approach