I agree with you about their ridiculous amounts of API churn. I think it happens for (IMHO) two main reasons: 1. MS wanted to keep Windows APIs growing quickly

I agree with you about their ridiculous amounts of API churn. I think it happens for (IMHO) two main reasons: 1. MS wanted to keep Windows APIs growing quickly to keep anyone from making a compatible platform. I can't imagine how many $B a year it costs to maintain that. This is probably less of a goal than it used to be, as the baseline Windows install is now so many GB that it's an impediment for the nimble VMs and ultra-portable clients that are the future. 2. MS seems to pitch to (and staff from) a young audience, folks in school and moving to the workplace as application software developers. This crowd has a natural turnover period of only a few years. But one thing they really are quite good at is supporting stuff for a long time. You can today build an app with .Net framework 2.0 with VS 2005 and it will install and run about as well as it ever did. For native code compatibility typically goes all the way back to Win95 apps. When old apps don't work it's usually a result of unambiguous security or stability improvements made to the OS. Even then Windows often provides virtualized registry and filesystem areas that trick the apps into working.