????windows?????????????? Win32 vs by K719yZU

VIEWS: 0 PAGES: 17

									選擇 windows 嵌入式應用程式的程式設計介面
                                                                   Formatted: Indent: First line: 0 ch
Win32 和 vs. the .NET Compact Framework
作者:
  Paul Yao, Windows Embedded MVP
  Paul Yao 的公司

使用於

  Microsoft® Win32®
  Microsoft .NET Compact Framework
  Microsoft Windows® CE 3.0
  Microsoft Windows CE .NET
  Microsoft Embedded Visual Tools 3.0 and 4.0
  Microsoft Embedded Visual C++® 3.0 and 4.0
  Microsoft Embedded Visual Basic®
  Microsoft Visual Studio® .NET
  Microsoft ASP.NET Mobile Controls
  Microsoft ADO.NET


內容
 開發工具
 Win32—Windows 的組合語言
 .NET Compact Framework---「快速的應用程式環境」
 連結 Win32 和.NET Compact Framework 程式碼
 結語

應用程式介面(Application Program Interface),以下簡稱為 API

摘要:文章 Application Development Landscape for Windows CE .NET 中比較了
Win32、MFC 和 .NET Compact Framework 這三種 Windows CE API,本篇文章將
會延續上篇的分析,並針對 Win32 和.NET Compact Framework 深入說明如何為
特定程式設計工作來選擇 API。而 API 又大大影響對開發工具(Embedded Visual
C++ 3.0/4.0 或 Visual Studio .NET)的選擇。

選擇 API 對任何開發計畫都是很重要的,因為這將會影響計畫的其他部分。對
嵌入式應用程式來說,這個關鍵就在於在 Microsoft® Windows® 32 位元 API
(Win32®) 跟 Microsoft .NET Compact Framework.中作個選擇。

其實這不是一個很困難的抉擇,因為大多數的軟體都只使用 Win32,或低階程式
碼用 Win32、高階程式碼用.NET Compact Framework。若想要更了解這兩個 API
的特色,請看 Application Development Landscape for Windows CE .NET。

Win32 是微軟 Windows CE 的核心,因此它支援了 Windows CE 所有的功能。對
                   ,          。
任何無頭(headless)的裝置 唯一的選擇是 Win32 對某些作業系統的擴充      ,Win32
還是唯一的選擇。如果你希望做出來的東西,例如裝置驅動程式,在 Windows CE
的平台上有很大的可攜性,使用 Win32 是很合理的。

Win32 和.NET Compact Framework 都有其各自的方式來強化可攜性。.NET
Compact Framework 具有二進位碼可攜性,因此它的執行檔能夠在不同的
CPU(StrongARM, XScale, MIPS, SH3, SH4 等)下執行。可是.NET Compact
Framework 並不支援某些 Windows CE 裝置,尤其是對於那些沒有螢幕顯示的裝
置。甚至某些有螢幕顯示的裝置亦沒有足夠必要的 Win32 API 來支援.NET
Compact Framework。

另一方面,Win32 API 並沒有二進位碼可攜性,但有原始碼可攜性。所以如果要
使用 Win32 API 建立一個能夠在兩個不同平台(如 MIPS 和 SH3)上面跑的程式,
就必須有兩個執行檔,但是只要有一份原始碼。因此 Win32 能夠支援在.NET
Compact Framework 不支援的 Windows CE 系統。這使得 Win32 對於那些必須在
不同 Windows CE 系統下執行的低階組成因子是最好的選擇。

.NET Compact Framework 利用 C#(C 語言家族)或 Microsoft Visual Basic®.NET
(Visual Basic 家族)提供了使用者建立對話式使用者介面的能力 使用者也可以採      。
用在應用程式主視窗(.NET 下稱「form」)上處理輸入跟繪圖的方式來作出圖形
使用者介面(GUI),這對在.NET Compact Framework 上的資料庫管理有很大的幫
助,特別是 Microsoft SQL Server™ CE。對於藉由使用 Microsoft ADO.NET 來建
立放在記憶體裡面的資料庫(in-memory database)的使用者是如此,或是 DataSet
                         。
和 DataTable 的使用者亦是如此 如果你想運用 eXtensible Markup Language(XML)
的資料,或是建立網站服務的客戶端(Web Service client),.NET Compact
Framework 將對你有很大的助益。

這篇文章的其餘部分會更深入地探究何時使用 Win32 和何時使用.NET Compact
Framework


開發工具
當你選擇了一個 API,你也跟著挑選了取得 API 的開發工具。以下的表格將四種
                     ,
Windows CE 的應用開發工具和平台 以及支援微軟 Windows CE 開發為主的 API
作了概括的敘述:


