WinCE設計開(kāi)發(fā)常見(jiàn)問(wèn)題（WinCE開(kāi)發(fā)特性及忠告）

最近一段時(shí)間，移動(dòng)設備開(kāi)發(fā)越來(lái)越多的成為了程序員社區的話(huà)題。移動(dòng)設備主要包括智能手機和PDA，是嵌入式開(kāi)發(fā)中很重要的一個(gè)方向。在智能手機領(lǐng)域被大多數手機廠(chǎng)商支持的J2ME無(wú)疑是領(lǐng)頭羊，微軟CE平臺的SmartPhone也逐漸成為關(guān)注焦點(diǎn)。一直不溫不火的PDA市場(chǎng)，也在行業(yè)應用領(lǐng)域有所收獲，Pocket PC由于其開(kāi)發(fā)與Windows平臺的一致性而得到了開(kāi)發(fā)人員的青睞。

在長(cháng)期關(guān)注程序員論壇的過(guò)程中，我發(fā)現由于Windows CE開(kāi)發(fā)的獨特性，加之多個(gè)版本并存、缺乏中文參考資料，所以論壇上充斥著(zhù)大量相同的入門(mén)問(wèn)題。我希望在這里能夠為剛轉入Windows CE開(kāi)發(fā)的程序員明晰一些概念，將現有的Windows CE版本與開(kāi)發(fā)工具之間的關(guān)系給大家解釋清楚。

　　Windows CE與平臺開(kāi)發(fā)

　　Windows CE是微軟為嵌入式設備打造的操作系統，而嵌入式設備可謂多種多樣，這就要求CE操作系統必須是可定制的，所以微軟將Windows CE設計為模塊化的操作系統。說(shuō)簡(jiǎn)單點(diǎn)，我們可以把Windows CE想像成一盒積木，你可以用積木搭建出任何物體，但不一定要把所有的積木都用上。

　　Windows CE搭建出來(lái)的物體就是平臺，是適應某種有固定標準的嵌入式設備的操作系統子集，最著(zhù)名的平臺就是Pocket PC了，是提供給沒(méi)有鍵盤(pán)的掌上電腦使用的平臺。由于平臺和硬件的一致性，所以有時(shí)候我們也用平臺的名稱(chēng)來(lái)稱(chēng)呼整個(gè)系統——硬件與操作系統的總和。

　　我們也可以自己開(kāi)發(fā)平臺，開(kāi)發(fā)工具是微軟提供的Platform Builder，Platform Builder的版本號是和Windows CE的版本號一致的。

　　更多程序員關(guān)心的是應用程序的開(kāi)發(fā)，而應用程序開(kāi)發(fā)是針對特定平臺的，我們在開(kāi)發(fā)之前必須安裝目標平臺的SDK，才能夠開(kāi)發(fā)出適應目標平臺的開(kāi)發(fā)工具。

　　Windows CE開(kāi)發(fā)環(huán)境綜述

　　初學(xué)者另外一個(gè)比較糊涂的概念是版本的問(wèn)題，現在市面上能夠見(jiàn)到Windows CE的兩代產(chǎn)品，它們的內核分別基于Windows CE 3.0和Windows CE.NET（即4.0）。

　　微軟將今年剛面世的Pocket PC 2003和Smart Phone 2003統稱(chēng)為Windows Mobile 2003，我們大多數時(shí)候還是習慣地沿用老稱(chēng)謂。

　　而市面上經(jīng)常見(jiàn)到的Pocket PC 2002是基于Windows CE 3.0的平臺，而Pocket PC 2003則是基于Windows CE.NET的平臺，需要注意的是，Pocket PC 2003的內核是Windows CE.NET 4.2。而SmartPhone2003也是基于Windows CE.NET的。SmartPhone的最初版本是2002，基于Windows CE 3.0的，但是微軟沒(méi)有推出SmartPhone2002的中文版。

　　清晰了平臺與CE之間的關(guān)系，解釋平臺與開(kāi)發(fā)工具之間的關(guān)系就很容易了。微軟提供給應用程序開(kāi)發(fā)者的工具包括：Embedded Visual Tools 3.0，其中包括Embedded Visual C 3.0和Embedded Visual Basic 3.0；Embedded Visual C 4.0和Visual Studio.NET。

