Apparently it’s not that the software is broken, it’s that the software being installed breaks Windows Update. There are reports from people that uninstalling StartAllBack, updating the OS, then reinstalling it back (renaming the install executable first) works fine.
As much as being affected by this is frustrating to me (though this is all happening still on the dev channel, so for me it’ll be a problem for the future), I understand Microsoft’s rationale here. They can’t be expected to support every third-party tool that can break the OS, and it’s known that both ExplorerPatcher and StartAllBack relies on many hacks using undocumented APIs to work.
In the last few decades that I’ve been using Windows, I never felt compelled to use shell replacements or customizations - the default experience always worked fine for me with a few tweaks. So, if anything I’m more frustrated at Microsoft that I’m forced to use StartAllBack, because MS went and removed options from the shell that existed forever and always took for granted, and then some.
They can’t be expected to support every third-party tool that can break the OS
They don’t have to support it. They just have to let it break. It is your PC. They can issue notifications to their system and add these apps to their troubleshooter as possible conflicts.
What they abso-fucking-lutely cannot be allowed to do is to decide what software you’re allowed to run on your PC. This is a dangerous precedent and a slippery slope.
I’m going to have to disagree here. If they made their operating system in such a way that the update service can be broken by any random developer, and the fact that their own software is on this list, kind of indicates to me that this is a them problem. They can’t be expected to support third party software, but they absolutely can be expected to provide a stable method to deploy patches to their systems. Linux and MacOS don’t share this issue.
I’m going to guess it’s not very easy to simply fix this problem if you’re an app developer. Intel, AMD, Microsoft itself, et. al. simply wouldn’t jeopardize their own products in this way and I’d bet many of them are unaware this is happening to their software. Some of these call-outs on the list are years-old at this point.
Apparently it’s not that the software is broken, it’s that the software being installed breaks Windows Update. There are reports from people that uninstalling StartAllBack, updating the OS, then reinstalling it back (renaming the install executable first) works fine.
As much as being affected by this is frustrating to me (though this is all happening still on the dev channel, so for me it’ll be a problem for the future), I understand Microsoft’s rationale here. They can’t be expected to support every third-party tool that can break the OS, and it’s known that both ExplorerPatcher and StartAllBack relies on many hacks using undocumented APIs to work.
In the last few decades that I’ve been using Windows, I never felt compelled to use shell replacements or customizations - the default experience always worked fine for me with a few tweaks. So, if anything I’m more frustrated at Microsoft that I’m forced to use StartAllBack, because MS went and removed options from the shell that existed forever and always took for granted, and then some.
They don’t have to support it. They just have to let it break. It is your PC. They can issue notifications to their system and add these apps to their troubleshooter as possible conflicts.
What they abso-fucking-lutely cannot be allowed to do is to decide what software you’re allowed to run on your PC. This is a dangerous precedent and a slippery slope.
I’m going to have to disagree here. If they made their operating system in such a way that the update service can be broken by any random developer, and the fact that their own software is on this list, kind of indicates to me that this is a them problem. They can’t be expected to support third party software, but they absolutely can be expected to provide a stable method to deploy patches to their systems. Linux and MacOS don’t share this issue.
I’m going to guess it’s not very easy to simply fix this problem if you’re an app developer. Intel, AMD, Microsoft itself, et. al. simply wouldn’t jeopardize their own products in this way and I’d bet many of them are unaware this is happening to their software. Some of these call-outs on the list are years-old at this point.