不覺中有兩年沒有發新博客，主要是項目重心從Win轉向Web開發，雖然Web中HTML5也有很多點可以分享，但是總是抵不住懶惰，偶得的一點點心得，weibo一條就過去了。
恰逢進來微軟在WinRT上發力，GrapeCity PowerTools也在WinRT上做了一些嘗試，作為前期調研的先導部隊，我從中還是學到很多，如今，GrapeCity PowerTools的第一個WinRT控件產品業已發布（從這里傳送，或者嘗試Store上的Demo App），感觸頗深，整理了一下，覺得應該共享一些出來，促進學習吧。
對於WinRT開發，微軟堅持了.NET保持的一貫的風格，對於多編程語言的支持做的非常到位，無論你是C#/VB還是C++，甚至JavaScript，都有自己的定位；這也給很多人帶來了諸多模糊不清的概念！這里就列舉幾個WinRT開發過程中的首先需要明確的點。
- 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各種編程語言的優缺點，敬請期待）
- WinRT不是基於Win32編程接口的。
WinRT是設計用來代替Win32編程接口的，如上面所述，WinRT是一個全新的框架，編程模型也是全新的，無法直接把以前的基於Win32開發的應用直接運行到WinRT之上。當然，Win32依然存在，所有基於Win32編寫的應用依然可以運行，但是不能充分利用WinRT的很多特性。
另外，WinRT的設計重點是高可用的用戶響應，如果操作耗時，需要設計成異步的，以防止應用被阻塞，造成界面卡死。對於文件系統、網絡請求等耗時操作和服務，WinRT均已經默認移除了同步方法，全部改成了異步方式。 - WinRT不是.NET下一代。
WinRT和.NET之間沒有必然的替代關系，WinRT設計用來替代Win32，.NET技術依然可以在WinRT平台使用。
還有很多這樣的“不是”系列點，我先拋出幾塊“磚”，希望引起大家討論，引出來一些“美玉”吧