　　開(kāi)發(fā)工具的版本號是與Windows CE的版本號對應的。EVC3.0和EVB3.0是用來(lái)開(kāi)發(fā)基于Windows CE 3.0平臺的應用程序的，比較常見(jiàn)的平臺有：Pocket PC 2002、Pocket PC 2000、Palm-size PC、HPC。而EVC4.0是用來(lái)開(kāi)發(fā)Windows CE.NET平臺的程序的，主要包括Pocket PC 2003和SmartPhone 2003。

　　Visual Studio.NET針對嵌入式設備開(kāi)發(fā)需要SDE的支持，而VS.NET 2003中包括了SDE，不需要另外安裝。Visual Studio.NET開(kāi)發(fā)的程序需要目標平臺支持.NET Compact Framework?，F在支持.NET Compact Framework的平臺有Pocket PC 2002和Pocket PC 2003。這里需要注意的是SmartPhone 2003是不支持.NET Compact Framework的。

　　EVB開(kāi)發(fā)入門(mén)

　　微軟已經(jīng)宣布EVB不再支持Windows CE.NET，所以EVB的最終版本是3.0。但由于EVB的易上手性和快速開(kāi)發(fā)的特點(diǎn)，在VS.NET橫空出世之前，它成為Windows CE平臺上快速開(kāi)發(fā)的不二之選?，F在EVB仍然適合Windows CE 3.0平臺上小型應用程序的快速開(kāi)發(fā)。如果您不是專(zhuān)職的Windows CE程序員，而只是需要在Windows CE平臺上開(kāi)發(fā)整個(gè)系統的一部分，那么EVB可以讓您用很短的時(shí)間開(kāi)發(fā)出您想要的程序。

　　EVB的開(kāi)發(fā)環(huán)境的搭建也是十分簡(jiǎn)單，您可以從微軟的網(wǎng)站上下載EVT 2002，其中包含了EVC 3.0、EVB 3.0和Pocket PC 2002 SDK和SmartPhone 2002 SDK。按照提示將EVB和Pocket PC 2002 SDK安裝好后就可以進(jìn)行開(kāi)發(fā)了。SDK中包含模擬器，在沒(méi)有實(shí)際設備的情況下，可以利用模擬器來(lái)調試程序。

　　這里需要注意的是，開(kāi)發(fā)環(huán)境和模擬器之間是通過(guò)網(wǎng)絡(luò )連接協(xié)議進(jìn)行通訊的，所以開(kāi)發(fā)所用的計算機上必須有一個(gè)活動(dòng)的網(wǎng)絡(luò )連接。如果沒(méi)有，可以安裝微軟的虛擬網(wǎng)卡。

　　EVB的開(kāi)發(fā)環(huán)境與VB類(lèi)似，因為Windows CE應用程序需要在模擬器或者實(shí)際設備上調試，所以我們必須選擇程序的輸出目標。如果您選擇了Emulation，在您按下運行（或F5）后，EVB將自動(dòng)啟動(dòng)模擬器，并把程序下載到模擬器中。

　　由于新的Windows CE.NET將不再支持EVB，微軟建議EVB程序員使用VB.NET開(kāi)發(fā)新的程序，而對于原有的EVB程序也給出了遷移路徑，關(guān)于這方面的論述，您可以參考MSDN文章《Moving from eMbedded Visual Basic to Visual Basic .NET》。

　　EVC開(kāi)發(fā)入門(mén)

　　無(wú)論是Win32平臺還是WinCE平臺，Visual C 都是一個(gè)強大的開(kāi)發(fā)工具。而EVC也是WinCE上的主流開(kāi)發(fā)工具。EVC支持MFC類(lèi)庫的子集，可以給開(kāi)發(fā)者提供最強大的支持，也使Win32平臺上的VC程序員可以很容易地遷移到WinCE平臺上。但由于MFC類(lèi)庫需要一個(gè)DLL，所以對某些存儲空間有限的嵌入式設備來(lái)說(shuō)，這是個(gè)很大的負擔，所以SmartPhone就不支持MFC。

