Anyway, does anybody still have this article somewhere? I couldn't find it anymore :(
As much as MS had the reputation of "Windows isn't done until Lotus won't run" back in the day. If you follow some of the MSDN blogs, you'll find the extraordinary hacks that MS has done over the years to keep the most obscure programs running.
People complain about how Apple will drop support for backwards compatibility but this a consequence of the MS culture of doing just the opposite.
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.
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=...
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.
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...
Can't find the site again, but someone figured out you can use an older version of the Borland resource editor to convert the embedded resources to a newer format, than patch the exe header to say it's a windows 2.0 binary and it will run even on windows 10 (32bit version only since of obviously needs the 16bit subsystem).
I was seriously impressed when I saw that.
And afaik, MS only retired the 16-bit subsystem because AMD64 can't switch between 64 and 16 bit modes. You can either run it in 16/32 or 32/64 modes, but not 16/32/64.
Interesting enough you can still mark a code segment as 16 Bit and the CPU will execute it in 16 Bit mode.
https://www.wine-staging.com/news/2016-02-10-blog-wine-16bit...
The tricky part is that a LDT entry also contains flags which define if a segment contains 16 bit, 32 bit or 64 bit code. If you change to a segment, the CPU will automatically start interpreting the code inside the segment according to this value.
In other words, 16, 32, and 64-bit code can all coexist simultaneously and the CPU can switch between those automatically --- MS just decided not to implement it. Linux with WINE does, however.
Frankly that part is a large contributor to "consumer" Linux never got any traction beyond Google going all out and making their own (Android and ChromeOS), while the DE people keep "polishing" the UX by introducing yet more dependency kudzus.
One example on the top of my head is udisk. First there was udisk1, that had a CLI interface as well as a dbus api. Then came udisk2 that trashed the CLI interface and introduced a new dbus api. And now there is probably some equivalent of udisk3 living inside systemd that has yet another dbus api.
And all this for what? Mounting and unmounting removable media...
Ironically Sutter was saying in C++ [sic] "we have a good backwards compatibility story". :)
http://en.cppreference.com/w/cpp/compiler_support
And the table lacks most embedded compilers.
But yes, embedded compilers are usually a nightmare.
Yeah, I get that with embedded, it's a crapshoot. However it's probably not ridiculous to say that GCC ports to microcontrollers is not terribly uncommon, either.
GCC and Clang certainly are a lot more useful than for just that tiny range you listed. The reality is they probably cover more platforms than any other individual compiler.
https://blogs.msdn.microsoft.com/vcblog/2017/09/11/two-phase...
https://blogs.msdn.microsoft.com/vcblog/2015/09/25/rejuvenat...
In most places I worked for it actually seemed to have the reputation of a fairly good compiler toolset, unfortunately with just a bit of non-standardness sprinkled on top of it, a bug here and there, and perhaps not the fastest out there. (Which describes pretty much every other compiler out there as well: it's not like there's a perfect one with no quirks whatsoever). But it does the job, the optimization is ok as well, and it usually comes integrated in VS which is top of the line compared to other IDEs.