開發工具                             平台                         API
Embedded Visual C++              全部以 Windows CE 3.0 為基礎          Win32
( Embedded Visual Tools 3.0 的一   的平台,包括:
                                                                 MFC
部分)                                  Pocket PC
                                     Pocket PC 2002*            ATL

                                     Smartphone 2002*

Embedded Visual Basic            全部以 Windows CE 3.0 為基礎     Embedded Visual Basic
( Embedded Visual Tools 3.0 的一   的平台
部分)

Embedded Visual C++ 4.0          以 Windows CE .NET 為基礎的平         Win32
                                 台
                                                                 MFC

                                                                 ATL

Visual Studio .NET 2003              Pocket PC                  .NET Compact Framework

                                     Pocket PC 2002*            ASP.NET Mobil Controls
                                     Windows CE .NET 為基礎
                                      的平台

*需要分別下載 SDK

你可以使用以 Windows CE 3.0 為基礎平台的微軟 Embedded Visual C++®
(eVC++) 3.0 或以 Windows CE .NET 為基礎平台的 4.0 版本,來建立 Win32 的應
用程式或動態連結函式庫(DLL)。如果你想要同時建立這兩種 Windows CE 的版
本,請使用 Embedded Visual C++ 3.0。如此,除了那些只在 eVC++ 4.0 下被支援
的 C++功能,你不會失去很多 Embedded Visual C++所擁有的特性。

你需要用 Microsoft Visual Studio® .NET 2003 來建立.NET Compact Framework 的
應用程式。因為在這環境下有個特色,那就是你能利用滑鼠的拖曳和存置(drag-
and-drop),從工具箱控制表單(form),並點選表單(form)裡的元素來增加程式
碼。另外內建的 IntelliSense 顯示了各種控制所支援的內容(properties)、方法
(methods)、事件(events)。所以不管是使用桌面上的 Visual Basic 或 Embedded
Visual Basic 的程式設計師都會發現 Microsoft Visual Studio® .NET 2003 的開發環
境是很相似的。

微軟在 2001 年秋天宣布 Embedded Visual Basic(eVB)可用的特性會在版本 3.0 中
被凍結,若想要繼續使用 Basic 語言的程式設計師們應該計畫使用支援 Visual
Basic .NET 程式語言的.NET Compact Framework。另外它也會提供 eVB 使用者
非常熟悉的拖曳和存置(drag- and-drop)開發環境。

.NET Compact Framework 的應用程式使用一個叫「Platform Invoke」的特性,可
以呼叫包括系統核心函式庫「COREDLL.DLL」在內的 Win32 動態連結函式庫。
而這也只是幾個可以用來在兩個 API 間互相操作的一個結構。


Win32—Windows 的組合語言
Win32 API 是 Windows CE 程式設計界面的核心。在 1990 年代早期,微軟就宣布
它的兩個重要的核心技術是 Win32 和 Component Object Model(COM)。而 Win32
API 在包括 16 位元系統(Microsoft Windows 95, Windows 98, and Windows
Millennium Edition)和 32 位元系統(Microsoft Windows NT®, Windows 2000, and
Windows XP)的 Windows 作業系統上都有被支援。

Windows CE 是第一個為了裝置驅動程式和應用程式而使用 Win32 的微軟作業系
統。16 位元的 Windows 系統在它們的最低階層中使用 Virtual(VxD)驅動程式,
而 32 位元的 Windows 系統擁有一個不是 Win32 且屬於核心模式(kernel-mode)的
API,因此 Windows CE 和 Win32 的關係絕對不只是 Win32 被視為「Windows 的
組合語言」而已。因為 Win32 是一個擁有很基本功能的低階 API,如同最簡單的
工作還是需要多樣的機器語言指令一般,真實的工作也需要多樣的 Win32 函式
呼叫。然而這是一種其他 API 和開發工具所大大依賴來完成工作的 API。

                                                    ,
在.NET Framework 中,Win32 被視為「未受管理的程式碼(unmanaged code)」
這是因為共通語言執行期間程式(common language runtime, CLR)並不會管理記
憶體,或保證 Win32 程式碼的安全性和型別安全(type-safety)。相反地,.NET 的
程式碼被稱為「受管理的程式碼(managed code)」   ,因為所有的特性都被.NET
runtime 所支援。所以了解「受管理」和「未受管理」的程式碼是了解這兩種 API
不同處的關鍵。