　　說(shuō)這么多，讓我們來(lái)創(chuàng )建一個(gè)EVC的工程。是不是和VC很像，需要提醒大家注意的是，由于嵌入式設備支持的CPU種類(lèi)很多，我們在選擇創(chuàng )建工程類(lèi)型的同時(shí)，也要把該工程所支持的CPU類(lèi)型選擇好。創(chuàng )建工程的過(guò)程和VC是一樣的。當然不同的平臺支持的工程類(lèi)型是不同的，比如Pocket PC 2003有支持MFC和API的兩種工程，而SmartPhone 2003則只有支持API的一種工程。

　　EVC中比VC環(huán)境中多了一行下拉菜單的選項，分別用來(lái)選擇：工程、SDK、CPU類(lèi)型和輸出設備。以Pocket PC為例，在實(shí)際設備上調試應該選擇Win32(WCE ARMV4)Debug ，而在模擬器上則需要選擇Win32(WCE emulator)Debug。

　　VS.net開(kāi)發(fā)入門(mén)

　　又來(lái)到我們的.NET時(shí)間了，我怎么說(shuō)又？最近大家都被JAVA和.NET搞得頭昏腦脹了吧？不管大家怎么吵，.NET Compact Framework對于手中缺少開(kāi)發(fā)利器的嵌入式程序員無(wú)疑是一大福音。Visual Studio .NET 2003完全支持對移動(dòng)設備的開(kāi)發(fā)，好了，讓我們開(kāi)始一段奇幻的.NET之旅吧。

　　打開(kāi)VS.net 2003，選File - New – Project,就打開(kāi)了上面的界面。讓我們來(lái)建立一個(gè)Visual C#的工程，然后選擇Smart Device Application，然后OK。

　　你在這里要選擇目標設備：Pocket PC、SmartPhone、Windows CE（指的是其他平臺），下面則是選擇創(chuàng )建的工程類(lèi)型，我們選擇“Windows Application”，左邊是選擇的平臺所支持的模擬器。最后點(diǎn)擊OK，我們就可以進(jìn)入VS.NET的主界面了。

　　選擇輸出設備的情況和EVB十分類(lèi)似，只需要選擇輸出設備，而不用選擇CPU類(lèi)型。當然了，因為.NET是運行在虛擬機上的了。在CPU類(lèi)型眾多的嵌入式領(lǐng)域，.NET和JAVA才能真正發(fā)揮自己的強項。

　　當然，我們也可以選擇VB.NET作為開(kāi)發(fā)智能設備的語(yǔ)言，情況和C#完全一樣。目前智能設備開(kāi)發(fā)只支持C# 和VB.NET。愛(ài)好C 的程序員可能還要等上一段時(shí)間。

Windows CE 開(kāi)發(fā)的忠告

　　可以說(shuō)當我們花了大部分時(shí)間將已有的應用程序移植到Microsoft Windows CE中。一般說(shuō)來(lái)，這個(gè)計劃不是太難。我們起步于Microsoft Win32代碼，當然Windows CE是基于Win32應用程序接口（API）的。有利的是，我們的應用程序（即Raima 數據管理器）有方便的使用接口，并包含一個(gè)大約由150個(gè)子函數組成的庫，這些函數都是由C語(yǔ)言寫(xiě)成，可以用來(lái)創(chuàng )建、管理和訪(fǎng)問(wèn)數據庫。

　　按建立應用程序的方式來(lái)說(shuō)，我們原以為將它移植到Windows CE中是一項相對簡(jiǎn)單的C語(yǔ)言編程練習。然而，我們不久便遇到好些困難。從粗心大意的錯誤開(kāi)始，比如在基于Windows NT 的Windows CE仿真器上使用Microsoft Windows NT庫，接著(zhù)又違背Windows CE的編程戒律，如"千萬(wàn)不要給Unicode（國際標準組織10646標準）字符分配奇數內存地址"。

　　大約有百分之九十的問(wèn)題或多或少地與Unicode有關(guān)。盡管Unicode編程不難，但是，當給單字節字符編寫(xiě)代碼時(shí)，很容易出錯（我有過(guò)許多次錯誤）。

