5 ms·
There’s a very good business in maintaining backwards compatibility. Any large enterprise is not going to buy from a company that they can’t rely on having a ro
by justonepost 8y ago
There’s a very good business in maintaining backwards compatibility. Any large enterprise is not going to buy from a company that they can’t rely on having a roadmap that will fix security issues but won’t break their deployed software.
- scarface74 8y agoUnfortunately the market for "companies that need to deploy a fleet of Windows computers to run a bespoke app" is shrinking compared to the entire market. I'm thinking UWP is a them attempting to start over.
- Narishma 8y agoIsn't UWP still built on top of all those hacks upon hacks the previous commenter mentioned?
- slededit 8y agoYes, but it does a reasonable job of hiding it.
- scarface74 8y agoBut it should allow easier compatibility with lighter weight versions of Windows.
- realusername 8y agoMost software on Linux is backward compatible as well, you can get some 90s software, compile it and run it, however it does not have as many hacks as Windows has at the moment to achieve that.
- userbinator 8y agoyou can get some 90s software, compile it and run it, The "compile" is the tricky part; with Windows, you can get a binary from the early 90s and it will just run. My experience with Linux software is that while the kernel-userspace interface remains stable, userspace is itself full of breaking changes, and software has so many dependencies that trying to compile it quickly turns hairy.
- realusername 8y agoI must admit you are right, it works again on Linux because the API is stable and you have the source, if you take a Linux binary directly from the 90s, there's very little chance it's going to run properly..
- xioxox 8y agoLinux has a stable kernel ABI. If you can get hold of the appropriate libraries of the vintage of the executable and set up the library loading correctly, it is possible to run it. Of course if the binary is a.out format, then we can't do this.
- SteveJS 8y agoCompat 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 agohttps://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...
- digi_owl 8y agoThe CLI stuff, yes. In large part thanks to Torvalds holding everyone to strict rules. Higher in the stack, not so much.