何時使用 Win32
Win32 API 提供了建立那些像可擴充作業系統的裝置驅動程式或 DLL 等之低階
組成的能力,Win32 也被用在必須於 headless (HLBASE-derived) Windows
CE .NET 平台上執行的應用程式中。以下有些基本特性敘述了 Win32 為何是最
好的選擇,以及為何對某些應用程式來講,Win32 是唯一的選擇。
   最快速的執行檔 (Fastest executables)
   最好的及時支援 (Best real-time support)
   原始碼於平台間的可攜性 (Source code inter-platform portability )
   利用.NET Compact Framework 應用程式將 COM 包裝以存取的能力
   建立裝置驅動程式的能力
   建立控制面板(control panel)applet 的能力
   支援特定使用者介面的面板
   支援安全性擴充
   建立 Simple Object Access Protocol (SOAP) Web Servers 的能力
   支援 Pocket PC shell 擴充
   使用已存在 Win32 程式碼的能力

最快速的執行檔
Win32 提供了最快速的執行檔。部分的原因是 Win32 的執行檔使用原生(native)
機器指令,而.NET Compact Framework 的執行檔使用微軟中間語言(Microsoft
                                                             ,
Intermediate Language/Common Intermediate Language , MSIL/CIL) 而這種語言是
必須被轉為原生碼的。這個轉換需要時間,而且你無法預期此轉換何時會發生。

只有當程式碼從物件儲存和(或)從唯讀記憶體中解壓縮到程式記憶體時,中間語
言(Intermediate Language)轉換到原生(native)碼的動作才會發生。因此在轉換過
後,只要此程式碼不被系統記憶體管理者刪除,程式碼就不再需要其他的轉換即
可執行。

另一個會使.NETR Compact Framework 程式碼延遲的原因是資源回收器(Garbage
Collector),因為 Garbage Collector 將搬動物件到堆積(heap)視為它動作的一部
分。任何一個正在程序(process)中執行且受到管理的執行緒(thread),可能需要同
時存取一個或多個在堆積上的物件,為了避免此現象發生,所有的執行緒是停止
的。毫無疑問地 Garbage collector 提供了一個有用的服務,但沒有任何可以安排
或控制 Garbage Collector 何時執行的方法,這表示受管理的程式碼在執行中可能
是不一致的。


最好的即時支援
建議使用 Win32 來支援即時系統是跟其擁有最快的執行檔有關,因為即時運算
的重點需要正確且即時的演算法。而即時處理是用來收集資料、以及控制各類的
裝置,如製造廠的機器以至於用來輸入資料的滑鼠和鍵盤。

即時支援不只表示處理東西要越快越好,Windows CE 的即時支援還為擁有最高
優先權的執行緒和中斷處理提供一致性的保證。Windows CE 透過
CeSetThreadPriority 這個函式提供 256 種執行緒(therad)優先權,另外也利用函式
CeSetThreadQuantum 來操縱如何安排個別執行緒的 quantum。

如同之前所描述的,Garbage Collector 需要所有受管理的執行緒停止執行。但是
以原生程式碼所執行的執行緒,即使在 Garbage Collector 正在執行時,也能夠繼
續執行。因為此種執行緒在 Garbage Collector 正在執行時,會跑回受管理的程式
碼中,並停滯(blocked)一直到 Garbage Collector 執行完成。這表示你可以有信心
地讓一個執行原生程式碼的 Win32 執行緒和受管理的程式碼同時和平地存在。


原始碼(平台間)的可攜性
Win32 和.NET Compact Framework 的應用程式都提供了一定程度的可攜性:
Win32 提供原始碼可攜性,而.NET Compact Framework 提供二進位碼可攜性。
                                        ,
因此當你要讓原始碼能在很多 Windows CE 平台上執行時 那麼即使在沒有.NET
Compact Framework 執行期間程式(runtime)的平台上,Win32 也能夠提供你此服
務。但 Win32 的執行檔有個限制:它們必須擁有足夠的 Win32 函式,而且取決
於為何種的 CPU。

Windows CE 是個高度依設定而改變的作業系統。這是指支援某個平台的 Win32
函式可能並不和另一個平台上的函式相合。因此即使使用 Win32 API,要得到在
各平台間的高度可攜性,依舊需要花一些功夫。

每個 Windows CE 平台保證擁有符合 Platform Builder 裡「Tiny Kernel」結構的函
式。(這在 Platform Builder 的早期版本中叫做「MINKERN」)在這些被支援的特
性中為以下的核心服務:
 模組函式(LoadLibrary,FreeLibrary,GetProcAddress)
 執行緒函式(CreateThread,Sleep..等)
 同時化函式(critical section,mutexes,semaphores)
 檔案輸出入函式
 登錄函式
 記憶體配置函式(VirtualAlloc,HeapCreate,LocalAlloc..等)
 C-runtime string 函式(wcscpy,wcslen..等)
 點對點佇列(queue)函式(例如:CreateMsqQueue)
 支援連續系列間的溝通(Serial communications support) (有 SetCommMask,
  GetCommState..等)