　　下面這些忠告是根據我們在Windows CE上編寫(xiě)Raima 數據管理器的經(jīng)驗總結出來(lái)的，但我相信，在做任何其它Windows CE程序之前，它們都值得借鑒。畢竟大多數Windows開(kāi)發(fā)者，當他們創(chuàng )建第一個(gè)Windows CE應用程序時(shí)，真正運用的是已掌握的Win32知識。

不要在仿真器上使用Windows NT庫

　　這里所討論的第一個(gè)錯誤實(shí)在太愚蠢了，但我還是陷了進(jìn)去，也許你也會(huì )。當用Microsoft VC （5.0版）創(chuàng )建一個(gè)Windows CE程序時(shí)，你會(huì )發(fā)現，包含路徑（include）、 庫路徑（library）、及可執行程序路徑被自動(dòng)調整以匹配反應目標環(huán)境的選擇。因此，比如說(shuō)為Windows CE模擬器建立應用程序時(shí)，你會(huì )發(fā)現，include路徑?jīng)]有指向Win32的包含文件（在VC目錄下），而是指向Windows CE包含文件（在WCE目錄下）。千萬(wàn)別去修改。

　　由于Windows CE在Windows NT下運行，所以仿真器上運行的程序能夠調用任一Windows NT動(dòng)態(tài)鏈接庫(DLL)中的函數，即使這個(gè)DLL不是模擬器的成員也一樣。顯然，這不是很好的事，因為相同的函數也許在手持PC(H/PC)或Windows CE設備上不可用，而你的軟件最終要能在這些設備上運行。

　　第一次將非Unicode應用程序裝入Windows CE仿真器時(shí)，你會(huì )發(fā)現，許多正在使用的函數它都不支持，例如美國國家標準協(xié)會(huì )(ANSI)定義的字符函數strcpy()。這也許引誘你去鏈接Windows NT 運行時(shí)間庫，以便能解決所有問(wèn)題。

　　如果你是剛開(kāi)始用Windows CE編程，可能你能用的包含文件和庫文件是明顯的。答案就是，你不要采用那些在寫(xiě)普通Win32或非Windows CE程序時(shí)使用的包含文件和庫文件。

不要混淆TCHARs和bytes

　　如果你正在Windows CE上寫(xiě)非Unicode應用程序，你或許要將所有的字符串從單個(gè)字符(chars)轉換為寬字符(widechars)（例如，C變量類(lèi)型whcar_t）。幾乎所有Windows CE支持的Win32和運行時(shí)間庫函數都要求寬字符變量。Windows 95不支持Unicode，然而，為了使程序代碼具有可移植性，你要盡可能采用tchar.h中定義的TCHAR類(lèi)型，不要直接使用wchar_t。

　　TCHAR是定義為wchar_t還是char，取決于預處理器的符號UNICODE是否定義。同樣，所有有關(guān)字符串處理函數的宏，如_tcsncpy宏，它是定義為Unicode函數wcsncpy還是定義為ANSI函數strncpy，取決于UNICODE是否定義。

　　在現存的Windows應用程序中，有些代碼也許暗示字符長(cháng)為單字節。這在給字符串分配內存時(shí)經(jīng)常用到，例如：

　　在這段代碼中，分配的內存塊應該寫(xiě)作(MAXFILELEN * sizeof(char))，但是大多數程序員喜歡將它簡(jiǎn)化為MAXFILELEN，因為對于所有的平臺來(lái)說(shuō)sizeof(char)的值等于1。然而，當你用TCHARS代替多個(gè)字符時(shí)，很容易忘記這種固有的概念，于是將代碼編寫(xiě)成下面的形式：

　　這是不行的。它馬上會(huì )導致出錯。這里的錯誤在于malloc函數中指定變量大小為bytes，然而_tcsncpy函數中使用的第三個(gè)變量卻指定為T(mén)CHARs而不是bytes。當UNICODE被定義時(shí)，一個(gè)TCHAR等于兩個(gè)字節數(bytes)。

　　上述代碼段應該改寫(xiě)為：

不要將Unicode 字符串放入奇數內存地址

