2011年，Silverlight刚开始有蓬勃发展的起色，不利的传言就开始大量流传。不安的Silverlight开发者们要求微软澄清，但得到的只是沉默。终于随着微软在BUILD上亮相Window 8以及新的API WinRT，开发者们意识到，Silverlight的故事结束了。尽管微软在年底如期发布了大幅改进的Silverlight 5，但大势已去，微软甚至都没怎么宣传。随后传闻Silverlight的开发团队大部分转移到了Windows Azure项目。那么，Silverlight何以失宠呢？
作为免费的开发工具，Silverlight是不产生直接利润的。开发工具的主要用途在于推进平台的市场占有率，对微软来说，就是最赚钱的Windows系统。但跨平台的Silverlight，并不能为已经占有大部分市场的Windows作出贡献，反而为其它系统提供了优质的开发工具和大量的Windows程序员，以及移植的Windows程序。这导致它反而削弱了Windows的盈利能力。因为在有良好的跨平台开发工具的条件下，操作系统的重要性大大降低，不管什么系统，只要能支持用户需要的应用程序就可以了。
Silverlight的本来意图是夺取Flash的Web平台，可不但这一点没有成功，反而由于早期的大力投入，反而抢了WPF的用户群。想想看，尽管功能比WPF少一点，但Silverlight可是跨平台的，可以轻易地把业务拓展到非Windows平台，何乐而不为呢？而对微软来说，付出了双倍的努力，却没能抢到多少Flash的市场，反而分散了自己的用户。之后，Apple在iPad上封禁Flash，同时也注定了Silverlight的跨平台战略已经成为不可能完成的任务。
如此，Silverlight已成鸡肋。但至少还能在Windows Phone 7上，作为首选的开发工具，最后闪耀一次。
至于Windows 8、WinRT和Windows Store，和Apple对比一下就能看出其基本对应iOS、Cocoa和AppStore。传闻中，鲍尔默对Apple产品推崇至极，以至和不少其它高管意见不合，内部人事变动频频。其实当今复制Apple模式的公司为数不少，而且微软旗下的XBox部门早已通过XNA MarketPlace实践多年。尤其Apple绝对强势的私有平台、私有API策略不但没有招致批评，反而好评如潮，也大大刺激了微软蠢蠢欲动、想要重回平台锁定战略的心。
那么，为什么不为平板设备、手机等专门做一个系统，而偏偏要把桌面平台的Windows改成两用的呢？作为一个大企业的战略，必然是以3到5年的长期规划，以电子设备的发展速度，那时平板、手持设备的计算能力将超越目前的桌面电脑，不可避免地将具有当前桌面电脑的功能，两者融合是早晚的事。即使今天，高端平板同样可以具有等同桌面电脑的计算能力，而且微软看中的主要市场，恰恰是企业商用平板。事实上，在iPad面世前两年，微软就已经制作了叫做Surface的多点触控平板设备，但因为造价昂贵、体积过大，实在难以商业化；但使用XP系统的上网本却卖得火热。
另一方面，推出一个全新的系统的需要其他厂商的配合、消化和大力推广，难度和所需时间远在推出一个大家所熟悉的系统的改进版之上。之前的Windows CE, Windows Embedded, Windows Phone也并不算顺利。在Windows系统垄断地位受到威胁的局面下，与其分化自己的产品线，自己和自己竞争，不如集中资源办大事。
但这个选择也有明显的不利因素，就是难以在功耗和电池续航时间上和专为平板设计的iOS匹敌。
这次大变动也提供了一次彻底革新Windows API的机会。对于未来的API应该是Native的还是Managed，这个争议自微软开发Vista时就存在。最终，WinRT是基于改版后的COM的native代码，但引入了大量.NET的对象模型概念，甚至完全重用的了.NET的元数据格式，重写了WPF。从微软的角度来讲，他们终于可以用一套API来服务所有的编程语言了。
但从各个编程语言的角度，却让完美主义的开发人员很纠结。对C++程序员而言，很少有人认为写COM程序很幸福，所以VC里添加了叫做C++/CX的语言扩展，结果C++用户们愤怒了。之前已经有了Managed C++和C++/CLI，这回是C++/CX，下次是什么呢？为什么不能简单地提供个C++的API呢？对.NET程序员而言，尽管WinRT的界面API和WPF很相似，但不再是原生的.NET对象，多了些转换，而且WinRT对象的内存管理模式是引用计数而不是垃圾回收，必须小心环形引用了。微软在BUILD上确实曾经宣称.NET程序不用再为包装native API费心了。但事实上，并不是所有的API都由WinRT提供，比如DirectX 11仍然是基于传统COM的，甚至还有一些Win32 API。
http://blog.csdn.net/nightmare/article/details/7226678