Windows CE .NET Platform Builder 定義了 Standard SDK 的一部分,當這一部分
被加到平台上時,會包含進一組基本的作業系統特徵。只以螢幕顯示為基礎的基
                                                   ,
本核心系統(建立在 Internet Appiiance Base Files(IABASE)的核心上) 使我們較容
易撰寫那些可在很多種以 Windows CE. NET 為基礎的平台上執行的元件。欲獲
更詳細的內容,請看 Standard SDK for Windows CE .NET.


利用.NET Compact Framework 應用程式將 COM 包裝以存取的能力
雖然桌上型的 .NET Framework 提供了與 Component Object Model(COM)共用的
功能,但 .NET Compact Framework 並不支援此功能。你必須利用一些包裝過的
函式(跟你想使用的 Win32 ActiveX®/COM 函式庫有關) 來建立 Win32 的動態聯
結函式庫。

這個步驟成功與否跟你試著去呼叫的組成因子種類有關       。對於擁有很少或根本沒
有使用者介面的組成因子,這種支援會運作的很好。以下是一些和一個或多個
COM 組成因子包裝而成的 Windows CE 系統服務。

   Pocket Outlook® Object Model (POOM)
   DirectX® Multimedia API, 包括 Direct3D® (3D 繪圖), ActiveMovie®,
    DirectMusic®, 和 DirectPlay®

   Mail API (MAPI)
   Object Exchange (OBEX)
   OLE Database API (OLEDB)
   Simple Object Access Protocol (SOAP)
   Pocket Internet Explorer Web viewer window
   藍芽(Bluetooth) API

   Internet Explorer 5.5 add-ins
   Universal Plug and Play (UPnP)
   Access structured-storage 檔案
   Access COM 自動化伺服器



建立裝置驅動程式的能力
全部的裝置驅動程式都必須用 Win32 來撰寫。一些理由我們在前面已經提過。
如大小、速度、即時支援和多種平台的可攜性等。

另外一個結構性的原因是,裝置驅動程式總是用 C 語言能呼叫的輸出函式來建
立動態連結函式庫。雖然你可以建立相容於.NET 的 DLL,但 .NET Compact
Framework 並不支援某些此類的 DLL。

這是第一個跟「作業系統擴充」有關聯的項目。全部的這些作業系統擴充都是動
態連結函式庫,而且你可以將他們用 Win32 實作出來。


建立控制面板(control panel)applet 的能力
就像在 PC 的桌面上一樣,你可以在 Windows CE 的控制面板(Control Panel)上新
增圖示(icon),這可供使用者在集中的區域內修改系統設定。這對隱藏的服務和
安裝於系統上的驅動程式特別重要。

控制面板 applet 是將一個叫 CplApplet 函式輸出的 Win32 DLL。這些東西在需要
的時候會被 Control Panel 載入並秀出相關的對話框。另外 Platform Builder 在
\WINCE400\public\WCESHELLFE\OAK\CTLPNL\CPLMAIN 下提供了 Control
Panel 的原始碼和幾個控制面板 applet 範例的原始碼。


訂製使用者介面外觀(skin)
Windows CE .NET 提供了作業系統中改變使用者介面外觀的功能。這類似自繪
(owner-draw)的概念,也就是說 Win32 程式可以改變如按鍵、狀態列、標頭控制
項、ListView 控制項和 Tab 控制項的外觀。(桌上型 PC 提供其他 Windows CE 所
不支援的自繪項目,如 Listbox)。例如一個自繪按鍵可以顯示一隻魚及其一連串
的動作,或是任何其他使用者所要的圖案。簡單地說,Windows CE .NET 提供了
所有改變控制列外觀的功能。

使用者介面外觀面板使平台開發者能夠在不是客戶端的視窗區域作跟自繪控制
項支援的客戶端區域相同的改變。外觀面板讓你可以改變系統的顏色、用來捲動
軸箭頭的小型對應工具集、檢查盒、選擇鈕和其他小型系統圖片。此外你也可以
改變大部分系統控制項的外觀。

Windows CE .NET 提供兩種標準面板:Windows 95 外觀和 Windows XP 外觀。
當建立一個特定的平台時,你可以修改這兩個面板,來讓你的外觀和其他以
Windows CE 平台為基礎的外觀看起來不一樣。

