Microsoft and the API War
Joel Spolsky wrote a recent article "How Microsoft Lost the API War?" because of its recent tendency to abandon existing APIs and languages such as Win32 and VB6 in favor of new ones, like WinFX and VB.NET.
I don't think his arguments are persuasive. If anything, I think the new platforms have revitalized interest in programming Windows. I think that I think the older platforms was showing their age and preventing innovation.
In Win32, APIs were inconsistent and split into one of many different models--the classic API, COM interfaces like OLEDB and DirectX, C++-based APIs like GDI+, and OLE Automation-based object models found in Office applications. These various APIs were optimized for one language, and thus inaccessible or awkward to use from another language. There also was not a clean mechanism to move or run applications in the different platforms, be they different mobile devices or 64-bit processors.
Jeffrey Richter has spoken about some of the challenges Windows faced to balance innovation and compatibility. Entire features, that have been fully spec'ed, developed and tested for Windows, had to be dropped, because of incompatibility with legacy applications. He described how improvements to CreateWindowEx broke several existings application and had to be abandoned. Windows function calls are riddled with special-case code for different applications. For example, PeekMessage checks to see how often it was called in the last second and whether the calling application was PowerPoint.
Windows XP includes an Application Compatibility Layer, which modifies the behavior of Win32 calls based on the name of the executable. Supposedly, if the Windows calculator was renamed from calc.exe to armymen.exe (or some similar sounding name that Jeffrey Richter), Windows changes to 640x480 mode and disables Alt-Tab. Win32 is too stuck with the past to move forward in a compelling way.
I actually think much of the migration away from Microsoft is attributed to the difficulty of developing and deploying applications for Windows; if developers were so concerned with Microsoft maintaining compatibility with older platforms, I don't see why they would make a leap to a radically different and incompatible environment like Java. Microsoft's compatibility story isn't very bad; Microsoft's problem was ease of development.
As for Joel's comment that Longhorn's changes are not impressive, it's too early to talk to about the compellingness of Longhorn, since the latest bits released include neither the desktop composition engine nor the Longhorn user experience (Aero).