[rewma]

> But that sleight-of-hand hides the fact that many (perhaps even most) security fixes do not break the ABI or API; they are completely contained to the implementation (one obvious exception would be if the security issue was caused by bad API design, but even then often there are ways to fix it without breaking the ABI).

Right you are. I was also perplexed when I read that non sequitur. The author's reference to DLL Hell also suggests there's some confusion in his analysis of the underlying problem, given that DLL Hell is very specific to windows and at best is only orthogonally related to ABI. The author's references to API changes make even less sense, and definitely cast doubt over his insight into the issue.

[pjmlp]

And was kind of fixed with application manifests, on XP.

[salawat]

Differentiating DLL and SO hell is getting a bit beyond pedantic as they are implementations of the same fundamental abstraction. Any substantial difference in merely one of implementation details.

[rewma]

> Differentiating DLL and SO hell is getting a bit beyond pedantic (...)

It really isn't. Unlike linking problems, where the problem is focused on how you need to fight your dependencies to be able to resolve symbols, DLL Hell has been for over a decade a dependency resolution problem that is solved at the packaging level.

More importantly, on Windows, where sharing DLLs is not a thing, you can simply drop a DLL in the app dir and be done with it. In fact, it's customary for windows apps to just bundle all their dependencies.