修改建立平台時所撰寫的 C++原始檔以及將這些原始檔與 Graphics, Windowing,
and Events Subsystem (GWES)整合,可以達到此功能。而接下來也只有 Win32 可
以用來建造使用者介面外觀。
假設你要建立的是一個特定的 shell,則前面所提到的步驟只是在一個已存在的
面板上加入新的面板而已。所以若要建立特定的 shell,必須從頭寫起。這裡你
所得到最重要的好處是對使用者所見及所做擁有更大的控制權。下面的位置為
Windows CE .NET 的 Platform Builder 提供一個 shell 的範例:
.\Public\wceshellfe\Oak\Taskman。


支援安全性擴充
2.0 版本後的 Windows CE 都提供了增加網路溝通安全性的功能,其中包括了
Secure Socket Layer(SSL)、API 加密(CRYPT32.DLL)和 X.509 數位認證。Windows
CE .NET 還對 Security Support Provider Interface(SSIP)提供支援,這在 Windows
2000 之前都是沒有的。SSPI 是負責輸出一個叫 InitSecurityInterfaceW 函式的
Win32 API 動態連結函式庫。

          :
這兩種安全支援 LAN Manager 和 Kerberos 在 Windows CE .NET 上可以使用而
       ,
且利用 SSPI 你可以在 Windows CE .NET 的平台上加入你自屬的特定安全機制        。

對於安全性這個主題,.NET Compact Framework 的執行檔在自屬的演算法上被
爭議說比 Win32 執行檔的安全性還低的這點是值得拿出來討論的。原因之一是
類似 IL Disassembler(ILDASM.EXE)的這種工具允許任何人將機器語言置入你的
程式中。雖然這也可以在 Win32 的模組中也可以做得到,但在.NET 二進位碼內
還可以看到屬性(property)名稱、方法(method)和事件(event)這些重要的資料。利
用被稱為「欺騙者(obfuscator)」的工具使這些資料較不容易被理解,是將技術性
                         。
的細節內容隱藏的的一種方式 關心隱藏自屬資料內容的開發者無庸置疑的會想
更深入探究 Win32 或.NET Compact Framework 所需的安全保護程度。


建立 SOAP Web Servers 的能力
不管是區域網路或大範圍的 Internet,網路服務都會提供跨網路呼叫函式的能
 ,                    。
力 因為這是分散式計算發展的下一步 為支援此功能     ,.NET Compact Framework
擁有建立客戶端網路服務的能力。換言之,.NET Compact Framework 應用程式
                              。
能夠宣告和呼叫在 SOAP 所允許的網路伺服器上的函式 這不僅包括以 ASP.NET
為基礎的網路伺服器,還包括任何支援 SOAP 業界標準的伺服器。

.NET Compact Frame 雖然能讓你建立網路服務(Web Service)的客戶端,但他並不
提供建立網路服務(Web Service)之伺服器端的能力。不過你可以在 Windows
CE .NET 上建立網路伺服器(Web Server),這包括了利用 Platform Builder 來啟動
的 SOAP 2.0 工具組和建立本身是 Win32 DLL 所需的 COM 物件,才能使你的網
路伺服器(Web Service)運作。


支援 Pocket PC shell 擴充
Pocket PC shell 考慮到一些必須用 Win32 實作的改進,這包括了 Today 螢幕、特
定的 Software Input Panel (SIP)模組等。


使用已存在 Win32 程式碼的能力
假設你有 Win32 的程式碼,你就必須以 Win32 來保存這程式碼。除非你有些必
須移植到.NET Compact Framework 程式碼,不然以以 Win32 來保存程式碼還是
較好的方法。有人可能會建議使用 10x,但除非你使用 10x 可獲得 10 倍的好處,
不然還是繼續使用舊的技術。

你可能需要包裝已存在的 Win32 程式碼,讓它可以從.NET Framework 讀取。這
篇文章的最後一部份會總結支援 Win32-to-.NET Framework 整合性的機制。


.NET Compact Framework---「快速的應用程式環境」
不論使用 Win32 來撰寫支援裝置或作業系統的低階程式碼是否為好的,.NET
Compact Framework 在高階上的互動還是很好的。.NET Compact Framework 對於
建立一個有使用者介面、擁有收集資料能力、能在本地資料庫儲存資料,且偶爾
還能將資料送到伺服器型資料庫的應用程式來說,是最合適的。

如前面所述,Win32 程式碼被視為未受管理的程式碼,.NET 程式碼則被叫作受
管理的程式碼。「受管理」就是指 Common Language Runtime(CLR)(程式碼管理
員),能提供下列幾點保證:

   受管理的程式碼不能有不健全的指標(bad pointers)
   受管理的程式碼不會產生記憶體漏失(memory leaks)
   受管理的程式碼提供堅強的型別安全性(type-safety)

