Hacker News Reader

Comment by throwawaaarrgh | Hacker News Reader

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.

View on HN

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.

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.

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

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.

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.

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.

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

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.

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

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

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

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.

Reply on news.ycombinator.com