Building Windows 研討會除了將 Windows 8 帶向廣大的開發人員面前外，似乎對於長久在微軟陣營中的開發人員來說，也許也多了一份恐懼感，又或是多了一個新玩意，這個玩意就是 Windows 執行期函式庫 (Runtime Library)，為什麼說會有這種感覺呢？且待內文分解 ...。
Building Windows 研討會除了將 Windows 8 帶向廣大的開發人員面前外，似乎對於長久在微軟陣營中的開發人員來說，也許也多了一份恐懼感，又或是多了一個新玩意，這個玩意就是 Windows 執行期函式庫 (Runtime Library)，為什麼說會有這種感覺呢？且待內文分解 ...。
Windows 上的開發框架發展歷程
我們由 Windows 95 和 NT 來說起就好了，大家都知道 Windows 95 和 NT 是 32 位元的作業系統，而給應用程式開發的介面 (API) 又稱為 Win32 API，它是一個給 C/C++ 開發人員的原生 (native) API，與作業系統層次直接溝通，其他的語言如果想要存取 Win32 API，就要透過特別的方式來存取，以 Visual Basic 6 來說，要先用 Declare 宣告 Win32 API 的原型，這樣的 API 親和性很差，其他的程式語言幾乎不太能呼叫，就連為 scripting 或 Office 應用程式所設計的 COM 架構也是一樣，最早也是只能給 C++ 開發人員使用 (原生的介面只有 IUnknown 和 COM Client Library，IDispatch 介面是後面才加的)，後來隨著 VB 和 scripting 這類的語言快速發展，Windows 上的 API 才開始有質性的變化，開始提供了 Win32 和 COM 雙介面，甚至更新的服務 (ex: Active Directory) 只提供了 COM 的介面，這時 C/C++ 和 VB 這類 RAD 開發工具的生產力整個顛倒過來，VB (or Delphi 等) 變成快速應用程式開發的首選，而 C/C++ 則是低階與高效能應用程式開發的首選，最重視高效能的遊戲應用程式開發的核心函式庫 DirectX，也是到了 9.0 才開始有 Managed DirectX Library 的出現，但當時 .NET Framework 已發展到 2.0。
在 COM 和 Win32 API 並存一段時間過後，微軟開始發展 .NET Framework 與 .NET 策略，.NET Framework 成為封裝 Win32 API 的一種物件導向類別庫，而和 COM 則是保持並存與可相互溝通的相容性，沒被封裝的 Win32 API 也可以透過 P/Invoke Service 來橋接呼叫，對 .NET 開發人員來說可是個重要的里程碑，因為不用再使用複雜的 Win32 API 和麻煩的 COM 呼叫才能達成應用程式的開發工作，尤其是處理像 Office 應用程式開發這類的發展工作時。這幾年來，.NET Framework 不但快速發展成與 Win32 API 勢均力敵的大型核心類別庫，同時也成為許多新興平台的標竿實作，像是 Silverlight 以及 Compact Framework 等重要的平台，Windows Phone 7 與最新的 Mango (v7.5) 手機的核心則是 Silverlight，連 XNA Framework 也是基於 .NET Framework 的精神來開發的，物件導向開發方法早已取代傳統 C/C++ 開發 Windows 應用程式的方式，不過在轉換的過程中，許多原本寫 Windows 應用程式的 VB6, C++ 等開發人員也吃了不少的苦頭。
不知還有多少人記得 WinFX 這個名詞，當初在 WPF, WCF 和 WF 發展之時，微軟使用的就是 WinFX 來代稱，但卻沒有成功的在作業系統世代交替時取代 Win32 API，反而被稱為 .NET Framework 3.5，讓多數開發人員稍微鬆了一口氣。但如今在 Windows 8 中，我們可能又要再次經歷這個轉換的過程，因為在 Windows 8 中又多了一種應用程式類型：Windows 8-style application，這個源自 Windows Phone 7 的應用程式類型，未來在使用者的桌面也看的到了，當然在 Windows Phone 7 上的使用者介面特色，也將會移到桌面應用程式中，Windows 8-style application 又比傳統的 .NET Framework 更加輕量與支援更多開發的語言，連 JavaScript 都可以用來開發 Windows 8-style application，要有如此大的相容性，Windows 核心中提供給應用程式開發的介面就要再次改寫，這也就是為什麼會有 Windows Runtime Library 的原因。
Windows Runtime Library 概觀
Windows Runtime Library (Windows RT, WRT) 簡單來說，其實是給 Windows 8-style application 使用的 Windows API，就像 .NET Framework 是給 .NET 應用程式用的 Windows API 一樣，WRT 封裝了 Windows API，並顯露了相關的物件和類別給 Windows 8-style application 的程式語言使用，而其中最令人關注的是 JavaScript，雖然以前在 Windows 2000 時，就有一個被稱為 HTML application 的應用程式類型，但 HTML application 是封裝在瀏覽器沙箱內的應用程式，它只能活在瀏覽器的行程內，而不能存取作業系統的資源，但是在 WRT 中，JavaScript 除了得到 HTML5 和 CSS3 的奧援外，更得到了 WRT 的全力支持，讓 JavaScript 真的可以用來開發純 Windows 應用程式了，不像 HTML application 只是個包在沙箱內的玩具而已。
在 WRT 中，Windows 的資源被封裝到不同的類別庫物件，並以 Windows.* 命名空間為主，開發人員只要在程式中使用 Windows.* 命名空間，即可取用 Windows 8 中的各類物件，當然 Visual Studio 一樣提供了 Intellisense 的能力：
這樣的特性一樣可以在 C# 和 VB 中使用，所以等於 HTML 和 Web Designer 也可以進軍 Windows 8 應用程式的開發行列，這對 Web Designer 和 Developer 而言等於是將他們的工作範圍延伸到桌面應用程式上，讓原本的技能可以得到更大範圍的應用。
每個 WRT 的物件中都會實作一個系統級的物件 (不過雖然看起來是 COM 物件，但它不是真正的 COM 介面，也無法使用 COM Client Library 操作)，這個物件除了 IUnkown 介面以外，還多了一個叫做 IInspectable 的介面，這個介面內含了 GetIids(), GetRuntimeClassName() 以及 GetTrustLevel() 三個方法，分別可取得物件可操作的介面，類別名稱以及信任層次的資訊，所有可供非 C/C++ 使用的物件都要實作這個介面，就像要實作 IDispatch 介面一樣。
而 Windows 8 的應用程式在存取 Windows (或特別為 Windows 8 開發的) 物件時，作業系統會用投影 (Projection) 的方式，讓不同的開發平台可以存取元件中的介面：
投影功能是植基於 Windows Metadata 的功能，元件可以在程式中登錄元件介面適用的平台 (for native, for CLR or for scripting)，WRT 會自動在元件活化時對應到不同的介面。
WRT 為了要保持不同應用程式間資料格式的相容性，因此特別定義了幾組新的型別如下圖，包含了一個新的 HSTRING 型別，以及泛型介面和執行期類別等：
同樣的，在內建的集合物件上也有所改變，陣列會以向量 (Vector) 來替代，而集合則是用 Map 來替代，在 Silverlight 中被廣為應用的重量級 ObservableCollection 也被納入了標準集合中。
Windows Runtime Library 的物件活化過程 (object activation process)
WRT 的物件活化過程如下圖：
在 Windows 8 中的重要殼層 explorer.exe 中內含了 activation system，它會在應用程式部署時讀入 application manifest 資料檔，並查詢物件的 Registration (於 Class Catalog 與 Extension Catalog)，以得到操作它的介面：
explorer.exe 還會於查詢完成後將應用程式登錄到 RPCSS 服務以啟動應用程式，而 RPCSS 會搜尋在應用程式中內含的 Core Application Object 進入點 (也就是 main() )，並啟動應用程式本體，在應用程式與物件交換訊息時，explorer.exe 和 RPCSS 也會扮演訊息分派的角色。
應用程式內的元件與程式互動則是透過介面呼叫方式處理，而為了要做到一些非同步的工作，元件的程式會被移至不同的 thread 中執行，剛好可以與 .NET Framework 4.5 中將推出的 async 與 await 架構相呼應：
Windows Runtime Library 中的使用者介面元素
在 WRT 中內建的都是對 Windows 8-style application 開發的支援，所以可用的控制項與使用者介面，都是以 Windows 8-style application 為主：
當然，基本的 Databinding 和使用者介面導覽系統一樣都不缺，但那些可以講一個主題了。目前可以看出來的是，XAML 在 Windows 8-style application 仍然是要角，但如果用的是 JavaScript，那麼 data-binding 機制則會很像 AJAX 的 client template：
沒有完結
Windows 8 的 WRT 是一個蠻複雜的東西，可以和 .NET Framework 相提並論，而且 Windows 8-style application 的開發也是一個很大的學問，本篇文章只是當一個研究 Windows 8-style application 開發的起頭而已，未來當技術愈來愈明朗時，我們會看到更多技術的文件以及範例，而筆者也會持續追蹤這個技術的發展，因為它也許在 12 個月內就會成為我們生活中的一部份。
Reference:
Building Windows Conference Slides