受管理程式碼的最大好處是你可以利用受管理的開發環境來處理一些平常使
Win32 程式設計師感到麻煩的錯誤。


何時使用.NET Compact Framework
這裡列出合理使用.NET Compact Framework 的情況。接下來的章節也會陸續詳
細討論到。

   使用擁有.NET Compact Framework 的平台
   建立使用者介面
   建立特定的控制項
   在多顆 CPU 間達到二進位可攜性
   建立網站服務的客戶端
   建立資料密集型和資料庫密集型的應用程式
   建立 XML 密集型的應用程式
   使用已存在的.NET Framework 程式碼


使用擁有.NET Compact Framework 的平台
支援.NET Compact Framework 執行期間程式的平台,才能執行.NET Compact
Framework 的應用程式。.NET Compact Framework 需要最基本的 Windows
CE .NET 環境(.NET Compact Framework 的 Windows CE 4.1 版本)。但有兩種例
  :
外 在 Windows CE 3.0 版本上執行的 Microsoft Pocket PC 和 Microsoft Pocket PC
2002,因其支援了.NET Compact Framework。另一個支援 Microsoft Smartphone
的.NET Compact Framework 預計將在 2003 初發行。

欲執行.NET Compact Framework 應用程式的平台,其第二項需求是,必須支援
足夠建立.NET Compact Framework 所需的基本 Win32 API。用來支援.NET
Compact Framework 所需的 Win32 API 一定要存在。.NET Compact Framework 不
能在包括 Tiny Kernel、Media Appliance 和 Residential Gateway 等以 headless
Windows CE .NET 為基礎的平台上執行。要執行.NET Compact Framework,
Windows CE .NET 平台必須擁有顯示螢幕,也就是說建立此平台一定要以
IABASE 為基礎。

平台開發者要確認是否支援.NET Compact Framework 最簡單方式就是把.NET
Compact Framework 的二進位碼加進來。至目前為止,Compact Framework 的二
進位碼尚在 beta 的測試階段,因此還不能結合到 Windows CE .NET 的平台上。
在.NET Compact Framework 正式啟用後,平台開發者就可以使用 Windows
CE .NET 映像檔(image)自己把.NET Compact Framework 的二進位碼加進來。


建立使用者介面
.NET Compact Framework 在建立使用者介面上做的很好。Visual Studio
Designer 允許你從工具箱拖曳和存置(drag and drop)控制項。屬性(Properties)視窗
會幫助你辨別所支援的事件和不同控制項的屬性。這都是非常直接的使用者介
面。習慣撰寫桌上型.NET Framework 應用程式的程式設計師會發現其有很多地
方是類似的。

不過其實他們是不一樣的。雖然 35 項桌上型.NET Framework 控制項中的 28 項
都有在.NET Compact Framework 中被支援,但每一個控制項都已被修正來滿足
Windows CE 的大小和效能需求。因為這個原因,只有一部分的桌上型屬性、方
法和事件(PMEs)在.NET Compact Framework 中被支援,且依特定類別提供特定
的控制項。而基本(Base)控制項包括 27 個屬性(全部共 76 項)、35 個方法(全部共
128 項)、17 個事件(全部共 58 項)。最大的衝擊會在你想從桌上型 PC 移植程式
碼時出現。

不管如何,你都會找到一組適合你的控制項,包括像 GUI 程式設計師習慣使用
的 DataGrid 和 TreeView。


建立特定的控制項
建立特定的控制項跟建立使用者介面有關。.NET Compact Framework 使用 28 個
控制項,其中包括 Windows 使用者需要的全部標準控制項:文字編輯視窗
(TextBox)、按鍵(Button)和用來顯示目錄的不同控制項 (ComboBox, ListBox, and
ListView)。

如果這些內建的控制項不能滿足你的需求,你可以建立特定的控制項。通常的做
法是利用一個叫 Control 的基本控制項類別,再加上你所需要的屬性、事件和方
法。


在多顆 CPU 間達到二進位可攜性


在.NET Compact Framework 的平台上,一個.NET Compact Framework 的執行檔
可以同時在多顆 CPU 上執行。這裡最大的好處是當你要利用多顆 CPU 來執行程
式時,設定的步驟已經簡化。這對擁有特定控制項和其他多平台產品的.NET
Compact Framework 函式庫特別有幫助。

建立網站服務的客戶端
桌上型 PC 的.NET Framework 和.NET Compact Framework 其中的一項堅強功能
就是,可以輕易地建立網站服務(Web Service)客戶端,網站服務客戶端允許網路
        ,
函式呼叫 這是分散式計算技術長期發展的下一步 其中包括了 Remote Procedure  ,
Calls(RPCs)和 Distribute Component Object Model(DCOM)。