　　在Intel系列處理器上，你可以在一奇數內存地址儲存任何變量或數組，不會(huì )導致任何致命的錯誤影響。但在H/PC上，這一點(diǎn)不一定能行 ? 你必須對大于一個(gè)字節的數據類(lèi)型小心謹慎，包括定義為無(wú)符號短型（unsigned short） 的wchar_t。當你設法訪(fǎng)問(wèn)它們的時(shí)候，將它們置于奇地址會(huì )導致溢出。

　　編輯器經(jīng)常在這些問(wèn)題上提醒你。你無(wú)法管理堆棧變量地址，并且編輯器會(huì )檢查確定這些地址與變量類(lèi)型是否相匹配。同樣，運行時(shí)間庫必須保證從堆中分配的內存總是滿(mǎn)足一個(gè)word邊界 ，所以你一般不必擔心那兩點(diǎn)。但是，如果應用程序含有用memcpy()函數拷貝內存區域的代碼，或者使用了某種類(lèi)型的指針算術(shù)以確定內存地址，問(wèn)題也許就出現了?？紤]下面的例子：

　　這段代碼是從堆中分配內存并復制一個(gè)字符串，在字符串的開(kāi)頭留一個(gè)HEADER_SIZE的大小。假設UNICODE定義了，那么該字符串就是一個(gè)widechar字符串。如果HEADER_SIZE是一個(gè)偶數，這段代碼就會(huì )正常工作，但如果HEADER_SIZE為奇數，這段代碼就會(huì )出錯，因為q指向的地址也將為奇數。

　　注意，當你在Intel系列處理器中的Windows CE仿真器上測試這段代碼時(shí)，這個(gè)問(wèn)題是不會(huì )發(fā)生的。

　　在這個(gè)例子中，只要確保HEADER_SIZE為偶數，你就可以避免問(wèn)題的發(fā)生。然而，在某些情況下你也許不能這么做。例如，如果程序是從一臺式PC輸入數據，你也許不得不采用事先定義過(guò)的二進(jìn)制格式，盡管它對H/PC不適合。在這種情況下，你必須采用函數，這些函數用字符指針控制字符串而不是TCHAR指針。如果你知道字符串的長(cháng)度，就可以用memcpy()復制字符串。因此，采用逐個(gè)字節分析Unicode字符串的函數也許足以確定字符串在widechars中的長(cháng)度。

在A(yíng)NSI和Unicode字符串之間進(jìn)行翻譯

　　如果你的Windows CE應用程序接口于臺式PC，也許你必須操作PC機中的ANSI字符串數據（例如，char字符串）。即使你在程序中只用到Unicode字符串，這都是事實(shí)。

　　你不能在Windows CE上處理一個(gè)ANSI字符串，因為沒(méi)有操縱它們的庫函數。最好的解決辦法是將ANSI字符串轉換成Unicode字符串用到H/PC上，然后再將Unicode字符串轉換回ANSI字符串用到PC上。為了完成這些轉換，可采用MultiByteToWideChar()和WideCharToMultiByte () Win32 API 函數。

對于Windows CE 1.0的字符串轉換，劈開(kāi)（hack）

　　在Windows CE 1.0 版本中，這些Win32API函數還沒(méi)有完成。所以如果你想既要支持CE 1.0又能支持CE 2.0，就必須采用其它函數。將ANSI字符串轉換成Unicode字符串可以用wsprintf()，其中第一個(gè)參數采用一widechar字符串，并且認識"%S"(大寫(xiě))，意思是一個(gè)字符串。由于沒(méi)有wsscanf() 和 wsprintfA()，你必須想別的辦法將Unicode字符串轉換回ANSI字符串。由于Windows CE 1.0不在國家語(yǔ)言支持(NLS)中，你也許得求助于hack，如下所示：

　　這種適合于Windows CE 1.0的實(shí)現辦法比使用wsprintf()函數要容易，因為使用wsprintf()函數更難以限制目標指針所指向的字符串的長(cháng)度。

選擇正確的字符串比較函數

　　如果你要分類(lèi)Unicode標準字符串，你會(huì )有以下幾個(gè)函數可供選擇：

wcscmp(), wcsncmp(), wcsicmp(), 和wcsnicmp()

wcscoll(), wcsncoll(), wcsicoll(),和wcsnicoll()

CompareString()

