[bombcar]

Kind of sad. Even from this blog, he admits that the Microsoft of old would test software and see if it worked; the Microsoft of now obviously knows of the existence of these shell enhancements, but clearly doesn’t test patches against them at all.

[praptak]

A relevant quote about the lenghts they went to to assure stuff not getting broken:

"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."

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

[giantrobot]

A huge difference between 1995 and today is in 1995 "simcity.exe" might represent fewer than a half dozen artifacts because patches and updates were rare. An exception covering a handful of cases is maintainable and testable.

Today patches are near constant so a "simcity.exe" might represent hundreds of different versions of the code. It's much harder to maintain exceptions since the list of cases is much larger. Even if your test harness is embarrassingly parallel your results are only as accurate as the latest version available to test.

None of that is impossible but there's additional non-zero costs involved in maintaining compatibility exceptions. At some point they tip over to not being worth the investment.

[rasz]

It was actually Simcity 2000 for DOS.

Jonathan Ross SimCity 2000 (1993) (IBM Programming) https://www.mobygames.com/developer/sheet/view/developerId,7...

Recently someone hacking away at DOS extender code stumbled on the same bug and fixed it independently.

https://www.vogons.org/viewtopic.php?p=1007153#p1007153

"New version 1.7 of DOS32AWE released, the download link is in the first message. Finally Sim City 2000 is supposed to be working flawlessly. The bug is in the game which sometimes overwrites unallocated RAM . A spare buffer is dedicated now which handles such buggy behavior. Could be useful in other games too."

[throwawaaarrgh]

That's a lot of money and time to spend on supporting someone else's bug-riddled software. You can't test literally all software that exists before you release a security patch. Just imagine testing every single solitary Windows application that exists, or has every existed, just to see if one of them crashes due to intentionally doing the wrong thing. What are they supposed to do, fix the 3rd party software? Delay fixing the security hole?

Testing is the responsibility of the 3rd party (in addition to using supported methods). If the 3rd party was part of a preview release program, they could test changes before they are officially released.

[userbinator]

That's a lot of money and time to spend on supporting someone else's bug-riddled software.

Consider that it's money and time that MS spent to get into their position today. They built their empire on "back-compat is king", and betraying that principle gives far less reason for their customers to continue using their software instead of moving to alternatives.

[Kwpolska]

Microsoft cares about backwards compatibility and does a good job at it IMO, especially compared to their competitors. The thing that broke was not a public API, but an internal, undocumented, unexported function in Explorer. Microsoft did patch API abuse in the past for prominent software, but they can't be expected to do it forever and for all software.

[JohnFen]

> Microsoft cares about backwards compatibility and does a good job at it

Indeed. This is one of the few points that I give high marks to Microsoft for, and when it comes to Windows, is the only thing that makes me feel sympathy for Microsoft devs.

Pulling off the level of backward compatibility that Windows has maintained for so long is an incredible accomplishment.

[twoodfin]

Software didn’t have to be that prominent to warrant a compatibility hack in Windows.

When I was exposed to the “shim” database in the XP era, it had thousands of entries.

[justin66]

I'm not sure if you're holding up the XP list as being better than the list today, but I bet even the list at that time did not include every random shell extension imaginable.

[twoodfin]

At the time, there weren’t that many “random shell extensions”. Many of the more common ones were almost certainly there if needed.

My point was you didn’t need to be a “prominent” developer for Microsoft to patch up your app at runtime. This was particularly important for XP, given that it was the big, strategic consumer swap to the NT kernel and had to go smoothly.

[bombcar]

They were the scrappy underdog then, they're the big dog now.

At least Apple straight up tells you "we support for about 3 years, then you're boned".

[StressedDev]

Apple supports its major products for more than 3 years. You typically get 6-8 years of support for an iPhone, iPad, and probably Mac.

Also, Microsoft supports each Windows version for about 10 years.

[toast0]

> That's a lot of money and time to spend on supporting someone else's bug-riddled software. You can't test literally all software that exists before you release a security patch.

Microsoft has been pushing telemetry for how long? I would think they would have a good idea of what to test so that p99 their software works for their customers.

But it depends on the severity of the security issue fixed. If it's a big deal, you push it and let telemetry dictate your future hotfixes. If it's not a big deal, you do your internal testing, then push it through external testing, and see what telemetry picks up (hey!)

> Just imagine testing every single solitary Windows application that exists, or has every existed, just to see if one of them crashes due to intentionally doing the wrong thing. What are they supposed to do, fix the 3rd party software? Delay fixing the security hole?

Microsoft made its business on "where do you want to go today?" Not "you're holding it wrong"

If windows and the 3rd party software worked before a windows update and doesn't after the windows update, that's Microsoft's problem because it reduces acceptance of updates. One way forward is to fingerprint the broken application and not do the update if it's active, another way is to prevent it from running after the update. Either of those allow unaffected users to get the update and get on with their life. Once the application is identified, Microsoft can work with them to update their software to do things right, and then figure out how to get users updated.

I've been a user of desktops where the OS developer clearly doesn't care about continuity for users, and Windows feels more and more like that. It's not pleasant, and if I can't be assured what works today will work tomorrow, that leads to delaying updates which is bad for business.

[jfultz]

This can come up even with application software (which is my area). If it worked before and it's broken now, or if your application appears to be the only thing that is broken for the user, from most user perspectives, it doesn't matter that the problem may have been technically created by an OS bug, errant virus scanner, or whatever. As I tell colleagues, "It may not be our fault, but it's still our problem."

[JohnFen]

Correct. Customers are paying for a working solution. If what they get doesn't work, they couldn't care less (and shouldn't have to care) about who or what is to blame. They just want it to work.

[bombcar]

> If windows and the 3rd party software worked before a windows update and doesn't after the windows update, that's Microsoft's problem because it reduces acceptance of updates.

This is the critical key to the whole thing. Currently, I basically apply updates as soon as they're available (with a bit of delay for major ones like new macOS version updates) but if I get burned a few times I'll go back to waiting carefully.

[justin66]

> the Microsoft of now obviously knows of the existence of these shell enhancements, but clearly doesn’t test patches against them at all

Microsoft taking into account this method of modding explorer in its testing would be like asking Apple's design team to take into account the one in a million iPhone user who sticks their phone up their butt. [0] I don't know what it says about Windows or its users that there must be more than one in a million people running this stuff, but still.

[0] https://www.youtube.com/watch?v=bsbpFKDIaZ0