WinRT开发系列之基础概念：WinRT不是……

不觉中有两年没有发新博客，主要是项目重心从Win转向Web开发，虽然Web中HTML5也有很多点可以分享，但是总是抵不住懒惰，偶得的一点点心得，weibo一条就过去了。

恰逢进来微软在WinRT上发力，GrapeCity PowerTools也在WinRT上做了一些尝试，作为前期调研的先导部队，我从中还是学到很多，如今，GrapeCity PowerTools的第一个WinRT控件产品业已发布（从这里传送，或者尝试Store上的Demo App），感触颇深，整理了一下，觉得应该共享一些出来，促进学习吧。

 对于WinRT开发，微软坚持了.NET保持的一贯的风格，对于多编程语言的支持做的非常到位，无论你是C#/VB还是C++，甚至JavaScript，都有自己的定位；这也给很多人带来了诸多模糊不清的概念！这里就列举几个WinRT开发过程中的首先需要明确的点。

1. WinRT不是.NET，也不是.NET子集。
   这个也是所有.NET程序员最迷惑的一点，甚至很多微软讲师也对此语焉不详；从他们唯一肯定的是你可以使用.NET技术和语言来开发WinRT应用。事实上，WinRT是微软为Metro style app开发的全新框架。在这套框架里，以面向对象的方式重新封装了所涉及的所有系统服务，在此基础上提供了很多其他辅助类库，而以上内容都是Native实现，通过Projections给不同的编程语言和方法来提供一致的调用和类似的体验。
   这里我借用微软TechED中的一张Window 8平台和工具的图，修改了一下，标注了Projections层。
   
   在这些编程语言中，可以选择C++直接编译Native的WinRT组件，扩展WinRT的功能，这也是最高效的；当然，也可以选择C#/VB来实现对WinRT的扩展，但是运行时需要额外通过Projection来和WinRT交互，第一次执行会有一些损耗；而其中JavaScript是无法直接扩展WinRT组件的，但是有了它，就可以很容易的把Web应用快速的迁移到WinRT上来。（计划在稍后的系列里详细剖析WinRT各种编程语言的优缺点，敬请期待）
   
2. WinRT不是基于Win32编程接口的。
   WinRT是设计用来代替Win32编程接口的，如上面所述，WinRT是一个全新的框架，编程模型也是全新的，无法直接把以前的基于Win32开发的应用直接运行到WinRT之上。当然，Win32依然存在，所有基于Win32编写的应用依然可以运行，但是不能充分利用WinRT的很多特性。
   另外，WinRT的设计重点是高可用的用户响应，如果操作耗时，需要设计成异步的，以防止应用被阻塞，造成界面卡死。对于文件系统、网络请求等耗时操作和服务，WinRT均已经默认移除了同步方法，全部改成了异步方式。
3. WinRT不是.NET下一代。
   WinRT和.NET之间没有必然的替代关系，WinRT设计用来替代Win32，.NET技术依然可以在WinRT平台使用。

　　还有很多这样的“不是”系列点，我先抛出几块“砖”，希望引起大家讨论，引出来一些“美玉”吧