Win CE開(kāi)發(fā)特性及忠告

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)常用到，例如：

int myfunc(char *p)

{

char *pszFileName;

pszFileName = malloc(MAXFILELEN);

if(pszFileName)

strncpy(pszFileName, p, MAXFILELEN);

/*etc*/

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

int myfunc(TCHAR *p)

{

TCHAR *pszFileName;

PszFileName = (TCHAR*)malloc(MAXFILELEN);

If (pszFileName)

tcsncpy(pszFileName, p, MAXFILELEN);

/*etc*/

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

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

int myfunc(TCHAR *p)

{

TCHAR *pszFileName;

PszFileName = (TCHAR*)malloc(MAXFILELEN * sizeof(TCHAR));

if(pszFileName)

tcsncpy(pszFileName, p, MAXFILELEN);

/*etc*/

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