最近從架構的角度做了一個 Windows 8 下 Metro Style 應用程序開發介紹的講座。以下是講稿。
如有問題歡迎指正。
下載地址：
1 概述
這篇的標題叫做Windows RT Introduction而非Windows 8 Introduction是想強調此次介紹是從開發人員的角度而不是普通用戶的角度出發的。同時，我們關注的是Metro Style應用而不是傳統的Win32應用程序的開發。
實際上，使用C#或者HTML + Javascript書寫一個Hello world應用的代碼例子已經在網上泛濫了。但是僅有一個Hello world并不能夠說你掌握了Win RT的開發。從Pro的角度來說我們應該弄清楚整件事情的細節。那么首先就應當是他的架構。這樣寫起程序來才能心定。
2 Windows 8 Metro與Desktop模式
2.1 兩種模式
Windows 8的應用程序顯示模式目前有兩種，定義在METRO_MONITOR_MODE中：即傳統的桌面模式（MMM_Desktop）以及Metro模式（MMM_Metro）。如果你是Windows Phone用戶的話可能就會對Metro比較熟悉。事實上，微軟在2009年啟動Windows 8的研發工作時目標是創造一個完全不同以往的操作系統，完全不以之前的操作系統為藍本。而后發現Desktop應用是不可或缺的部分而將兩個部分進行合并。一開始用可能會有些別扭，但是我估計開發人員半天之內就能夠熟練使用這個系統了。
2.2 Metro和Desktop的一些不同
既然有兩種模式那么我們自然就會關注他們的不同點。這個問題應該從架構圖上做一下說明但是我們可以先有一些直觀的認識。
2.2.1 Message Loop
消息處理的編程是傳統Desktop應用程序的重要部分。你需要書寫維護Message Loop的代碼。例如：在WinMain調用（或者其子例程中）你需要書寫類似
|
while (::GetMessage(&message, NULL, 0, 0)) {
::TranslateMessage(&message);
::DispatchMessage(&message);
} |
而在Window創建之前候你一定指定了
|
WNDCLASS wndClass;
// ...
wndClass.lpfnWndProc = WndProc; |
這樣你就可以在WndProc函數中決定特定message的流向了。對于繪圖來說，你一定是接受了WM_PAINT消息，然后執行了區域重繪。
但在Metro App中這些都已經隱藏了，而且消息的細節也可能發生了變化。Metro App中你看不到消息循環。一切關于界面消息的分發都隱藏在了CoreDispatcher中。因此如果你用Spy++去試探Metro App的消息循環那么你什么都抓不到。
2.2.2 Display
在傳統的Desktop應用程序中，繪圖可能通過GDI，GDI+，DirectDraw，DirectX進行。同樣通過捕獲WM_PAINT消息或者當系統處于IDLE的時候進行繪圖（對于游戲編程來說）。
而Metro App不會再支持GDI和GDI+，在Metro App中繪圖只能通過DirectX來進行。確切的說是Direct3D和新公布的Direct2D、Direct Write API。因此Metro應用的所有繪圖都是希望是硬件加速的。這種繪圖更高效，解放CPU，而且一般不需要處理復雜的Dirty Region Repaint。
2.2.3 Life Cycle
Metro App并沒有關閉窗口這種按鈕。其生命周期是由系統托管的。系統會決定僅僅是掛起應用執行還是需要完全銷毀應用進程。這和一般意義上的Desktop應用程序不一樣。（當然，你也可以使用Alt+F4顯示的結束Metro App的執行）。
2.2.4 Share & Communication
傳統的桌面應用程序有多種手段進行公共組建的公用或IPC。但是在Metro App中，隔離是一個很重要的概念，應用的可執行部分，運行庫，Isolated Storage都是獨立的，不能夠共用。同樣，不能夠使用傳統的IPC機制。應用程序的互動僅僅可以通過內置的Contracts進行，關于這一部分內容可以查看MSDN：
http://msdn.microsoft.com/en-us/library/windows/apps/hh464906.aspx
2.2.5 Portability
傳統的Desktop應用程序的支持大多為x86/64架構的處理器。由于Metro環境可以完整運行在ARM處理器上是一個重要的特性，因此Metro App可以運行在ARM處理器上，即同時部署在PC和移動設備上。
2.2.6 OS Access
當然為了Portability的要求，必然要求應用不能夠越過Win RT的抽象，因此Metro是不能像Desktop App那樣訪問所有的Windows API的。
3 從Windows 8 API的架構圖看Windows RT
我們對Windows RT的介紹都將圍繞著這個圖展開。
在這個圖中，最底層的是NT的內核；在其上是Windows子系統。實際上NT至少有三個子系統，Windows子系統，POSIX子系統（Unix）和OS/2子系統。POSIX子系統和OS/2子系統實際還是在使用Windows子系統。 在Windows子系統上劃分了不同的運行時（橙色）和程序庫（淺藍色），最上面的綠色是我們使用的各種開發語言。
這個架構圖實際上說明了一切。并且消除了很多誤解：
（1） 第一個誤解是INFOQ指出的Windows RT和Win32是完全分開的。這源于微軟發布的一幅飽受批評的架構圖，在那張架構圖中，Windows RT和Windows子系統竟然是并排排列的。這是很荒謬的，Windows RT實際上基于Windows子系統。首先Windows RT完全基于COM；其次Windows RT利用了一部分現有的Win32 API；其余的部分Windows RT則直接訪問NT內核。
（2） 第二個誤解是C++/CX。C++/CX是微軟推薦的開發Windows RT的方式。他主要隱藏了COM的復雜性。關于這個問題我們后續會有說明。這個誤解是C++/CX實際就是C++ CLI。實際上這是兩個完全不同的東西，C++ CLI是運行在托管環境下的，而C++/CX完全是Native的。
3.1 Windows RT僅用于Metro應用
從架構圖中可以看出，Win RT僅僅用于Metro應用。并秉承了我們剛才介紹的，簡單部署，沒有共享的組件，沒有IPC，等等。
3.2 Windows RT構建與COM之上
這也是為什么說Windows RT是構建與Win32之上，因為COM是Win32重要的組成部分。這意味著：
（1） 你可以用之前所有的消費COM的方式來使用Windows RT，你可以用C，你可以用ATL或者新的WRL；
（2） WRL完全符合傳統的C++語法，這意味著你可以使用不同的編譯器（例如Intel C++編譯器）來構建Metro應用。但是微軟顯然希望大家都來使用C++/CX，WRL的文檔跟沒有差不多，現在也看不到一個完整的例子出現。
3.3 Windows RT限制了系統API的調用
Win RT是基于COM的，但是COM僅僅是一個二進制協議而已。在COM Interface實現中從技術上講還是在調用Win32 API。但由于前面介紹的Win RT的設計要求，系統API的調用需要受到嚴格的限制。僅僅支持有限的API調用，因此在你希望使用一個Win32 API時，一定要查詢MSDN上的Applied To一節，看看是否是Metro Style App | desktop App。
同樣的道理，.NET的某些方法也在進行著系統調用，因此在使用.NET開發Metro Style應用程序的時候也并不是所有的程序集都能夠支持。當然，如果使用P-Invoke的方式調用Win32 API那么危險性就會更大。
總之，在Metro應用中調用不支持的Win32 API會有如下的后果：
（1） 發生一個Runtime Exception；
（2） 應用程序失去響應，尤其是在使用和消息循環相關的代碼時。例如對Metro App進程使用WaitForSingleObject(hProcess)。
（3） 調用成功，但是你的Metro App應用會被Windows Store駁回。
按照上述分析，那么即使你存在相當可觀的COM代碼庫，也需要巨大的努力才能夠保證他們在Metro App上正確運行（消除非法的系統調用）。對于新的應用來說，為了避免書寫大量的COM開發代碼，最好使用C++/CX進行開發了。
3.4 C++/CX
為什么會有C++/CX呢？這可以聯想n年前我們為了避免C++開發COM的冗長的代碼，轉而使用C開發關鍵程序，而使用Visual Basic創建COM組件。現在時間到了2012年，VB6已經不在考慮范圍之內了，于是C++/CX取代了他的位置。
C++/CX是Native的，但是它的語法為什么能夠和C++ CLI保持近乎一致呢？這是因為Win RT本身雖然是Native的，但它以.NET兼容的方式暴露了元數據。但是我們在編程中要時刻想到，我們在操作實打實的Native對象。根本沒有什么垃圾收集器在幫助我們。
那么為什么不單純使用.NET開發Metro App呢？這是因為對于移動設備來說，CPU的速度和電池是兩大局限，因此在近一年，Go Native的大潮終于襲來。目前：
（1） iOS使用Objective-C進行程序開發，而且在移動設備上也是沒有垃圾收集器的，需要手動釋放使用的內存；
（2） Android一開始使用Java進行開發，但是在糟糕的性能和社區的強大壓力下，終于開放了C/C++開發接口；
（3） WP7/8也出現了類似Android的情況。
目前客戶端應用向更薄（核心應用向服務器移動），更快（運行速度快，耗電小），交互更豐富（沒有動畫你都對不起觀眾）的方向發展。因此開放Native接口是大勢所趨，C/C++順理成章的在Windows 8強勢回歸了。
但是，用.NET開發Metro應用也是一個不錯的選擇，尤其你的應用沒有密集的運算（游戲）的情況下。你可以參考幻燈片中的Cheat Sheet。