3 ms·

So sad, because that could have been the DLL's finest hour. A lot of code uses ATL. Imagine if Microsoft had been able to update a few ATL DLLs and close the h

So sad, because that could have been the DLL's finest hour. A lot of code uses ATL. Imagine if Microsoft had been able to update a few ATL DLLs and close the hole for every app written to dynamically link to ATL. Instead, the dynalinkers were no better off than the static linkers. No wait, they were worse off.

roel_v 16y ago
To elaborate, the rub here was that ATL heavily relies on templates, code that is instantiated by the client at build time. The fix (IIRC but I don't see any other explanations either) required a change in one of those compiled-at-build-time parts (i.e, in the header), and was of such nature that it changed the ABI. If the part that had the bug had been able to be included in a dll (but it couldn't be because of the way templates work), swapping out the dll would have worked. So arguably it was exactly the static linking (forced by the language) that was at fault here. People who linked dynamically were forced to make some painful changes, but those who linked statically potentially had the security bug left in their programs. I'm not sure who of the two would be worse off here. I guess at Microsoft they considered the security implications severe enough to warrant a patch as disruptive as this one was.