> What exactly are backwards-compatibility goals of Windows? Are they that different from backwards-compatibility goals of POSIX systems?

I can still run software written for Windows 95, without recompilation, with a pretty high success rate. As far as I'm aware, only Linux has that level of ABI compatibility and unfortunately it's completely broken by userspace. Often you can't even run the same binary on two different distributions without recompilation.

The ABI is only part of backward compatibility. From another POV, you can run software designed for VT100 or other terminal in seventies on any Linux or Unix today, (though it may be recompiled. That legacy mentioned in previous post is that terminal is still considered serial device with specific protocol). There are companies, that do exactly that in production. You would be hard pressed to find DOS-era software that bangs on buffer starting at 0xB800:0000 that still works in 64-bit Windows.

> You would be hard pressed to find DOS-era software that bangs on buffer starting at 0xB800:0000 that still works in 64-bit Windows.

True, though 32-bit editions of Windows still include NTVDM which runs Win16 apps!

Microsoft is pretty fanatical about backward compatibility.

Why? It's the #1 reason most enterprises and many users continue to pay to install/upgrade to Windows.

Breaking backward compatibility with existing executables (not source-code) is a violation of the trust that we've earned with customers for the last 40 years or so.

Of course, some products/features/etc. are discontinued on newer OS', etc. but the core essential platforms are rarely discontinued.

True fact: Windows still runs VB6 apps - millions of them. EVERY DAY!