Microsoft used to be quite dedicated to this too. If you look at the leaked Windows XP source code you can find compatibility shims to ensure that older Versions of Quicken or Acrobat Reader or Settlers 3 still work. A "don't break userland" policy is part of the reason they became so popular in businesses. Since then times seem to have changed somewhat.
That changed because they have a major refactor starting from Windows 7. They have it up to the spec and not so much more ad-hoc behavior this time.
To me it seems like cutting the compatibility arm is worth the price of having to keep a shitty, inconsistent behavior.
Apple has nailed it so well (don't make it backward compatible) for the last decade afterall, since Apple realized one the internet is so much better and source code management (and repository, backup, disaster recovery) became more accessible so that the cost of port became much lower.
To be fair though I think there's a happy medium. For a while I really loved Apple's approach of just not giving a damn about backwards compatibility but I have to say using Windows did make me realise just how wonderful it is not worrying about whether the software I want to use will work.
It's a constant issue around me. I know people still keeping 10.6 Macs and sweating profusely at the idea that one day they'll stop working, as the tools they use haven't been ported upwards (because most often the developer of the proprietary app is dead) and will stop too ; imagine an artist whose favorite signature brand of crayons closes door.
for macOS 9 and older, yes, but not as far as I know for the first OS X releases - and running in a VM generally would not cut it (besides being extremely hard to do)
> To me it seems like cutting the compatibility arm is worth the price of having to keep a shitty, inconsistent behavior.
The ideal solution would be to have a compatibility shim (like Wine) to provide the old behavior while being able to make the native behavior more consistent.
