Chinaunix首页 | 论坛 | 博客
  • 博客访问: 5223367
  • 博文数量: 1696
  • 博客积分: 10870
  • 博客等级: 上将
  • 技术积分: 18357
  • 用 户 组: 普通用户
  • 注册时间: 2007-03-30 15:16
文章分类
文章存档

2017年(1)

2016年(1)

2015年(1)

2013年(1)

2012年(43)

2011年(17)

2010年(828)

2009年(568)

2008年(185)

2007年(51)

分类: 嵌入式

2012-03-23 11:26:24

作者:小朱@台湾
 
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 中又多了一種應用程式類型:Metro-style application,這個源自 Windows Phone 7 的應用程式類型,未來在使用者的桌面也看的到了,當然在 Windows Phone 7 上的使用者介面特色,也將會移到桌面應用程式中,Metro-style application 又比傳統的 .NET Framework 更加輕量與支援更多開發的語言,連 JavaScript 都可以用來開發 Metro-style application,要有如此大的相容性,Windows 核心中提供給應用程式開發的介面就要再次改寫,這也就是為什麼會有 Windows Runtime Library 的原因。

Windows Runtime Library 概觀

image

Windows Runtime Library (Windows RT, WRT) 簡單來說,其實是給 Metro-style application 使用的 Windows API,就像 .NET Framework 是給 .NET 應用程式用的 Windows API 一樣,WRT 封裝了 Windows API,並顯露了相關的物件和類別給 Metro-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 的能力:

image

這樣的特性一樣可以在 C# 和 VB 中使用,所以等於 HTML 和 Web Designer 也可以進軍 Windows 8 應用程式的開發行列,這對 Web Designer 和 Developer 而言等於是將他們的工作範圍延伸到桌面應用程式上,讓原本的技能可以得到更大範圍的應用。

每個 WRT 的物件中都會實作一個系統級的物件 (不過雖然看起來是 COM 物件,但它不是真正的 COM 介面,也無法使用 COM Client Library 操作),這個物件除了 IUnkown 介面以外,還多了一個叫做 IInspectable 的介面,這個介面內含了 GetIids(), GetRuntimeClassName() 以及 GetTrustLevel() 三個方法,分別可取得物件可操作的介面,類別名稱以及信任層次的資訊,所有可供非 C/C++ 使用的物件都要實作這個介面,就像要實作 IDispatch 介面一樣。

image

而 Windows 8 的應用程式在存取 Windows (或特別為 Windows 8 開發的) 物件時,作業系統會用投影 (Projection) 的方式,讓不同的開發平台可以存取元件中的介面:

image

投影功能是植基於 Windows Metadata 的功能,元件可以在程式中登錄元件介面適用的平台 (for native, for CLR or for scripting),WRT 會自動在元件活化時對應到不同的介面。

WRT 為了要保持不同應用程式間資料格式的相容性,因此特別定義了幾組新的型別如下圖,包含了一個新的 HSTRING 型別,以及泛型介面和執行期類別等:

image

同樣的,在內建的集合物件上也有所改變,陣列會以向量 (Vector) 來替代,而集合則是用 Map 來替代,在 Silverlight 中被廣為應用的重量級 ObservableCollection 也被納入了標準集合中。

image

Windows Runtime Library 的物件活化過程 (object activation process)

WRT 的物件活化過程如下圖:

image

在 Windows 8 中的重要殼層 explorer.exe 中內含了 activation system,它會在應用程式部署時讀入 application manifest 資料檔,並查詢物件的 Registration (於 Class Catalog 與 Extension Catalog),以得到操作它的介面:

image

explorer.exe 還會於查詢完成後將應用程式登錄到 RPCSS 服務以啟動應用程式,而 RPCSS 會搜尋在應用程式中內含的 Core Application Object 進入點 (也就是 main() ),並啟動應用程式本體,在應用程式與物件交換訊息時,explorer.exe 和 RPCSS 也會扮演訊息分派的角色。

image

應用程式內的元件與程式互動則是透過介面呼叫方式處理,而為了要做到一些非同步的工作,元件的程式會被移至不同的 thread 中執行,剛好可以與 .NET Framework 4.5 中將推出的 async 與 await 架構相呼應:

image

Windows Runtime Library 中的使用者介面元素

在 WRT 中內建的都是對 Metro-style application 開發的支援,所以可用的控制項與使用者介面,都是以 Metro-style application 為主:

image

當然,基本的 Databinding 和使用者介面導覽系統一樣都不缺,但那些可以講一個主題了。目前可以看出來的是,XAML 在 Metro-style application 仍然是要角,但如果用的是 JavaScript,那麼 data-binding 機制則會很像 AJAX 的 client template:

image

沒有完結

Windows 8 的 WRT 是一個蠻複雜的東西,可以和 .NET Framework 相提並論,而且 Metro-style application 的開發也是一個很大的學問,本篇文章只是當一個研究 Metro-style application 開發的起頭而已,未來當技術愈來愈明朗時,我們會看到更多技術的文件以及範例,而筆者也會持續追蹤這個技術的發展,因為它也許在 12 個月內就會成為我們生活中的一部份。

阅读(2133) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~