首页 Version2CompactFrameWork_1.v1

Version2CompactFrameWork_1.v1

举报
开通vip

Version2CompactFrameWork_1.v1Windows CE.NET應用程式開發 作者: Paul Yao, Windows Embedded MVP Paul Yao的公司 2002 8月 使用於 Microsoft® Windows® CE.NET application development Microsoft .NET Compact Framework 內容 簡介 Win32 API Microsoft Foundation Class Library .NET Compact Framework 結語 簡介 面對開...

Version2CompactFrameWork_1.v1
Windows CE.NET應用程式開發 作者: Paul Yao, Windows Embedded MVP Paul Yao的公司 2002 8月 使用於 Microsoft® Windows® CE.NET application development Microsoft .NET Compact Framework 內容 簡介 Win32 API Microsoft Foundation Class Library .NET Compact Framework 結語 簡介 面對開發微軟® Windows® CE .NET應用程式的眾多選擇可能會讓你望之卻步。想要建立傳統圖形使用者介面(GUI)的開發者可以選擇微軟Win32®應用程式介面(API)、物件導向式的微軟基礎類別庫(Microsoft Foundation Class (MFC) library)或是.NET Compact Framework(有大量的程式模型及工具支援)。本份文件將會概述這些介面(API)的基本特徵並使讀者在選擇時具有基本的知識背景。 本篇文件的主要目的是對比出在微軟Windows CE(包括Pocket PC以及Windows CE .NET)上三種程式設計介面(API)的技術優點。通常,能擁有許多選擇是件好事,但這也有可能導致我們要花更多時間在分析上。在選擇應用程式介面的時候必須要深思熟慮,因為你所寫下的程式碼不僅僅只是開發的時候要使用,也要考慮未來維護的便利性。 每個在本份文件中討論到的應用程式介面(API)最初都是實作在微軟桌上型(desktop)視窗上。實作在Windows CE .NET上的只是其子集合而已。如果你曾經在桌上型視窗下使用過其中任何一種介面,那麼你將會發現其最核心的功能在掌上型視窗下一樣支援。因此,你對前者具有的認知可能已足夠你在後者作一個良好的選擇。不過事實上你還是沒有使用掌上型應用程式介面(API)的經驗,所以首先你必須決定要學習哪種。表格一摘要了這三種介面的優點及缺點,而文件的其餘部分就是針對這個表格提供更詳細的討論。 表格一.三種Windows CE .NET程式介面的優缺處 應用程式介面 長處 短處 Microsoft Win32 (C / C++) · 執行檔跟動態連結函式庫跑的最快且最小. · 記憶體消耗最少. · 對裝置驅動程式來說是必須的選擇. · 對控制面板小程式(applet)是必須的選擇. · 擴充外殼(shell)的時候要用.像是Pocket PC上的今日桌面(Today screen)及使用者介面外觀, 軟體輸入面板, 等等. · 不需要執行期間程式(runtime);Windows CE .NET本身就是執行期間程式. · 突變出來的應用程式介面. · 回收不用的記憶體空間是應用或驅動程式設計者的責任,使得這個應用程式介面(API)有漏失記憶體(memory leak)的傾向. · 低階應用程式介面,就像是Windows的組合語言一樣。因為擁有許多抽象(abstraction)而使它難以理解. · 程序導向, 非物件導向. MFC (C++) · 物件導向式. 繼承, 封裝, 多型,也被稱作函式多載化. · 容器類別支援陣列, 表(list), 物件地圖並簡化資料處理(simplify data handling). · 型別安全. · 完整的MFC原始碼與嵌入式視覺工具(Embedded Visual Tool)一同正式啟用. · 良好的工具支援. 一群程式魔術師們會為視窗、視覺函數(virtual function)新增訊息處裡器,並新建表單(form)及類別,. · 半自動清除記憶體,因此比Win32比起來較不易漏失記憶體.但因為MFC屬於Win32上層的封裝程式,因此還是很難不受影響. · 執行期間程式的大小. 零售版mfc300.dll的大小是 404 KB. .NET Compact Framework (C# and Microsoft Visual Basic® .NET) · 設計精良的程式設計介面. · 物件導向式. 繼承, 封裝, 多型,也被稱作函式多載化. · 容器類別支援陣列, 表(list), 雜湊表,字典(dictionary)以及堆疊 · 型別安全. · 名稱領域(namespace亦即區別XML文件中元素名稱的一種方法). · 自動記憶體回收,避免了漏失記憶體 · 可攜的機器碼指令集, MSIL / CIL,提供可攜的二進位執行檔(.exe 及.dll). · 快速及易寫的網站客戶端服務(Web service client). · 支援XML的處理. · 良好的工具支援:整合表格設計師(integrated forms designer)讓你更容易從工具箱(toolbox)拖曳工具.; 自動產生使用者介面元素(UI element)的程式碼. · 程式期間程式的大小. 目前尚在測試階段,但預期會小於2MB. · 在受管理的程式碼(managed code)與未受管理的程式碼(unmanaged code)之間呼叫,開銷很大. · 與COM互通會有點不便. 需要寫一個封裝程式(wrapper)來呼叫COM的介面函式. · 無法取得原始程式碼的是別號. · 需要顯示型組態(IABASE) 的螢幕的顯示平台, 但是此平台在無頭(headless)及無標題組態(HLBASE)平台下卻沒有. Win32 應用程式介面 Win32是「Windows 32位元應用程式介面」的簡稱。它是三種應用程式介面內歷史最悠久的,可以回溯到1992年啟用的Microsoft Windows NT®。然而,它實際的年紀比這個更大。 Win32是以Windows 16位元應用程式介面(Win16)為基礎,而Win16早在1985年11月就跟Windows 1.01一起正式啟用了。 其他的API皆極為依賴Win32 API。有人說過:「Win32是Windows的組合語言。」即使你並不是選用Win32來當你的API,其他所用到的工具最後還是會呼叫Win32的函式來完成工作。這種事情在你要用到MFC或.NET Compact Framework不支援的功能時最為明顯。MFC及.NET Compact Framework都允許你在此時連結入更底層的Win32 函式。 跟Windows桌上型(desktop)版本比較起來,Windows CE .NET支援較少的Win32函式。雖然有些人會使用「子集合」這個名詞來說明Windows CE內的Win32的地位,但是你也可以將之看作 「Win32 API中最偉大的暢銷作品」。設計Windows CE.NET的人為了讓Windows CE .NET變小,慎重的挑選了應該包含及捨棄的函式,因此許多冗贅的函式都已被刪除。例如,桌上型版本同時擁有TextOut跟ExtTextOut,但Windows CE.NET只有ExtTextOut。扮演與過去環境相容角色的函式同樣也被刪除了。不支援Win16的登錄(registry)函式,而只有最新的Win32版本是能被使用的。總之,Windows CE.NET上的Win32 是精簡且相容性高的,並只注重開發者會用到的工作。 Win32 API的好處 Win32 API是一條通往最小軟體的路。Win32不像MFC和.NET Compact Framework需要另外一個執行期間程式(runtime)。相反的,它本身就是一個執行期間程式。 Win32 API同樣也是通往最快軟體的路,這使得它成為作即時執行緒的理想選擇。也就是說,如果你想要執行限時(time critical)的工作,你就應該使用Win32。MFC背負了C++帶來的包袱,因此有點慢。 本文件內描述的另外一個選擇.NET Compact Framework,會因為將微軟中介語言(Microsoft Intermediate Language , MSIL)轉換成原生指令集的這個動作而造成延遲。這只會在第一次將程式碼載入記憶體時發生,原來就存記憶體內的原生程式碼可被重複使用。此外,資源回收器(Garbage Collector)也有可能會在錯誤的時間執行,導致在限時程式碼中造成不能預期的延遲。 Win32同時也是相容性最高的API。只要可以在Windows CE.NET內完成的東西,一定也可以在Win32 API內完成。甚至MFC的死忠擁護者也知道當某一功能在MFC內無法支援時,他們可以依賴Win32 API來完成。在這種情況中,全域運算子:「::」是MFC程式設計師最好的朋友。 雖然.NET內並沒有全域運算子,.NET Compact Framework還是可以在需要的時候呼叫到Win32的函式。與MFC不同的是,在.NET有管理的部分與Win32未受管理的部分之間呼叫需要一些額外的支出,例如啟動不同的平台(P/Invoke)。因此你從.NET Compact Framework拿取Win32函式時,必需要謹慎考慮。 因為Win32不需要執行期間程式,所以它也是一個最廣泛被支援的API。如果你想寫個可以在任何Windows CE平台上面跑的程式,Win32這條路準沒錯。如果你想寫個可以在各種不種平台間執行的應用程式,你就一定要使用Win32。我們同時也強烈建議您在寫任何擴充作業系統的程式(例如裝置驅動程式)時,記得使用Win32。 作業系統擴充裝置 Win32對於某些組成因子來說是最好的抉擇,特別是在想要支援範圍廣大的平台,但又不知道特定的執行期間程式是否會出現時。表格二陳列這些作業系統必要的擴充裝置。 表格二 建議使用Win32的組成因子 Component Description 裝置驅動程式 雖然Windows家族的其他作業系統皆定義了一個與Win32不同的裝置驅動程式設計介面給它們,但是在Windows CE.NET中,Win32還是驅動程式們的官方程式設計介面. 特製的軟體輸入面板(SIP) 在口袋型個人電腦以及其他以Windows CE .NET為基礎的裝置上,SIP是指螢幕小鍵盤. 控制面板小程式(Applet) 在每個控制面板圖示背後,都有一組動態連結函式庫提供對話框、內容頁(property page)、內容表(property sheet)以便訂製出可安裝的組成因子。 使用者介面外觀(UI skin) Windows CE .NET採用了可以讓你訂做使用者介面外觀的面板。因此你可以任意的變換系統控制,以獲得不同於正規Windows CE.NET的佈置。這項功能在Pocket PC或是Pocket PC 2002上並不提供。 即時執行緒 Win32比其他兩種API提供更好的效能,因此Win32在你要編寫限時程式碼時是不二的選擇。 撰寫Win32程式的挑戰 Win32被視為是Win16的升級版。Win16跟微軟開發的第一個圖形使用者介面Windows 1.01同時出現。在那個時候,設計的焦點是放在作出一個方便使用的使用者介面即可。當時大部分電腦的使用者介面都是以字符為基礎,而Windows 1.01成功的在1985年11月正式出線。蘋果電腦的麥金塔比Windows 1.01稍微早一點點,在1984年1月啟用。 Windows 1.01圖形引擎(GDI)開發團隊中穆林埃勒(Marlin Eller)曾表示:「雖然提高方便性是Windows 1.01着重的焦點,但是對於增加程式設計介面的便利性這點卻不太獲得重視,這個結果就是一個突變且前後不協調的API。」在很多情形下,參數欄都是空白,以便將來增加新的用途。許多函式也在沒有解釋的情況下就請你輸入NULL或是零。 最明顯的就是這兩個常常要用到的函式:RegisterClass及 CreateWindow。前者要你將資料填入一個資料結構並傳送這個位址,後者卻是要你將所有的資料以一長串的參數傳入。這種前後不配合的例子在Win32內一再的出現,造成了難學、難懂又難除錯的Win32。 Win32:程序化的程式設計介面 Win16及Win32 基本上都是C的程式設計介面,因為C++是在它們之後好久才出現的。因為這個緣故,它們並不支援許多程式設計師視為理所當然的功能,例如函式多載化。換言之,Win16跟Win32是程序導向的程式設計介面。在C及組合語言建立的API中,不會有類別或繼承的功能。 這些API最棒的地方在於它們是以物件為基礎(object-based),而非物件導向的。會用這個術語是因為這個API廣泛的運用了將資料包裝在物件內的觀念,並且裡面有許多可以建立系統物件並回傳控制柄(handle)的函式。例如你可以用CreateWindow這個函式來建立一個視窗,並回傳視窗控制柄(window handle, HWND)。接下來你就可以藉由將控制柄傳入函式的方式來移動,改變大小,隱藏,顯示及刪除視窗。事實上,最後一個刪除視窗的動作是Win32 API的一個核心特性,而這個特性很容易讓你寫出容易漏失記憶體的程式。 如果你曾經當過管理者,你一定知道指派任務的重要。不管你是否曾分派過任務給人,你一定有過被分派任務的經驗。這就描述了Win32管理系統物件的方法,因為這個任務是指派給你:一個程式設計師。 應用程式必需創造一個物件視窗,目錄選單(menu),對話盒,控制件,筆刷,字型等等以便能使用Win32。每當這個時候,記憶體就會被配置。每個程式都要摧毀它建造出來的物件以防記憶體漏失。若無法釋放記憶體空間,就會發生每個軟體的惡夢:記憶體漏失(memory leak)。如果有太多的記憶體漏失,無論是桌上型或是Windows CE.NET甚至是其他的作業系統都會當掉。 作業系統其實是有能力自動清除物件的,但是只有當Win32程式當掉的時候作這件事情才安全。不然,如果想要讓一個程式執行很長的時間,就必須經過全盤的測試以確定它有自己清除物件的能力。 然而,現在已有種可以減輕痛苦的良藥。Entrek公司開發出的CODESNITCH(www.entrek.com)能夠追蹤並回報記憶體漏失。它會告訴你造成記憶體漏失的物件類型以及程式碼行數。CODESNITCH以猜測來取代真正追蹤記憶體漏失這件麻煩事。 微軟基礎類別庫 (The Microsoft Foundation Class Library, MFC) 當Win32發行後,程式設計師們還是努力的想創造出更好用的介面。MFC就是其中一個努力的結果,於1992年正式啟用。 MFC被建造在Win32 API的上層。它對Win32程式設計師來說,是很容易上手的。因為它主要用戶群就是用過Win32後希望找到更好選擇的人。因為這個原因,MFC命名的規則都延續自Win32。例如在繪圖函式中,MFC使用了跟Win32一樣名字的ExtTextOut、Rectangle以及BitBlt。大多數的時候,MFC內與Win32對等的函式是真的是用呼叫Win32做出來的。MFC比Win32還物件導向化,同時它也改善了Win32前後不同調的狀況。例如Win16的MoveTo函數搬到Win32改叫做MoveToEx,但在Windows CE.NET根本沒有這個函數。MFC會幫你處理細節,因此只要打上MoveTo即可。MFC提供了在不同平台間的原始程式碼可攜性。 物件導向方法的好處 MFC有個凌駕Win32的關鍵,那就是物件導向程式設計步驟。傳統上就是指它可以支援繼承,封裝及多型。 MFC內可使用繼承,其內的類別繼承樹更是龐大。就像在其他物件導向設計環境裡,你可以從MFC基本類別出發來建造屬於自己的獨特類別。例如CWnd是每種視窗的基本類別;CView是專門給Document/View的視窗類別;CSrollView是CView的可拉式版本。 MFC的設計也支援了封裝的功能。最基本的MFC類別將Win32的物件包裝起來:CWnd包裝Win32視窗、CDC包裝Win32 DC、CListBox包裝Win32 清單方塊(list box)等等。MFC是以Win32為基礎,因為都採用了跟Win32很像的名字以便慣用Win32的程式設計師使用。 多型(C++中支援)是指可用不同形式實作出同一方法的能力。MFC桌上型版本中也廣泛的使用這項功能,例如CDC::TextOut有兩個擁有不同參數的版本。然而在Windows CE.NET並不支援這項功能,因為相同函數若版本太多會佔用過多的空間。在Window CE.NET執行的MFC亦奉行Window CE.NET的圭臬:讓東西越少越好以保留更多的記憶體空間。 Document/View結構是個常常跟MFC有關聯的基礎模型。雖然你並不需要嚴格地遵照這個模型的規範,但不遵守規範的時候會需要剔除一些東西。Document/View背後的基本想法就是:使用者會想建立、編輯、寫入磁碟或從記憶體讀出一份資料(亦即文件),而這份資料可以不同的面貌(view)呈現給使用者。當你在Embedded Visual C++中使用開新計畫精靈(New Project Wizard)時就能看到這種結構。你可以在對話式及Document/View式的MFC應用程式中做個抉擇,但是運用Document/View最簡單的作法還是以對話式為基礎的。 另一個常在類別庫出現的是容器類別(container class),此外MFC還擁有陣列、表以及物件地圖。你可以用容器類別來聚集所有以CObject為來源的類別。若你想得到和在Win32內一樣的幫助,那你就必須自己寫程式碼。.NET Compact Framework提供了比MFC更棒的容器類別供你使用。 MFC在歷史上曾經被那些想要在桌上型電腦建造應用程式的C++程式設計師們視為第一選擇。它在使用者介面程式設計以及容器類別的使用上都給了我們很大的幫助,甚至還能支援所屬作業系統的核心功能。例如,MFC為專在Windows CE.NET上使用的CCeDBDatabase 以及CCeDBProp提供了專屬的類別。MFC只支援有在所屬作業系統內出現的功能,若作業系統沒有提供這項服務,那就表示MFC也不會支援它。例如Windows CE.NET沒有ODBC 這個特色,在MFC中自然也就不出現了。 MFC的記憶體管理 既然MFC屬於Win32的上層,而記憶體漏失又是Win32一項令應用程式及驅動程式設計師頭痛的問題,那麼MFC要如何解決這個問題?建構子及反建構子的出現為MFC解決了部分的麻煩。對於GDI物件(例如位圖bitmap、筆刷、字型、調色板以及所用到的區域等等)來說,在你摧毀MFC物件的同時,底下的GDI也會被清除。 然而,這些程序並不完美,因此你還是必須跟在用Win32時一樣小心翼翼去注意物件是否已經真的被清除。用過MFC的桌上型開發者一定聽過AfxDumpMemoryLeaks這個函數。就像名字暗示的,它可以陳列出所有已被配置記憶體空間但還沒被釋放的物件。唯一的問題是,這個函數並沒有出現在Windows CE.NET版本的MFC…好險Entrek's CODESNITCH彌補了這個嚴重的問題。 .NET Compact Framework .NET Compact Framework跟在Windows CE. NET上的Win32及MFC一樣,都是其桌上型版本(.NET Framework)的子集合。.NET Compact Framework代表了下一個進化的階段以及更精練的程式設計介面。.NET Framework.和它難兄難弟NET Compact Framework的出現解決了長久以來困擾Win32及MFC使用者的問題。當最終版正式啟用後,它將會支援Pocket PC、Pocket PC 2002以及所有恰當以Windows CE.NET為基礎的平台。 .NET Compact Framework:設計良好的API .NET Compact Framework是個設計良好的API。跟MFC一樣,都是物件導向式的,因此所有你需要的東西都包含在類別裡。它之所以可以提供MFC沒有的服務,是因為名稱領域(namespace)的關係。雖然C++支援名稱領域,但MFC並沒有使用它們。在.NET Compact Framework裡使用名稱領域可以幫助組織API內的各項元素,以便在API內找到各種不同的功能。從使用者介面設計的行話來說,好的設計就反應在所有的元素都是可以找到的(discoverable)。譬如所有.NET Compact Framework支援的繪圖功能都被放在System.Drawing這個名稱領域中。而這個類別其中的一個成員:圖形(Graphics)類別,等同於MFC中的CDC類別。你將會發現System.Drawing中的其他成員也都能輸出圖形。 另一項良好的設計呈現在容器(container)上。這不僅僅指出.NET Compact Framework有容器類別,更代表容器可被使用在.NET Compact Framework內任何地方。雖然在不同的地方出現,容器都能保有良好的一致性。例如每個Form都有ControlCollection,,ListBox 有ObjectCollection, 以及 DataSet 有 itsDataTableCollection,而這些例子都還只是所有範例中的一小部分。在每個這樣的集合中,都有新增、移除以及得到列舉子(GetEnumerator)這些方法。高程度的一致性意謂只要你熟悉其中一個集合,其他集合你就可以很輕易的上手。 .NET Compact Framework的記憶體管理 Win32及MFC都有記憶體管理的問題,大部分是靠程式設計師自行解決,即使不是全部。當你使用.NET Compact Framework撰寫程式碼時,你是在一個記憶體管理良好的環境下寫的。這個事實極為重要,因為「受管理的程式碼」(Managed Code)這個術語會跟.NET Compact Framework同時出現,而「未受管理的程式碼」(Unmanaged Code)就指的是那些不在.NET Compact Framework下撰寫的程式碼。「未受管理的程式碼」意思是當你為物件(譬如位元組、字串、視窗物件或繪圖物件等)配置記憶體時,執行期間程式會自動幫你追蹤這些物件的動向。這些物件被使用完後,會自動被清除。因為系統有追蹤物件的功能,所以它知道你何時使用完物件。它能清楚地紀錄堆疊以及被放在堆疊上的物件。當記憶體所剩無幾時,執行期間程式(稱為共通語言執行期間程式,common language runtime, CLR)會清查堆疊上的物件,看看哪些是正在被使用的。使用中的物件會被保留,而用過的物件會被Garbage Collector捆起來一同摧毀以釋放更多的空間。有Garbage Collector意謂.NET Compact Framework對需限時的程式碼來說,不是個好的選擇,因為你無法預測Garbage Collector會在哪時候執行。 Garbage Collector的出現表示在C#這個語言裡有新增(New)運算子卻沒有刪除(delete)運算子。你可以把原來花在記憶體管理上的心思拿去思考如何處理手邊的問題。 另一個也能建造出.NET Compact Framework的語言: Visual Basic .NET也與C#一樣有Garbage Collector。使用Visual Basic 6的程式設計師將會很高興聽到Visual Basic.NET在Visual Basic 6下一樣有新增運算子。而在他們了解到他們只有一種而不是兩種記憶體配置運算子(沒有CreateObject函式)後,他們將會更開心。既然這些物件的出現已沒有必要,自然就消失的不露痕跡。 其他特色 .NET Compact Framework的類別集合(collection)跟MFC的類別庫一樣,能在應用程式開發上提供很大的幫助。就像先前所提到的,.NET Compact Framework用類別集合的某些部分來整合表單內的控制、List box內的元素以及ADO.NET 類別內的資料庫元件。換句話說,這些類別是設計來讓你的工作做的更好。如果你曾經使用.NET Compact Framework的桌上型版本.NET Framework,你將會發現大部分但不是全部的類別被放進.NET Compact Framework裡。被忽略的類別包括Queues以及SortedList。而被包含的功能有陣列、陣列列表(array list)、雜湊表以及堆疊。 .NET Compact Framework在服務資料庫這方面經驗豐富,它支援原本在桌上型版本的ADO.NET類別的子集合。ADO.NET有個建在記憶體內的表(DataTable),而這個表與控制使用者介面有密切的關係。任何表上的改變都會反應在控制上,反之亦然。你也可以與外在的資料庫作連結,例如資料提供者(Data Provider)、SQL伺服器,或任何Windows CE.NET的原生資料庫。這些資料都能被穿插到XML內,因此若要與任何以XML為基礎的協定(例如SOAP)互動,.NET Compact Framework會是個很棒的選擇。 .NET Compact Framework使與執行在網路伺服器的SOAP基礎網站服務互動變的容易。網站服務是.NET整合的一部份,它允許你越過HTTP協定對網站服務提供者作函式呼叫。雖然越過網路的呼叫函式並不是什麼新鮮事,但這個被.NET 網路服務(Web Services)使用的機制卻是。它取代了低階對低階的socket 呼叫、特定的低階RPC程式碼以及DCOM遠端介面。當你在呼叫.NET 網站服務時,感覺起來就像你平常在呼叫本地建造的物件一樣。 以下是以C# 呼叫網站服務的例子: paulyao.HelloServer serv = new paulyao.HelloServer(); MessageBox.Show(serv.HelloWorld(), "Say"); 這個例子中,網站服務被放在一個叫做paulyao的伺服器中。而此類別的名字就叫HelloServer。在你在近端建造一個實體後,你就可以呼叫成員函式HelloWorld,它會回傳字串:Hello World。雖然這是一個非常簡單的例子,它卻說明了呼叫.NET網站服務的函式是多麼容易的事。更重要的是,建立網站服務的客戶端是由.NET Compact Framework支援的。 .NET Compact Framework的可攜性 .NET Compact Framework的另一個好處就是它的執行檔具有可攜性。這與Win32及MFC是非常不同的,因為它們都會因電腦種類不同而有不一樣的執行檔。這兩個API也具有可攜性,但是在原始碼階段。Win32或MFC建立出的二進位執行檔會包含各種機器的指令(例如x86、進階精簡指令集機器ARM、MIPS、SH3、SH4等等)。 相反的,.NET Compact Framework的執行檔卻有真正可攜的機器指令集,它藉由利用PE檔案形式(所有以Win32為基礎的系統以及Windows所有版本的共同標準)當作格式來達到目的。這些執行檔使用微軟中間語言(MSIL)來取代任何特定的指令。當呈到歐洲電腦製造者協會(European Computer Manufacturers Association ECMA)的標準團體時,它被叫做共通指令語言(Common Instruction Language CIL)。任何為了.NET Compact Framework而以上述這兩種語言撰寫的執行檔皆可在以Windows CE.NET為基礎並裝設有執行期間程式的系統下執行。 .NET Compact Framework的短處 跟MFC一樣,.NET Compact Framework需要一個執行期間程式庫,其實不只一個,是一組。我們預期這些程式庫跑過的足跡最多佔掉2MB的空間,但是這對某些記憶體很少的裝置來說,還是太貴了。 另外一個.NET Compact Framework需要處理的是潛在的效率問題。將MSIL/CIL轉換成原生程式碼需要花上一些時間。這種延遲對需要即時處理的應用程式來講可能變成一個大問題。在大多數的情況下,需限時的工作會由一個執行Win32程式碼的執行緒來負責,而它會有自己的動態連結函式庫。畢竟即時工作是裝置驅動程式以及其他低階程式碼主要的工作範圍。.NET Compact Framework在建造使用者介面、應用程式繪圖以及連結資料庫跟網站服務這些領域上特別有用。如果你正在做一個需要限時的應用程式,用.NET Compact Framework開發使用者介面然後以Win32原生動態資料庫處理即時執行緒這種方法會同時使用到兩種API的優點。 在.NET開發過程中,COM(Component Object Model)變成類似遺產的技術。COM在桌上型以及部分的Windows CE .NET上還是被大量的支援。然而,.NET還是以它「受管理的程式碼」(managed code)、增加的安全性以及MSIL/CIL指令集可攜性取代了 COM成為微軟技術的核心走向。在十年前,COM跟Win32是微軟軟體技術的中堅份子。隨著.NET的到來,COM再也不是核心技術了。桌上型的.NET Framework還是可以利用與「未受管理的程式碼」相互操作的技術支援COM,以便能在分散式記憶體上節省空間。.NET Compact Framework並不直接支援與COM組成因子的雙向操作,但可透過C語言呼叫的Win32動態連結庫來互動。 .NET Compact Framework以使用者圖形介面為導向,並深深的依賴GWES(圖形、視窗以及事件子系統Graphical,Windowing and Event Subsystem)來操作。這意味著.NET Compact Framework需要在一個以螢幕顯示為基礎(IABASE)的平台上執行,在無頭(HLBASE)裝置上並不支援。對於平台建造開發者(Platform Builder developer)而言,這也表示了.NET Compact Framework並不支援「媒體家電Media Appliance」, 「居家用匝道器Residential Gateway」 或是 「小型作業系統的核心程式Tiny Kernel configuration」。這個事實造成最大的影響是任何無頭裝置必需要用SOAP 2.0來取代.NET Compact Framework建造網站服務客戶端。 結語 總結地來說,我們可以參考下列各種不同API間的比較來決定該使用哪種API: Win32 API是最小且最具可攜性的API。若你使用平台開發者(Platform Builder)來建造HLBASE的無頭平台,那麼Win32是最合理的選擇。若你打算以裝置驅動程式、使用者介面延伸、軟體輸入面板或控制面板applet來擴充作業系統,就應該選擇Win32。若你正在建造一個需要即時處理的系統,例如一個每次都能在10毫秒內反應的硬體,Win32更是不二的抉擇。更重要的是,即是你選擇了Win32以外的API,你還是會用到大多數程式設計師都熟悉的Win32,因為MFC以及.NET Compact Framework總有要用到底層Win32來作一些低階功能的時候。 MFC是建造可以編輯及觀看資料的應用程式的一個很好的工具,因為它有內建document/view結構(有時被稱作model/view形式)的優勢。當你想要一組可以用物件導向方法來馴服底層Win32 API的類別時,MFC也是個很好的伴侶。若你想要更廣泛的使用已存在的微軟ActiveX®及COM組成因子,MFC是唯一有內建與COM結構整合機制的物件導向式框架。MFC原始程式碼的存在表示當你需要除錯時,你可以深入MFC底層的Win32追蹤錯誤。這是個可以幫助你在使用MFC時學習Win32的無價寶貝。 我們還有.NET Compact Framework這個選擇,它用更多的容器類別以及更堅固的資源回收器(garbage collector)來提供使用者比MFC更好的物件導向結構。.NET Compact Framework靠著MSIL/CIL可攜式指令集建造比Win32及MFC執行檔更具可攜性的執行檔。.NET Compact Framework在.NET的世界中是個很棒的玩家,它強力的支援.NET網站服務、XML的處理,還能透過ADO.NET取得資料庫。它同時也能讓使用者在兩種程式語言:C#以及Visual Basic .NET(一個能將兩個執行檔天衣無縫整合起來的語言)中作一選擇。
本文档为【Version2CompactFrameWork_1.v1】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
下载需要: 免费 已有0 人下载
最新资料
资料动态
专题动态
is_644545
暂无简介~
格式:doc
大小:133KB
软件:Word
页数:0
分类:互联网
上传时间:2018-09-07
浏览量:6