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

VS.net開發(fā)入門

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

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

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

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

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

Windows CE 開發(fā)的忠告

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

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

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

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

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

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

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

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

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

不要混淆TCHARs和bytes

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

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

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

int myfunc(char *p)

{

char *pszFileName;

pszFileName = malloc(MAXFILELEN);

if(pszFileName)

strncpy(pszFileName, p, MAXFILELEN);

/*etc*/

在這段代碼中，分配的內(nèi)存塊應(yīng)該寫作(MAXFILELEN * sizeof(char))，但是大多數(shù)程序員喜歡將它簡化為MAXFILELEN，因?yàn)閷τ谒械钠脚_來說sizeof(char)的值等于1。然而，當(dāng)你用TCHARS代替多個(gè)字符時(shí)，很容易忘記這種固有的概念，于是將代碼編寫成下面的形式：

int myfunc(TCHAR *p)

{

TCHAR *pszFileName;

PszFileName = (TCHAR*)malloc(MAXFILELEN);

If (pszFileName)

tcsncpy(pszFileName, p, MAXFILELEN);

/*etc*/

這是不行的。它馬上會導(dǎo)致出錯(cuò)。這里的錯(cuò)誤在于malloc函數(shù)中指定變量大小為bytes，然而_tcsncpy函數(shù)中使用的第三個(gè)變量卻指定為TCHARs而不是bytes。當(dāng)UNICODE被定義時(shí)，一個(gè)TCHAR等于兩個(gè)字節(jié)數(shù)(bytes)。

上述代碼段應(yīng)該改寫為：

int myfunc(TCHAR *p)

{

TCHAR *pszFileName;

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

if(pszFileName)

tcsncpy(pszFileName, p, MAXFILELEN);

/*etc*/

不要將Unicode 字符串放入奇數(shù)內(nèi)存地址