3 ms·

Compat in windows was a highly engaged technical problem, in a way that would be considered ‘hack on top of hack’ in linux. Windows ability to shim is signific

Compat in windows was a highly engaged technical problem, in a way that would be considered ‘hack on top of hack’ in linux. Windows ability to shim is significantly more sophisticated then maintaining a stable abi. It can present a facade of old implementation details to specific programs. Here is a Raymond Chen blog post (2006) on making an app with a ridiculous bug continue to ‘work’ by creating a decoy to compensate for the app bug. He mentions app compat in the ‘immature’ days of windows 95 where they ‘only’ had the ability to use app compat flags and hot patch binaries in memory on load: https://blogs.msdn.microsoft.com/oldnewthing/20060109-27/?p=32723 https://blogs.msdn.microsoft.com/oldnewthing/20060109-27/?p=... It can be argued that extreme app compat is a bad thing. Paying customers with line of business apps that ‘simply’ continued working never argued that.

digi_owl 8y ago
https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii-chicken-and-egg-problems/ https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii... Simcity supported in Win95 by allowing a use-after-free bug (if i am reading it right) to continue working. You get something similar in Linux by how once a userspace facing API is in the wild, the API stays, bugs and all, in case something, somewhere, use that specific behavior. A newer API will be introduce alongside the "broken" one however, with future code highly incentivized to use the newer API. Sadly that level of stringent API behavior is seen not as a virtue but as a burden by higher layer devs. Often to the point that the refuse to work with Torvalds after being berated for their lax attitudes, and dream of the day he retires...