最近兩周我們花了大部分時間將已有的應用程序移植到Microsoft Windows CE中。一般說來，這個計劃不是太難。我們起步于Microsoft Win32代碼，當然 Windows CE是基于Win32應用程序接口（API）的。有利的是，我們的應用程序（即Raima 數(shù)據(jù)管理器）有方便的使用接口，并包含一個大約由150個子函數(shù)組成的庫，這些函數(shù)都是由C語言寫成，可以用來創(chuàng)建、管理和訪問數(shù)據(jù)庫。
按建立應用程序的方式來說，我們原以為將它移植到Windows CE中是一項相對簡單的C語言編程練習。然而，我們不久便遇到好些困難。從粗心大意的錯誤開始，比如在基于Windows NT 的Windows CE仿真器上使用Microsoft Windows NT庫，接著又違背Windows CE的編程戒律，如"千萬不要給Unicode（國際標準組織10646標準）字符分配奇數(shù)內存地址"。
大約有百分之九十的問題或多或少地與Unicode有關。盡管Unicode編程不難，但是，當給單字節(jié)字符編寫代碼時，很容易出錯（我有過許多次錯誤）。
下面這些忠告是根據(jù)我們在Windows CE上編寫Raima 數(shù)據(jù)管理器的經驗總結出來的，但我相信，在做任何其它Windows CE程序之前，它們都值得借鑒。畢竟大多數(shù)Windows開發(fā)者，當他們創(chuàng)建第一個Windows CE應用程序時，真正運用的是已掌握的Win32知識。
1. 不要在仿真器上使用Windows NT庫
這里所討論的第一個錯誤實在太愚蠢了，但我還是陷了進去，也許你也會。當用Microsoft VC++（5.0版）創(chuàng)建一個Windows CE程序時，你會發(fā)現(xiàn)，包含路徑（include）、庫路徑（library）、及可執(zhí)行程序路徑被自動調整以匹配反應目標環(huán)境的選擇。因此，比如說為Windows CE模擬器建立應用程序時，你會發(fā)現(xiàn)，include路徑沒有指向Win32的包含文件（在VC目錄下），而是指向Windows CE包含文件（在WCE目錄下）。千萬別去修改。
由于Windows CE在Windows NT下運行，所以仿真器上運行的程序能夠調用任一Windows NT動態(tài)鏈接庫(DLL)中的函數(shù)，即使這個DLL不是模擬器的成員也一樣。顯然，這不是很好的事，因為相同的函數(shù)也許在手持PC(H/PC)或 Windows CE設備上不可用，而你的軟件最終要能在這些設備上運行。
第一次將非Unicode應用程序裝入Windows CE仿真器時，你會發(fā)現(xiàn)，許多正在使用的函數(shù)它都不支持，例如美國國家標準協(xié)會(ANSI)定義的字符函數(shù)strcpy()。這也許引誘你去鏈接Windows NT 運行時間庫，以便能解決所有問題。
如果你是剛開始用Windows CE編程，可能你能用的包含文件和庫文件是明顯的。答案就是，你不要采用那些在寫普通Win32或非Windows CE程序時使用的包含文件和庫文件。
2. 不要混淆TCHARs和bytes
如果你正在Windows CE上寫非Unicode應用程序，你或許要將所有的字符串從單個字符(chars)轉換為寬字符(widechars)（例如，C變量類型 whcar_t）。幾乎所有Windows CE支持的Win32和運行時間庫函數(shù)都要求寬字符變量。Windows 95不支持Unicode，然而，為了使程序代碼具有可移植性，你要盡可能采用tchar.h中定義的TCHAR類型，不要直接使用wchar_t。
TCHAR是定義為wchar_t還是char，取決于預處理器的符號UNICODE是否定義。同樣，所有有關字符串處理函數(shù)的宏，如_tcsncpy 宏，它是定義為Unicode函數(shù)wcsncpy還是定義為ANSI函數(shù)strncpy，取決于UNICODE是否定義。
在現(xiàn)存的Windows應用程序中，有些代碼也許暗示字符長為單字節(jié)。這在給字符串分配內存時經常用到，例如：
int myfunc(char *p)
{
char *pszFileName;
pszFileName = malloc(MAXFILELEN);
if(pszFileName)
strncpy(pszFileName, p, MAXFILELEN);
/*etc*/
在這段代碼中，分配的內存塊應該寫作(MAXFILELEN * sizeof(char))，但是大多數(shù)程序員喜歡將它簡化為MAXFILELEN，因為對于所有的平臺來說sizeof(char)的值等于1。然而，當你用TCHARS代替多個字符時，很容易忘記這種固有的概念，于是將代碼編寫成下面的形式：
int myfunc(TCHAR *p)
{
TCHAR *pszFileName;
PszFileName = (TCHAR*)malloc(MAXFILELEN);
If (pszFileName)
tcsncpy(pszFileName, p, MAXFILELEN);
/*etc*/
這是不行的。它馬上會導致出錯。這里的錯誤在于malloc函數(shù)中指定變量大小為bytes，然而_tcsncpy函數(shù)中使用的第三個變量卻指定為TCHARs而不是bytes。當UNICODE被定義時，一個TCHAR等于兩個字節(jié)數(shù)(bytes)。
上述代碼段應該改寫為：
int myfunc(TCHAR *p)
{
TCHAR *pszFileName;
PszFileName = (TCHAR*)malloc(MAXFILELEN * sizeof(TCHAR));
if(pszFileName)
tcsncpy(pszFileName, p, MAXFILELEN);
/*etc*/
3. 不要將Unicode 字符串放入奇數(shù)內存地址
在Intel系列處理器上，你可以在一奇數(shù)內存地址儲存任何變量或數(shù)組，不會導致任何致命的錯誤影響。但在H/PC上，這一點不一定能行 ? 你必須對大于一個字節(jié)的數(shù)據(jù)類型小心謹慎，包括定義為無符號短型（unsigned short）的wchar_t。當你設法訪問它們的時候，將它們置于奇地址會導致溢出。
編輯器經常在這些問題上提醒你。你無法管理堆棧變量地址，并且編輯器會檢查確定這些地址與變量類型是否相匹配。同樣，運行時間庫必須保證從堆中分配的內存總是滿足一個word邊界，所以你一般不必擔心那兩點。但是，如果應用程序含有用memcpy()函數(shù)拷貝內存區(qū)域的代碼，或者使用了某種類型的指針算術以確定內存地址，問題也許就出現(xiàn)了?？紤]下面的例子：
int send_name (TCHAR * pszName)
{
char *p, *q;
int nLen=(_tcslen(pszName) + 1) * sizeof(TCHAR);
p=maloc(HEADER_SIZE + nLen);
if(p)
{
q = p + HEADER_SIZE;
_tcscpy((TCHAR*)q, pszName);
}
/* etc */
這段代碼是從堆中分配內存并復制一個字符串，在字符串的開頭留一個HEADER_SIZE的大小。假設UNICODE定義了，那么該字符串就是一個 widechar字符串。如果HEADER_SIZE是一個偶數(shù)，這段代碼就會正常工作，但如果HEADER_SIZE為奇數(shù)，這段代碼就會出錯，因為q 指向的地址也將為奇數(shù)。
注意，當你在Intel系列處理器中的Windows CE仿真器上測試這段代碼時，這個問題是不會發(fā)生的。
在這個例子中，只要確保HEADER_SIZE為偶數(shù)，你就可以避免問題的發(fā)生。然而，在某些情況下你也許不能這么做。例如，如果程序是從一臺式PC輸入數(shù)據(jù)，你也許不得不采用事先定義過的二進制格式，盡管它對H/PC不適合。在這種情況下，你必須采用函數(shù)，這些函數(shù)用字符指針控制字符串而不是 TCHAR指針。如果你知道字符串的長度，就可以用memcpy()復制字符串。因此，采用逐個字節(jié)分析Unicode字符串的函數(shù)也許足以確定字符串在 widechars中的長度。
4. 在ANSI和Unicode字符串之間進行翻譯
如果你的Windows CE應用程序接口于臺式PC，也許你必須操作PC機中的ANSI字符串數(shù)據(jù)（例如，char字符串）。即使你在程序中只用到Unicode字符串，這都是事實。
你不能在Windows CE上處理一個ANSI字符串，因為沒有操縱它們的庫函數(shù)。最好的解決辦法是將ANSI字符串轉換成Unicode字符串用到H/PC上，然后再將 Unicode字符串轉換回ANSI字符串用到PC上。為了完成這些轉換，可采用MultiByteToWideChar()和 WideCharToMultiByte () Win32 API 函數(shù)。
5. 對于Windows CE 1.0的字符串轉換，劈開（hack）
在Windows CE 1.0 版本中，這些Win32API函數(shù)還沒有完成。所以如果你想既要支持CE 1.0又能支持CE 2.0，就必須采用其它函數(shù)。將ANSI字符串轉換成Unicode字符串可以用wsprintf()，其中第一個參數(shù)采用一widechar字符串，并且認識"%S"(大寫)，意思是一個字符串。由于沒有wsscanf() 和 wsprintfA()，你必須想別的辦法將Unicode字符串轉換回ANSI字符串。由于Windows CE 1.0不在國家語言支持(NLS)中，你也許得求助于hack，如下所示：
/*
Definition / prototypes of conversion functions
Multi-Byte (ANSI) to WideChar (Unicode)
atow() converts from ANSI to widechar
wtoa() converts from widechar to ANSI
*/
#if ( _WIN32_WCE >= 101)
#define atow(strA, strW, lenW) /
MultiByteToWidechar (CP_ACP, 0, strA, -1, strW, lenW)
#define wtoa(strW, strA, lenA) /
WideCharToMutiByte (CP_ACP, 0, strW, -1, strA, lenA, NULL, NULL)
#else /* _WIN32_WCE >= 101)*/
/*
MultiByteToWideChar () and WideCharToMultiByte() not supported o n Windows CE 1.0
*/
int atow(char *strA, wchar_t *strW, int lenW);
int wtoa(wchar_t *strW, char *strA, int lenA);
endif /* _WIN32_WCE >= 101*/
#if (_WIN32_WCE <101)
int atow(char *strA, wchar_t *strW, int lenW)
{
int len;
char *pA;
wchar_t *pW;
/*
Start with len=1, not len=0, as string length returned
must include null terminator, as in MultiByteToWideChar()
*/
for(pA=strA, pW=strW, len=1; lenW; pA++, pW++, lenW--, len++)
{
*pW = (lenW = =1) ? 0 : (wchar_t)( *pA);
if( ! (*pW))
break;
}
return len;
}
int wtoa(wxhar_t *strW, char *strA, int lenA)
{
int len;
char *pA;
wchar_t *pW;
/*
Start with len=1,not len=0, as string length returned
Must include null terminator, as in WideCharToMultiByte()
*/
for(pA=strA, pW=strW, len=1; lenA; pa++, pW++, lenA--, len++)
{
pA = (len==1)? 0 : (char)(pW);
if(!(*pA))
break;
}
return len;
}
#endif /*_WIN32_WCE<101*/
這種適合于Windows CE 1.0的實現(xiàn)辦法比使用wsprintf()函數(shù)要容易，因為使用wsprintf()函數(shù)更難以限制目標指針所指向的字符串的長度。
6. 選擇正確的字符串比較函數(shù)
如果你要分類Unicode標準字符串，你會有以下幾個函數(shù)可供選擇：
wcscmp(), wcsncmp(), wcsicmp(), 和wcsnicmp()
wcscoll(), wcsncoll(), wcsicoll(),和wcsnicoll()
CompareString()
第一類函數(shù)可用來對字符串進行比較，不參考當?shù)兀↙ocale）或外文字符。如果你永遠不想支持外文，或者你僅僅想測試一下兩個字符串的內容是否相同，這類函數(shù)非常好用。
第二類函數(shù)使用現(xiàn)有的當?shù)卦O置(current locale settings)（系統(tǒng)設置，除非你在字符串比較函數(shù)之前調用了wsetlocale()函數(shù)）來比較兩個字符串。這些函數(shù)也能正確分類外文字符。如果當?shù)氐淖址?C"（"C" locale）被選定，這些函數(shù)與第一類函數(shù)就具有了相同的功能。
第三類函數(shù)是Win32函數(shù) CompareString()。這個函數(shù)類似于第二類函數(shù)，但是它允許你指定當?shù)卦O置（the locale）作為一個參數(shù)，而不是使用現(xiàn)有的當?shù)卦O置(current locale settings)。CompareString()函數(shù)允許你選擇性地指定兩個字符串的長度。你可以將第二個參數(shù)設置為 NORM_IGNORECASE，從而使函數(shù)比較字符串時不比較大小寫。
通常，即使不將第二個參數(shù)設置為 NORM_IGNORECASE，CompareString()函數(shù)也不用來區(qū)分大小寫。我們經常用wcsncoll()函數(shù)來區(qū)分大小寫，除非使用當?shù)氐淖址?C"（"C" locale）。所以，在我們的代碼中，不使用CompareString()函數(shù)來區(qū)分大小寫，而用wcsncoll()函數(shù)來區(qū)分大小寫
7. 不要使用相對路徑
與Windows NT不一樣，Windows CE沒有當前目錄這個概念，因此，任何路徑只是相對于根目錄而言的。如果你的軟件給文件或目錄使用相對路徑，那么你很可能把它們移到別的地方了。例如，路徑"./abc"在Windows CE中被當作"/abc"看待。
8．移走了對calloc()和 time()函數(shù)的調用
C運行庫中的calloc()函數(shù)不能使用，但是malloc()函數(shù)可以代替calloc()函數(shù)。并且不要忘記，calloc()函數(shù)初始化時分配的內存為零，而malloc()函數(shù)不一樣。同樣，time()函數(shù)也不能使用，但你可以使用Win32函數(shù)GetSystemTime()函數(shù)代替 time()函數(shù)。
經過以上的警告后，你會高興地學習最后令你驚訝的兩點忠告。
9. 不需要改變Win32 輸入/輸出（I/O）文件的調用
Win32的輸入輸出函數(shù)，Windows CE也支持。允許你象訪問Win32文件系統(tǒng)那樣訪問對象。CreateFile()函數(shù)在Windows CE中不能辯認標志FILE_FLAG_RANDOM_ACCESS，但是這個標志僅用作可選的磁盤訪問，并且不影響函數(shù)調用的功能。
10. 不要擔心字節(jié)的狀態(tài)
當我們把應用程序寫入Windows CE時，有了一個美好的發(fā)現(xiàn)，那就是Windows CE的數(shù)字數(shù)據(jù)類型的字節(jié)狀態(tài)與Intel結構的字節(jié)狀態(tài)一樣，在所有的處理器上，Windows CE均支持。
幾乎象所有的數(shù)據(jù)庫引擎一樣，Raima數(shù)據(jù)庫管理器在數(shù)據(jù)庫文件中以二進制形式保存數(shù)字數(shù)據(jù)。這就意味一個記錄無論何時寫入數(shù)據(jù)庫或從數(shù)據(jù)庫讀出，均被當作一系列的字節(jié)來處理，不管它域的內容。只要數(shù)據(jù)庫文件不要傳給別的任何系統(tǒng)，數(shù)字數(shù)據(jù)的字節(jié)狀態(tài)問題就解決了。如果數(shù)據(jù)庫文件被一個來自原始系統(tǒng)且?guī)в胁煌止?jié)狀態(tài)的處理器訪問，數(shù)字數(shù)據(jù)將被誤解。
無論何時，當你在擁有不同處理器的機器上傳輸文件時，就會出現(xiàn)這個問題。在這個問題上，值得高興的是所有類型的處理器都使用相同的字節(jié)狀態(tài)。
在使用Windows CE時，這10點忠告應該引起你足夠的重視，避免學習時走彎路。
為了學會更多的Windows CE開發(fā)工具，請訪問Microfoft Windows CE Toolkits站點：
http://msdn.microsoft.com/cetools/ 
