Win CE開發特性及忠告

VS.net開發入門

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

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

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

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

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

Windows CE 開發的忠告

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

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

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

下面這些忠告是根據我們在Windows CE上編寫Raima 數據管理器的經驗總結出來的，但我相信，在做任何其它Windows CE程序之前，它們都值得借鑒。畢竟大多數Windows開發者，當他們創建第一個Windows CE應用程序時，真正運用的是已掌握的Win32知識。

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

這里所討論的第一個錯誤實在太愚蠢了，但我還是陷了進去，也許你也會。當用Microsoft VC++(5.0版)創建一個Windows CE程序時，你會發現，包含路徑(include)、 庫路徑(library)、及可執行程序路徑被自動調整以匹配反應目標環境的選擇。因此，比如說為Windows CE模擬器建立應用程序時，你會發現，include路徑沒有指向Win32的包含文件(在VC目錄下)，而是指向Windows CE包含文件(在WCE目錄下)。千萬別去修改。

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

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

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

不要混淆TCHARs和bytes

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

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

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

int myfunc(char *p)

{

char *pszFileName;

pszFileName = malloc(MAXFILELEN);

if(pszFileName)

strncpy(pszFileName, p, MAXFILELEN);

/*etc*/

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

int myfunc(TCHAR *p)

{

TCHAR *pszFileName;

PszFileName = (TCHAR*)malloc(MAXFILELEN);

If (pszFileName)

tcsncpy(pszFileName, p, MAXFILELEN);

/*etc*/

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

上述代碼段應該改寫為：

int myfunc(TCHAR *p)

{

TCHAR *pszFileName;

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

if(pszFileName)

tcsncpy(pszFileName, p, MAXFILELEN);

/*etc*/

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