Windows 8 is backwards compatible with Win32 and even Win16. If it wasn't, there would be hell to pay. WinRT is a somewhat clean break with the Win32 legacy. But that's only required for Metro apps.
To be fair, 64-bit Windows 7 (and Windows 8) don't support Win16 (as I understand it, because you can't sneak real-mode code into x86 64-bit mode the way you can in x86 32-bit mode).
OTOH, let's be clear about what Win16 is. Win16 is an API that Microsoft deprecated in 1995 (not coincidentally, when Windows 95 was released). In other words, Microsoft took 14 years to go from deprecation to significant (partial) non-support.
One major reason there have been 32-bit versions of all Windows releases up to and including Windows 8 is so that corporations big and small will be able to seamlessly continue running their crusty Win16 and MS-DOS legacy applications. If not for that, many companies would not have been able or willing to upgrade. Microsoft could instead have taken a DOSBox or Rosetta style approach. Hopefully they will do that with some future release, so developers will no longer have to worry about 32-bit support.
So, I feel my original statement was accurate in both its letter and spirit.
Oh, I completely agree with the spirit of your statement. And my disagreement over the letter is over the interpretation of an unqualified "Windows 8" (or "Windows 7"), not about the substantive facts.
The reason I went into that level of detail is because I wanted to highlight the insanely long 14-year deprecation cycle. Is that a record for a deprecation that was eventually removed?
I think if you focus on the win{16,32} API, it doesn't do any justice to, for instance, the C library. FreeBSD has always supported binaries from various UNIX systems and I think this heritage goes back a bit further then 1995. Also, windows bundles a c library of its own which implements a significant subset.
Sure win{16,32} support a GUI with bells and whistles but that's because it evolved several years later specifically to support this newer mode of UI. It does not support 50-year old teletypes.
You misunderstand my point about length. I'm completely aware that there are plenty of APIs that have been supported far longer than Win<anything>. That's not what I'm talking about.
What I'm wondering is this: Has there ever been an API with a longer deprecation period than Win16? Remember, Microsoft announced the deprecation in 1995 (IIRC), but it didn't start to bite until 64-bit Windows mattered (you could draw the line at some server versions, Vista, or, as I do, at Windows 7). No matter how you slice it, that's a long time.
OpenGL 4.2, backwards compatible to OpenGL 1.0 (1992)
OpenGL ES, not backwards compatible with OpenGL.
There's an obvious parallel here of APIs being compatible within themselves but not across boundaries between major architectural revisions intended to throw out cruft and target new environments.
This line of reasoning is utterly absurd. They are different APIs with different names. The specifics of the substrings they have in common and the format of the substrings that differ is utterly irrelevant.
OpenCL is a different API from OpenAL, Cocos-2d is an API for an entirely different language than Cocos-2d-x, the Cocoa API is wildly incompatible with Cocoa Touch. Horrors!
You determine whether or not two APIs are compatible (or even striving to be the same kind of API) by reading the documentation, not by applying stupid heuristics to common substrings in their names.
X11 wasn't deprecated in 1987, that's when it was released. So far as I know, X11 hasn't been deprecated.
Side-note: Win16 (called "the Windows API" back then) actually predates X11 (though not previous versions of X) since Windows 1.0 was released in November 1985.
Windows 8 is backwards compatible with Win32 and even Win16. If it wasn't, there would be hell to pay. WinRT is a somewhat clean break with the Win32 legacy. But that's only required for Metro apps.