[mwcampbell]

On the contrary, the Windows API has endured through some pretty big changes, e.g. from 16-bit to 32-bit and then 64-bit, and from a cooperative single-address-space system to preemptive multitasking with memory protection between processes. (I was surprised that each application had its own message pump even in the cooperative multitasking days.) In what ways do you think the Windows developers' hands were tied by the need for backward compatibility?

Seeing how similar the Windows 1.0 API was to the current Windows APi for desktop apps, I'm actually sad that Microsoft decided to (mostly) abandon that legacy for the new "modern" Windows apps under Windows 8 and Windows Phone 8.1. There's no reason why the classic Windows API couldn't have been adapted for these new-style immersive apps running inside sandboxed containers. But I guess the Windows API gained too much of a reputation for being old, crufty, ugly, and unapproachable for new developers; that's certainly how I saw it when I got my first copy of Visual C++ in 1998. But now I wish Microsoft hadn't responded to that perception by abandoning that API, which has now evolved for decades.

[gecko]

I doubt he meant that third-party developers' hands were tied. I think he means that Microsoft spent incredible resources on backwards compatibility at the expense of innovation. To take the most extreme example I can think of: going from OS 9 to OS X, Apple preserved a (comparatively) handful of APIs as-was, another pile as nearly-the-same-but-requires-modification, and regardless of which they temporarily preserved, made it very clear that you were going to completely rewrite your application if you intended to have a genuinely native OS X experience. By contrast, farking Microsoft OS/2 apps survived into Windows NT 4, and Windows 3.1 apps ran from 1993 through some forms of Windows XP without blinking. Even in the hated Windows 8, Microsoft went out of their way to make sure that they maintained very clear and well-spelled-out migration paths. It is theoretically possible (though you'd be insane) to write a WinRT app in C that mostly uses kernel32.dll, if you want to, because WinRT is unapologetically based on COM, which is in turn based on an old way that vtables happened to be laid out in VC++, which is in turn based on how C structs used to lay out function pointers. This hurts WinRT performance compared to what they could've accomplished with a Swift-like linker.

Did this insane focus on backwards compatibility hurt Microsoft? I don't think you can conclusively say. Did it hurt me as a former Windows developer? Only at best tangentially; all the backwards compatibility crap is pretty abstracted from you if you hang out in .NET land. (Except when it isn't.[1]) And at any rate, I don't think the bleed-through is noticeably worse than e.g. POSIX intrinsics showing up in OS X. But I think the argument that the engineering required to ensure Windows maintained such a strong backwards compatible stance ate out of resources that could've kept Windows more up-to-date has a point.

[1]: http://bitquabit.com/post/zombie-operating-systems-and-aspne...

[whoopdedo]

Needing to maintain compatibility certainly prevented Microsoft from fixing prevalent bugs. The C runtime remained non-POSIX compliant for a very long time because applications were written to expect the incorrect behavior. Some of those bugs led to security holes that were exploited, yet couldn't be patched for fear of breaking third-party software. That's how we end up with redistributable runtimes as applications were told not to depend on the out-of-date system libraries.