?Microsoft ? Windows ? CE ? 編程的十點忠告???
? 最近兩周我們花了大部分時間將已有的應用程序移植到Microsoft ? Windows ? CE中。 ?
? 一般說來，這個計劃不是太難。我們起步于Microsoft ? Win32代碼，當然 ? Windows ? CE是 ?
? 基于Win32應用程序接口（API）的。有利的是，我們的應用程序（即Raima ? 數據管理器 ?
? ）有方便的使用接口，并包含一個大約由150個子函數組成的庫，這些函數都是由C語言 ?
? 寫成，可以用來創建、管理和訪問數據庫。 ?
? 　　按建立應用程序的方式來說，我們原以為將它移植到Windows ? CE中是一項相對簡單 ?
? 的C語言編程練習。然而，我們不久便遇到好些困難。從粗心大意的錯誤開始，比如在基 ?
? 于Windows ? NT ? 的Windows ? CE仿真器上使用Microsoft ? Windows ? NT庫，接著又違背Windo ?
? ws ? CE的編程戒律，如"千萬不要給Unicode（國際標準組織10646標準）字符分配奇數內 ?
? 存地址"。 ?
? 　　大約有百分之九十的問題或多或少地與Unicode有關。盡管Unicode編程不難，但是 ?
? ，當給單字節字符編寫代碼時，很容易出錯（我有過許多次錯誤）。 ?
? 　　下面這些忠告是根據我們在Windows ? CE上編寫Raima ? 數據管理器的經驗總結出來的 ?
? ，但我相信，在做任何其它Windows ? CE程序之前，它們都值得借鑒。畢竟大多數Window ?
? s開發者，當他們創建第一個Windows ? CE應用程序時，真正運用的是已掌握的Win32知識 ?
? 。 ?
? 1. ? 不要在仿真器上使用Windows ? NT庫 ?
? 　　這里所討論的第一個錯誤實在太愚蠢了，但我還是陷了進去，也許你也會。當用Mi ?
? crosoft ? VC++（5.0版）創建一個Windows ? CE程序時，你會發現，包含路徑（include） ?
? 、 ? 庫路徑（library）、及可執行程序路徑被自動調整以匹配反應目標環境的選擇。因 ?
? 此，比如說為Windows ? CE模擬器建立應用程序時，你會發現，include路徑沒有指向Win ?
? 32的包含文件（在VC目錄下），而是指向Windows ? CE包含文件（在WCE目錄下）。千萬別 ?
? 去修改。 ?
? 　　由于Windows ? CE在Windows ? NT下運行，所以仿真器上運行的程序能夠調用任一Wind ?
? ows ? NT動態鏈接庫(DLL)中的函數，即使這個DLL不是模擬器的成員也一樣。顯然，這不 ?
? 是很好的事，因為相同的函數也許在手持PC(H/PC)或Windows ? CE設備上不可用，而你的 ?
? 軟件最終要能在這些設備上運行。 ?
? 　　第一次將非Unicode應用程序裝入Windows ? CE仿真器時，你會發現，許多正在使用的 ?
? 函數它都不支持，例如美國國家標準協會(ANSI)定義的字符函數strcpy()。這也許引誘 ?
? 你去鏈接Windows ? NT ? 運行時間庫，以便能解決所有問題。 ?
? 　　如果你是剛開始用Windows ? CE編程，可能你能用的包含文件和庫文件是明顯的。答 ?
? 案就是，你不要采用那些在寫普通Win32或非Windows ? CE程序時使用的包含文件和庫文件 ?
? 。 ?
? 2. ? 不要混淆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函數中指定變量大小為by ?
? tes，然而_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*/ ?
? 3. ? 不要將Unicode ? 字符串放入奇數內存地址 ?
? 　　在Intel系列處理器上，你可以在一奇數內存地址儲存任何變量或數組，不會導致任 ?
? 何致命的錯誤影響。但在H/PC上，這一點不一定能行 ? ? ? 你必須對大于一個字節的數據類 ?
? 型小心謹慎，包括定義為無符號短型（unsigned ? short） ? 的wchar_t。當你設法訪問它 ?
? 們的時候，將它們置于奇地址會導致溢出。 ?
? 　　編輯器經常在這些問題上提醒你。你無法管理堆棧變量地址，并且編輯器會檢查確 ?
? 定這些地址與變量類型是否相匹配。同樣，運行時間庫必須保證從堆中分配的內存總是 ?
? 滿足一個word邊界 ? ，所以你一般不必擔心那兩點。但是，如果應用程序含有用memcpy( ?
? )函數拷貝內存區域的代碼，或者使用了某種類型的指針算術以確定內存地址，問題也許 ?
? 就出現了。考慮下面的例子： ?
? 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_SIZ ?
? E的大小。假設UNICODE定義了，那么該字符串就是一個widechar字符串。如果HEADER_S ?
? IZE是一個偶數，這段代碼就會正常工作，但如果HEADER_SIZE為奇數，這段代碼就會出 ?
? 錯，因為q指向的地址也將為奇數。 ?
? 　　注意，當你在Intel系列處理器中的Windows ? CE仿真器上測試這段代碼時，這個問題 ?
? 是不會發生的。 ?
? 　　在這個例子中，只要確保HEADER_SIZE為偶數，你就可以避免問題的發生。然而，在 ?
? 某些情況下你也許不能這么做。例如，如果程序是從一臺式PC輸入數據，你也許不得不 ?
? 采用事先定義過的二進制格式，盡管它對H/PC不適合。在這種情況下，你必須采用函數 ?
? ，這些函數用字符指針控制字符串而不是TCHAR指針。如果你知道字符串的長度，就可以 ?
? 用memcpy()復制字符串。因此，采用逐個字節分析Unicode字符串的函數也許足以確定字 ?
? 符串在widechars中的長度。??
4. ? 在ANSI和Unicode字符串之間進行翻譯 ?
? 　　如果你的Windows ? CE應用程序接口于臺式PC，也許你必須操作PC機中的ANSI字符串 ?
? 數據（例如，char字符串）。即使你在程序中只用到Unicode字符串，這都是事實。 ?
? 　　你不能在Windows ? CE上處理一個ANSI字符串，因為沒有操縱它們的庫函數。最好的 ?
? 解決辦法是將ANSI字符串轉換成Unicode字符串用到H/PC上，然后再將Unicode字符串轉 ?
? 換回ANSI字符串用到PC上。為了完成這些轉換，可采用MultiByteToWideChar()和WideC ?
? harToMultiByte ? () ? Win32 ? API ? 函數。 ?
? 5. ? 對于Windows ? CE ? 1.0的字符串轉換，劈開（hack） ?
? 　　在Windows ? CE ? 1.0 ? 版本中，這些Win32API函數還沒有完成。所以如果你想既要支持 ?
? CE ? 1.0又能支持CE ? 2.0，就必須采用其它函數。將ANSI字符串轉換成Unicode字符串可以 ?
? 用wsprintf()，其中第一個參數采用一widechar字符串，并且認識"%S"(大寫)，意思是 ?
? 一個字符串。由于沒有wsscanf() ? 和 ? wsprintfA()，你必須想別的辦法將Unicode字符串 ?
? 轉換回ANSI字符串。由于Windows ? CE ? 1.0不在國家語言支持(NLS)中，你也許得求助于h ?
? ack，如下所示： ?
? /* ?
? 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 ? on ? 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的實現辦法比使用wsprintf()函數要容易，因為使用ws ?
? printf()函數更難以限制目標指針所指向的字符串的長度。 ?
? 6. ? 選擇正確的字符串比較函數 ?
? 　　如果你要分類Unicode標準字符串，你會有以下幾個函數可供選擇： ?
? wcscmp(), ? wcsncmp(), ? wcsicmp(), ? 和wcsnicmp() ?
? wcscoll(), ? wcsncoll(), ? wcsicoll(),和wcsnicoll() ?
? CompareString() ?
? 　　第一類函數可用來對字符串進行比較，不參考當地（Locale）或外文字符。如果你 ?
? 永遠不想支持外文，或者你僅僅想測試一下兩個字符串的內容是否相同，這類函數非常 ?
? 好用。 ?
? 　　第二類函數使用現有的當地設置(current ? locale ? settings)（系統設置，除非你在 ?
? 字符串比較函數之前調用了wsetlocale()函數）來比較兩個字符串。這些函數也能正確 ?
? 分類外文字符。如果當地的字符"C"（"C" ? locale）被選定，這些函數與第一類函數就具 ?
? 有了相同的功能。 ?
? 　　第三類函數是Win32函數CompareString()。這個函數類似于第二類函數，但是它允 ?
? 許你指定當地設置（the ? locale）作為一個參數，而不是使用現有的當地設置(current ?
? locale ? settings)。CompareString()函數允許你選擇性地指定兩個字符串的長度。你 ?
? 可以將第二個參數設置為NORM_IGNORECASE，從而使函數比較字符串時不比較大小寫。 ?
? 　　通常，即使不將第二個參數設置為NORM_IGNORECASE，CompareString()函數也不用 ?
? 來區分大小寫。我們經常用wcsncoll()函數來區分大小寫，除非使用當地的字符"C"（" ?
? C" ? locale）。所以，在我們的代碼中，不使用CompareString()函數來區分大小寫，而 ?
? 用wcsncoll()函數來區分大小寫 ?
? 7. ? 不要使用相對路徑 ?
? 　　與Windows ? NT不一樣，Windows ? CE沒有當前目錄這個概念，因此，任何路徑只是相 ?
? 對于根目錄而言的。如果你的軟件給文件或目錄使用相對路徑，那么你很可能把它們移 ?
? 到別的地方了。例如，路徑".\abc"在Windows ? CE中被當作"\abc"看待。 ?
? 8．移走了對calloc()和 ? time()函數的調用 ?
? 　　C運行庫中的calloc()函數不能使用，但是malloc()函數可以代替calloc()函數。并 ?
? 且不要忘記，calloc()函數初始化時分配的內存為零，而malloc()函數不一樣。同樣， ?
? time()函數也不能使用，但你可以使用Win32函數GetSystemTime()函數代替time()函數 ?
? 。 ?
? 　　經過以上的警告后，你會高興地學習最后令你驚訝的兩點忠告。 ?
? 9. ? 不需要改變Win32 ? 輸入/輸出（I/O）文件的調用 ?
? 　　Win32的輸入輸出函數，Windows ? CE也支持。允許你象訪問Win32文件系統那樣訪問 ?
? 對象。CreateFile()函數在Windows ? CE中不能辯認標志FILE_FLAG_RANDOM_ACCESS，但是 ?
? 這個標志僅用作可選的磁盤訪問，并且不影響函數調用的功能。 ?
? 10. ? 不要擔心字節的狀態 ?
? 　　當我們把應用程序寫入Windows ? CE時，有了一個美好的發現，那就是Windows ? CE的 ?
? 數字數據類型的字節狀態與Intel結構的字節狀態一樣，在所有的處理器上，Windows ? C ?
? E均支持。 ?
? 　　幾乎象所有的數據庫引擎一樣，Raima數據庫管理器在數據庫文件中以二進制形式保 ?
? 存數字數據。這就意味一個記錄無論何時寫入數據庫或從數據庫讀出，均被當作一系列 ?
? 的字節來處理，不管它域的內容。只要數據庫文件不要傳給別的任何系統，數字數據的 ?
? 字節狀態問題就解決了。如果數據庫文件被一個來自原始系統且帶有不同字節狀態的處 ?
? 理器訪問，數字數據將被誤解。 ?
? 　　無論何時，當你在擁有不同處理器的機器上傳輸文件時，就會出現這個問題。在這 ?
? 個問題上，值得高興的是所有類型的處理器都使用相同的字節狀態。 ?
? 　　在使用Windows ? CE時，這10點忠告應該引起你足夠的重視，避免學習時走彎路