網站服務提供放在網站伺服器端的函式呼叫語法資訊 網站伺服器傳統上處理大        ,
量人們可讀的 HTML 語言,但網站服務(Web Service)使用較像機器語言的
XML。網站服務使用 Simple Object Access Protocol(SOAP)所特別指定的 XML,
使用此種業界標準規定表示.NET Compact Framework 應用程式可以從不同種類
的 Web Server 產品上讀取 Web Service。Web Service 的支援對分散式、無線網路
和固定(always connected)網路的運算提供了另一種選擇。


建立資料密集型和資料庫密集型的應用程式
另一個使用.NET Compact Framework 的原因是其支援資料處理和資料庫的優點           。
在資料處理方面,.NET Compact Framework 的 Garbage Collector 負責清理記憶
體。而因為 Garbage Collector 的存在,.NET Compact Framework 較不會有記憶體
漏失和 heap 溢出的情形發生。

如其他類別的函式庫一樣,.NET Compact Framework 也擁有容器(container)類別
來幫助你做資料處理的工作。你可以在陣列(array)、表(list)、雜湊表(hash table)、
字典(dictionary)、佇列(queue)、堆疊(stack)間選擇。這每一項都可幫助你組織和
排列存在記憶體上的資料物件。反之,Win32 沒有內建的容器(container)類別。

.NET Compact Framework 以聯結(binding)資料達到控制的目的。這個能力是用來
確保使用者介面控制之間的同步(synchronization),像 TextBox 的控制和資料來
源。資料連結讓你在設定一次後就不用理他,也不需要一直擔心控制項第一次出
現時初始化的問題。而且當控制項被移除時,能夠自動改變。

最後還有一點是 ADO.NET,ADO.NET 提供了本地和遠端資料讀取的能力。本
地資料讀取牽涉到在一個區域的檔案系統使用資料庫和操作記憶體裡的資料 遠                   。
                       ,
端資料讀取跟讀取遠端資料庫有關 就像一個在安裝在平台上的 SQL Server 2000
一樣。這兩者在.NET Compact Framework 都有支援。跟.NET Compact Framework
一同啟用的資料提供者不但支援讀取 SQL Server CE,也可讀取伺服器型的 SQL
Server。


建立 XML 密集型的應用程式
ADD.NET 的基本儲存格式是 XML,所以若你使用 ADD.NET 服務,就是使用
XML。但如果你是做其他需要 XML 支援的事,像交換以 XML 為基礎的文字文
件、分析資料庫要求的 XML 資料語法和包裝送到網站服務的複雜交易。.NET
Compact Framework 擁有豐富的 XML 服務來幫助你。


使用已存在的.NET Framework 程式碼
如果你已經有桌上型.NET Framework 的程式碼,這是你選擇使用.NET Compact
Framework 的另一個原因。因為.NET Compact Framework 含有大部分.NET
Framework 的功能,而且最重要的組成是一樣的。包括名稱領域(namespace)、類
別、方法名稱、屬性名稱和資料型態。

然而你會發現.NET Compact Framework 是一個比桌上型.NET Framework 小很多
的函式庫。單比較二進位檔案,.NET Compact Framework 大約是 30MB,而.NET
Framework 只有 1.5MB。這表示桌上型.NET Framework 的子集合可以在大小和
效能上調整地更好。

連結 Win32 和.NET Compact Framework 程式碼
如果你採取我建議的方式—混合.NET Compact Framework 和 Win32 的程式碼 –
你需要了解如何連結這兩種程式碼。這滿足了.NET 偉大的設計目標:整合性。
在.NET 的術語中,Win32 程式碼稱未受管理的程式碼,因為.NET 共通語言執行
期間程式(Common Language Runtime, CLR)執行引擎並不管理 Win32 程式碼。他
並不收集資源、處理例外、提供安全性或讀取任何 Win32 程式碼的資料,相反
地,CLR 為受管理的程式碼提供這全部的功能,甚至更多。

呼叫 Win32 函式
.NET Compact Framework 提供桌上型.NET Framework 的部份整合性。尤其是你
可以建立 Win32 動態連結函式庫的函式呼叫,但你不可以呼叫 COM 介面(一個
已知為 COM Interop 的功能 )

                                  ,Platform Invoke 能在.NET
呼叫 Win32 DLL 的能力稱為「Platform Invoke」
Compact Framework 類別的函式中加入一個宣告。這裡有個宣告範例讓你可以在
系統的 COREDLL.DLL 函式庫中呼叫 MessageBox 函式,(函式最後的「W」在
這個宣告是指在這函式的的字串接受「廣大」(Wide)—意指 Unicode—字符集)

