WinRT 不是另一個抽象層；它就像 Win32 API 一樣，直接駐留在內(nèi)核之上。自從 1993 年 Win32 伴隨 Windows NT 被引入以來，這標(biāo)志著對于 Windows 核心的首次重大突破。WinRT 與 Win32 截然不同，它代表了新的語義學(xué)應(yīng)用程序執(zhí)行環(huán)境。

　　不像 Win32 是用C語言思想設(shè)計的，而 WinRT API 是用 C++ 編寫的，并且從一開始的設(shè)計就是面向?qū)ο蟮摹Ｒ恢滦浴⒁子眯浴⒁约靶阅芏际切碌倪\行時 API 的重要方面。WinRT API 中的每個對象都支持反射，以便甚至連諸如 JavaScript 等動態(tài)語言都可有效地使用它們。隨之而來還有統(tǒng)一對象模型，這對于基于庫的 C++ 而言是個稀罕物。

　　附注：Win32 API 并未被移除，而且那些使用傳統(tǒng)應(yīng)用程序執(zhí)行環(huán)境的較早的應(yīng)用程序?qū)⒗^續(xù)按預(yù)期方式工作。

　　C++開發(fā)

　　在 C++ 中編寫用戶界面將首選 XAML。所有與 XAML 一起使用的庫都已被移植到C++，并且被編譯為本地 x86 版本。使用 XAML 和 C++ 編寫的 Metro 風(fēng)格應(yīng)用程序并不運行在 .NET 之上，它們就像其他任何 Visual C++ 應(yīng)用程序一樣，被直接編譯為 x86 版本。

　　調(diào)用 UI 控件的方法就像在 C++ 中調(diào)用任何其他對象的方法一樣。在機器碼級別上，某個指令將 this 指針推送到堆棧上，然后通過虛函數(shù)表（v-table）調(diào)用相應(yīng)函數(shù)。這使得即使在低功耗設(shè)備上也能達到最優(yōu)的性能。

　　支持一些現(xiàn)代的 C++ 應(yīng)用程序所用的庫，例如 Boost。

　　重疊窗口不復(fù)存在

　　對話框是來自上一版 Windows 的核心概念，而在 WinRT 中它將不復(fù)存在。對于微軟而言，性能成本和可用性問題已不再是理所當(dāng)然的。希望使用這種模式的應(yīng)用程序?qū)⒁_發(fā)其他的方式來傳遞信息，例如消息框的方式。

　　另一并未納入 WinRT 的庫是 GDI。如果某個應(yīng)用程序要使用 Metro 風(fēng)格界面，那么它需要按自上而下的方式來做，將 Metro 風(fēng)格與經(jīng)典用戶界面相混合的情況是不可能出現(xiàn)的。

　　PlayTo 契約

　　另一被公開的契約是 PlayTo（由……發(fā)揮）。這使得應(yīng)用程序可發(fā)送如音頻及視頻等媒體文件到某個 charm^[1]。然后那個 charm 將允許用戶選擇某個他們想用的應(yīng)用程序來查看該文件。據(jù)推測，媒體文件不僅限于物理文件，而是任何可表示為數(shù)據(jù)流的媒體形式。

　　C#/VB：平臺調(diào)用（P/Invoke）之終結(jié)

　　從 .NET 中調(diào)用本地函數(shù)通常涉及建立結(jié)構(gòu)和操縱指針。而在 WinRT 環(huán)境下，所有的 API 被公開為許多可通過 C# 及 VB 直接使用的對象。這把 .NET 開發(fā)者置于與 C++ 開發(fā)者平等的層面上。

　　應(yīng)用程序的響應(yīng)速度對于微軟而言是非常重要的。所有耗時超過 50 毫秒的操作系統(tǒng)級別的 API 調(diào)用將被公開為異步操作，正是為了向開發(fā)者傳遞這種價值觀。

　　JavaScript