　　第一類(lèi)函數可用來(lái)對字符串進(jìn)行比較，不參考當地（Locale）或外文字符。如果你永遠不想支持外文，或者你僅僅想測試一下兩個(gè)字符串的內容是否相同，這類(lèi)函數非常好用。

　　第二類(lèi)函數使用現有的當地設置(current locale settings)（系統設置，除非你在字符串比較函數之前調用了wsetlocale()函數）來(lái)比較兩個(gè)字符串。這些函數也能正確分類(lèi)外文字符。如果當地的字符"C"（"C" locale）被選定，這些函數與第一類(lèi)函數就具有了相同的功能。

　　第三類(lèi)函數是Win32函數CompareString()。這個(gè)函數類(lèi)似于第二類(lèi)函數，但是它允許你指定當地設置（the locale）作為一個(gè)參數，而不是使用現有的當地設置(current locale settings)。CompareString()函數允許你選擇性地指定兩個(gè)字符串的長(cháng)度。你可以將第二個(gè)參數設置為NORM_IGNORECASE，從而使函數比較字符串時(shí)不比較大小寫(xiě)。

　　通常，即使不將第二個(gè)參數設置為NORM_IGNORECASE，CompareString()函數也不用來(lái)區分大小寫(xiě)。我們經(jīng)常用wcsncoll()函數來(lái)區分大小寫(xiě)，除非使用當地的字符"C"（"C" locale）。所以，在我們的代碼中，不使用CompareString()函數來(lái)區分大小寫(xiě)，而用wcsncoll()函數來(lái)區分大小寫(xiě)

不要使用相對路徑

　　與Windows NT不一樣，Windows CE沒(méi)有當前目錄這個(gè)概念，因此，任何路徑只是相對于根目錄而言的。如果你的軟件給文件或目錄使用相對路徑，那么你很可能把它們移到別的地方了。例如，路徑".abc"在Windows CE中被當作"abc"看待。

移走了對calloc()和 time()函數的調用

　　C運行庫中的calloc()函數不能使用，但是malloc()函數可以代替calloc()函數。并且不要忘記，calloc()函數初始化時(shí)分配的內存為零，而malloc()函數不一樣。同樣，time()函數也不能使用，但你可以使用Win32函數GetSystemTime()函數代替time()函數。

　　經(jīng)過(guò)以上的警告后，你會(huì )高興地學(xué)習最后令你驚訝的兩點(diǎn)忠告。

不需要改變Win32 輸入/輸出（I/O）文件的調用

　　Win32的輸入輸出函數，Windows CE也支持。允許你象訪(fǎng)問(wèn)Win32文件系統那樣訪(fǎng)問(wèn)對象。CreateFile()函數在Windows CE中不能辯認標志FILE_FLAG_RANDOM_ACCESS，但是這個(gè)標志僅用作可選的磁盤(pán)訪(fǎng)問(wèn)，并且不影響函數調用的功能。

不要擔心字節的狀態(tài)

　　當我們把應用程序寫(xiě)入Windows CE時(shí)，有了一個(gè)美好的發(fā)現，那就是Windows CE的數字數據類(lèi)型的字節狀態(tài)與Intel結構的字節狀態(tài)一樣，在所有的處理器上，Windows CE均支持。

　　幾乎象所有的數據庫引擎一樣，Raima數據庫管理器在數據庫文件中以二進(jìn)制形式保存數字數據。這就意味一個(gè)記錄無(wú)論何時(shí)寫(xiě)入數據庫或從數據庫讀出，均被當作一系列的字節來(lái)處理，不管它域的內容。只要數據庫文件不要傳給別的任何系統，數字數據的字節狀態(tài)問(wèn)題就解決了。如果數據庫文件被一個(gè)來(lái)自原始系統且帶有不同字節狀態(tài)的處理器訪(fǎng)問(wèn)，數字數據將被誤解。

　　無(wú)論何時(shí)，當你在擁有不同處理器的機器上傳輸文件時(shí)，就會(huì )出現這個(gè)問(wèn)題。在這個(gè)問(wèn)題上，值得高興的是所有類(lèi)型的處理器都使用相同的字節狀態(tài)。

　　在使用Windows CE時(shí)，這些忠告應該引起你足夠的重視，避免學(xué)習時(shí)走彎路。