The fact that an application can slow down the system doesn't sound like a problem with the application, but rather it's a problem with the OS. Tracking applications that "are not fixed" is not the solution. Fixing the OS is the solution.
The fact that an application can slow down the system doesn't sound like a problem with the application, but rather it's a problem with the OS. Tracking applications that "are not fixed" is not the solution. Fixing the OS is the solution.
Otherwise I would be inclined to agree with you, but in this specific case I'm torn. These apps (ab)used a private API and the OS update meant they suddenly used it incorrectly. That's not something that's really the OS fault as far as I'm concerned. But I do agree that better separation is always good.
Historically Windows was known for not causing this kind of breakage for even “(ab)users” of private APIs, common misusers, buggy users, etc. And even working around such issues on the OS side.
Yeah, Windows is actually known for bending the OS so that backward compatibility is preserved. They even added a GUI tab with Compatibility settings.
But of course, Apple is not Microsoft, so they can do whatever they please. On Apple systems, non-working software on new macOS releases is a normal thing, maybe part of their philosophy.
>Windows is actually known for bending the OS so that backward compatibility is preserved
Such as... having two context menus ;)
In this case Electron intentionally used reflection to override functionality that isn't part of the API surface, so maybe not as cut and dried as all that