　　對于 Windows 8 而言，第四大語言就是 JavaScript。盡管它不使用 XAML，但它就像本地及 .NET 應(yīng)用程序一樣，擁有對底層 WinRT API 的直接訪問權(quán)。這不僅是個像 PhoneGap 一樣的容器，JavaScript 開發(fā)者還可獲得與其他開發(fā)者所使用的同樣豐富的 API。

　　由于是 JavaScript，因此所選擇的 UI 工具包是 HTML 和 CSS 而非 XAML。IE 10 及 Metro 風(fēng)格的 JavaScript 應(yīng)用程序使用的是同一渲染引擎，盡管那些應(yīng)用程序?qū)嶋H并不運行在瀏覽器中。JavaScript 應(yīng)用程序看起來就像任何其他 Metro 風(fēng)格應(yīng)用程序一樣。

　　JavaScript 中的用戶控件幾乎與 C++ 及 .NET 中的控件不相上下。有些控件對于 HTML 渲染引擎而言是固有的，而另外一些控件則是用 JavaScript 編寫的。這些基于 JavaScript 的控件都是基于 div 的，非常像那些使用 jQuery 創(chuàng)建的控件。

　　應(yīng)用程序容器和應(yīng)用程序權(quán)限

　　Metro 風(fēng)格應(yīng)用程序運行在被稱為“應(yīng)用程序容器”（app container）的環(huán)境中。這似乎取代了由基于 Win32 應(yīng)用程序所使用的窗體環(huán)境。

　　大多數(shù) API 調(diào)用被直接發(fā)送給底層內(nèi)核。然而，有些調(diào)用將被通過系統(tǒng)代理（system broker）路由。系統(tǒng)代理確保應(yīng)用程序只能訪問那些經(jīng)用戶已批準(zhǔn)的功能。例如，當(dāng)某個應(yīng)用程序首次嘗試訪問攝像頭時，服務(wù)代理（service broker）將提示用戶以獲取他們的批準(zhǔn)。應(yīng)用程序必須包括一份清單，其中注明該應(yīng)用程序可能需要的所有限制服務(wù)。這種模式對于移動設(shè)備開發(fā)者而言將是非常熟悉的。

　　所有 Metro 風(fēng)格應(yīng)用程序都會運行在 WinRT 的應(yīng)用程序容器中，而且會受到系統(tǒng)代理的監(jiān)控，甚至連那些用 C++ 編寫的應(yīng)用程序也不例外。該思想是為了限制應(yīng)用程序破壞系統(tǒng)的能力。雖然也許并不是不可能的，但是在 WinRT 下創(chuàng)建惡意軟件與在 Win32 中相比將會難得多。

　　所有 Metro 風(fēng)格應(yīng)用程序必須進行數(shù)字簽名

　　不允許匿名應(yīng)用程序。應(yīng)用程序為了測試可進行自簽名，但是當(dāng)它們出現(xiàn)在應(yīng)用商店里時，它們就必須使用真實證書進行簽名。

　　譯注

　　[1] charm，微軟已將“CHARM”注冊為計算機、軟件產(chǎn)品、電氣和科學(xué)產(chǎn)品類商標(biāo)。微軟將 CHARM 描述為計算機程序、圖形用戶界面軟件和操作系統(tǒng)程序。在觸摸版 Windows 8 中，charms 在屏幕右側(cè)；在傳統(tǒng)版（使用鼠標(biāo)和鍵盤）Windows 8 中，charms 出現(xiàn)在屏幕左側(cè)。charms 包括：Search（搜索）、Share（分享）、Start（開始）、Devices（設(shè)備）、Settings（設(shè)置）。詳見微軟申請 Windows 8 功能 charm 注冊商標(biāo)（圖）。

　　作者：Jonathan Allen 譯者：高翌翔

　　查看英文原文：WinRT: An Object Orientated Replacement for Win32 

　　相關(guān)博客文章：Windows Runtime(WinRT) 揭秘

NET技術(shù)：WinRT：Win32的面向?qū)ο筇娲?/a>，轉(zhuǎn)載需保留來源！