[C#]

[System.Runtime.InteropServices.DllImport("coredll.dll")]

public static extern int MessageBoxW(int hWnd, String text,

       String caption, uint type);
[VB.NET]

<System.Runtime.InteropServices.DllImport("coredll.dll", _

       SetLastError:=False)> _

       Public Shared Function MessageBoxW(ByVal hWnd As Integer, _

           ByVal txt As String, ByVal caption As String, _

           ByVal Typ As Integer) As Integer

       End Function

現在你可以像普通的.NET Compact Framework 的函式一樣呼叫這個函式,以下
是從 C#和 VB.NET 中呼叫這個函式的例子

[VB.NET]

MessageBoxW(0, "Calling from VB.NET", "Platform Invoke", 0)

[C#]

MessageBoxW(0, "Calling from C#", "Platform Invoke", 0);

如此例所示,你並不需要建立你自己的 Win32 DLL--系統提供了許多 DLL 且在
每個 DLL 中提供了許多你可以呼叫的函式,假設你決定要建立自己的 DLL,有
幾點是需要注意的:

1 只有 EXPORTED 的函式可被讀取,為了輸出函式,你可以:
  a.在模組定義(.DEF)檔中使用 EXPORTS 的敘述或
  b.使用__declspec(dllexport)這類編譯器的關鍵字
2 要確保 C++函式名稱不會遭到損毀;否則你沒辦法找到你的函式。最簡單的方
  式就是使用關鍵字 extern 「C」(請見下面的例子),並使用像 DEPENDS.EXE
  的工具來檢查 DLL 是否已輸出所有需要輸出的函式。
3 選擇__stdcall 的呼叫機制,這是.NET Compact Framework 內建用來呼叫 Win32
  函式的機制,不過它限制函式只能擁有固定數目的變數,但如此卻能將清除堆
  疊的工作交給被呼叫的函式來做,以產生較小且較快的程式碼。(要讓變數的
  數目可變動,請使用__cdecl 這個關鍵字,並修改.NET Compact Framework 的
  函式宣告)

以下是上面 3 點在 MyMessageBox 裡的實作,我自己的 Win32 MessageBox 函式
版本:

extern "C" __declspec(dllexport)

int __stdcall

MyMessageBox(HWND hwnd, WCHAR * pMsg, WCHAR *pCaption, int type)

{

     return MessageBoxW(hwnd, pMsg, pCaption, type);

}

這是一個顯示如何從.NET Compact Framework 傳遞簡單變數型態—整數和字
串—到 Win32 的例子,你也可以從.NET Compact Framework 程式碼傳遞其他形
態的變數到 Win32,特別是像結構(struct)的型態。

                                                   ,
.NET Compact Framework 的整合性只支援呼叫 Win32 的函式庫 卻不能從 Win32
呼叫.NET Compact Framework。但你可以透過一個 Win32 程式設計師熟悉的機
制—windowing message—在 Win32 和.NET Compact Framework 間作溝通。

MessageWindow
.NET Compact Framework 團隊研發出一個叫 MessageWindow 的類別,它存在於
Microsoft. WindowsCE .Forms 的名稱領域中,可用來溝通 Win32 和.NET Compact
Framework 的程式碼。MessageWindow 是一個 Win32 視窗的包裝。經由正規的
發送訊息函式可讓 Win32 送訊息到這個物件上。

使用 MessageWindow 的.NET Compact Framework 必定會建立一個視窗程序。跟
正規 Win32 程序不一樣的是,你為 MessageWindow 建立的程序會被放在.NET
Compact Framework 的應用程式或函式庫裡。當一個視窗建立後,.NET Compact
Framework 一定會發送視窗處理柄(handle)到 Win32 的程式碼中,這可藉由使用
Platform Invoke 函式呼叫或發送訊息到另外一個 Win32 視窗來達成。

MessageWindow 讓 Win32 應用程式傳遞三個 32 位元的值到.NET Compact
Framework 的應用程式中:訊息值、wParam 和 IParam。對某些用途來說,這已
足夠。

結語
Windows CE .NET 目前支援 Win32 API,而只要.NET Compact Framework 一正式
啟用,它也會支援。在某些情況下—低階驅動程式碼、作業系統擴充、遺留的程
式碼或 headless 服務—使用 Win32 API 是合理的。但在其他大部分的情況下,結
合.NET Compact Framework 程式碼和 Win32 可以運作地很好。盡可能的延
伸.NET Compact Framework 的極限,然後當你需要基本 Win32 函式庫的幫忙時,
再使用 Platform Invoke 和 MessageWindow 來支援。

								
To top