3 ms·
The bug they fix is the bug that keeps the API contract intact. The first application gets its bug fixed, and the second application breaks because it was relyi
by magnetic 9y ago
The bug they fix is the bug that keeps the API contract intact. The first application gets its bug fixed, and the second application breaks because it was relying on a bug that didn't match the API contract.
You program to an API, not to an implementation. The second application did the latter, and will therefore pay the price.
- emodendroket 9y agoWell, sometimes, but the Windows philosophy is probably to introduce a shim so that an app relying on the broken functionality still works.
- magnetic 9y agoIf you can afford to do that, it's nice to do it indeed. It can get messy and hairy quite quickly though. It seems to me a lot of it boils down to "who gets impacted". If I have a bug in my kernel and a lot of apps are somehow relying on it, I need to be mindful of that and perhaps swallow the purity of the contract in order to provide a pragmatic fix.
- emodendroket 9y agoSure, it's not a strategy without costs and Microsoft goes to an extreme. But there's probably a middle way in there; if you're aware that tons of programs now depend on the buggy behavior you probably want to deal with it. But if you're working on Windows or the Linux kernel the tolerance for breaks is probably much lower.
- curveship 9y agoThat's not Linus' position. The "API contract" for the kernel is "we don't break userspace code," not "we don't break userspace code that follows the specs." He would bounce (and flame) the fix you're suggesting.
- oinkush 9y agoThat sounds insane. Is it written somewhere besides a sporadic Linus rant? (e.g. somewhere here https://www.kernel.org/doc/html/latest/ https://www.kernel.org/doc/html/latest/ etc.)
- caf 9y agoIn other words, the ABI you have is the ABI that got used, not the ABI you thought you were building.