WinCE設(shè)計開發(fā)常見問題（WinCE開發(fā)特性及忠告）

 最近一段時間，移動設(shè)備開發(fā)越來越多的成為了程序員社區(qū)的話題。移動設(shè)備主要包括智能手機和PDA，是嵌入式開發(fā)中很重要的一個方向。在智能手機領(lǐng)域被大多數(shù)手機廠商支持的J2ME無疑是領(lǐng)頭羊，微軟CE平臺的SmartPhone也逐漸成為關(guān)注焦點。一直不溫不火的PDA市場，也在行業(yè)應(yīng)用領(lǐng)域有所收獲，Pocket PC由于其開發(fā)與Windows平臺的一致性而得到了開發(fā)人員的青睞。

在長期關(guān)注程序員論壇的過程中，我發(fā)現(xiàn)由于Windows CE開發(fā)的獨特性，加之多個版本并存、缺乏中文參考資料，所以論壇上充斥著大量相同的入門問題。我希望在這里能夠為剛轉(zhuǎn)入Windows CE開發(fā)的程序員明晰一些概念，將現(xiàn)有的Windows CE版本與開發(fā)工具之間的關(guān)系給大家解釋清楚。

Windows CE與平臺開發(fā)

Windows CE是微軟為嵌入式設(shè)備打造的操作系統(tǒng)，而嵌入式設(shè)備可謂多種多樣，這就要求CE操作系統(tǒng)必須是可定制的，所以微軟將Windows CE設(shè)計為模塊化的操作系統(tǒng)。說簡單點，我們可以把Windows CE想像成一盒積木，你可以用積木搭建出任何物體，但不一定要把所有的積木都用上。

Windows CE搭建出來的物體就是平臺，是適應(yīng)某種有固定標(biāo)準(zhǔn)的嵌入式設(shè)備的操作系統(tǒng)子集，最著名的平臺就是Pocket PC了，是提供給沒有鍵盤的掌上電腦使用的平臺。由于平臺和硬件的一致性，所以有時候我們也用平臺的名稱來稱呼整個系統(tǒng)——硬件與操作系統(tǒng)的總和。

我們也可以自己開發(fā)平臺，開發(fā)工具是微軟提供的Platform Builder，Platform Builder的版本號是和Windows CE的版本號一致的。

更多程序員關(guān)心的是應(yīng)用程序的開發(fā)，而應(yīng)用程序開發(fā)是針對特定平臺的，我們在開發(fā)之前必須安裝目標(biāo)平臺的SDK，才能夠開發(fā)出適應(yīng)目標(biāo)平臺的開發(fā)工具。

Windows CE開發(fā)環(huán)境綜述

初學(xué)者另外一個比較糊涂的概念是版本的問題，現(xiàn)在市面上能夠見到Windows CE的兩代產(chǎn)品，它們的內(nèi)核分別基于Windows CE 3.0和Windows CE.NET(即4.0)。

微軟將今年剛面世的Pocket PC 2003和Smart Phone 2003統(tǒng)稱為Windows Mobile 2003，我們大多數(shù)時候還是習(xí)慣地沿用老稱謂。

而市面上經(jīng)常見到的Pocket PC 2002是基于Windows CE 3.0的平臺，而Pocket PC 2003則是基于Windows CE.NET的平臺，需要注意的是，Pocket PC 2003的內(nèi)核是Windows CE.NET 4.2。而SmartPhone2003也是基于Windows CE.NET的。SmartPhone的最初版本是2002，基于Windows CE 3.0的，但是微軟沒有推出SmartPhone2002的中文版。

清晰了平臺與CE之間的關(guān)系，解釋平臺與開發(fā)工具之間的關(guān)系就很容易了。微軟提供給應(yīng)用程序開發(fā)者的工具包括：Embedded Visual Tools 3.0，其中包括Embedded Visual C 3.0和Embedded Visual Basic 3.0;Embedded Visual C 4.0和Visual Studio.NET。

開發(fā)工具的版本號是與Windows CE的版本號對應(yīng)的。EVC3.0和EVB3.0是用來開發(fā)基于Windows CE 3.0平臺的應(yīng)用程序的，比較常見的平臺有：Pocket PC 2002、Pocket PC 2000、Palm-size PC、HPC。而EVC4.0是用來開發(fā)Windows CE.NET平臺的程序的，主要包括Pocket PC 2003和SmartPhone 2003。

Visual Studio.NET針對嵌入式設(shè)備開發(fā)需要SDE的支持，而VS.NET 2003中包括了SDE，不需要另外安裝。Visual Studio.NET開發(fā)的程序需要目標(biāo)平臺支持.NET Compact Framework?，F(xiàn)在支持.NET Compact Framework的平臺有Pocket PC 2002和Pocket PC 2003。這里需要注意的是SmartPhone 2003是不支持.NET Compact Framework的。

EVB開發(fā)入門

微軟已經(jīng)宣布EVB不再支持Windows CE.NET，所以EVB的最終版本是3.0。但由于EVB的易上手性和快速開發(fā)的特點，在VS.NET橫空出世之前，它成為Windows CE平臺上快速開發(fā)的不二之選?，F(xiàn)在EVB仍然適合Windows CE 3.0平臺上小型應(yīng)用程序的快速開發(fā)。如果您不是專職的Windows CE程序員，而只是需要在Windows CE平臺上開發(fā)整個系統(tǒng)的一部分，那么EVB可以讓您用很短的時間開發(fā)出您想要的程序。

EVB的開發(fā)環(huán)境的搭建也是十分簡單，您可以從微軟的網(wǎng)站上下載EVT 2002，其中包含了EVC 3.0、EVB 3.0和Pocket PC 2002 SDK和SmartPhone 2002 SDK。按照提示將EVB和Pocket PC 2002 SDK安裝好后就可以進行開發(fā)了。SDK中包含模擬器，在沒有實際設(shè)備的情況下，可以利用模擬器來調(diào)試程序。

這里需要注意的是，開發(fā)環(huán)境和模擬器之間是通過網(wǎng)絡(luò)連接協(xié)議進行通訊的，所以開發(fā)所用的計算機上必須有一個活動的網(wǎng)絡(luò)連接。如果沒有，可以安裝微軟的虛擬網(wǎng)卡。

EVB的開發(fā)環(huán)境與VB類似，因為Windows CE應(yīng)用程序需要在模擬器或者實際設(shè)備上調(diào)試，所以我們必須選擇程序的輸出目標(biāo)。如果您選擇了Emulation，在您按下運行(或F5)后，EVB將自動啟動模擬器，并把程序下載到模擬器中。

由于新的Windows CE.NET將不再支持EVB，微軟建議EVB程序員使用VB.NET開發(fā)新的程序，而對于原有的EVB程序也給出了遷移路徑，關(guān)于這方面的論述，您可以參考MSDN文章《Moving from eMbedded Visual Basic to Visual Basic .NET》。

EVC開發(fā)入門

無論是Win32平臺還是WinCE平臺，Visual C 都是一個強大的開發(fā)工具。而EVC也是WinCE上的主流開發(fā)工具。EVC支持MFC類庫的子集，可以給開發(fā)者提供最強大的支持，也使Win32平臺上的VC程序員可以很容易地遷移到WinCE平臺上。但由于MFC類庫需要一個DLL，所以對某些存儲空間有限的嵌入式設(shè)備來說，這是個很大的負擔(dān)，所以SmartPhone就不支持MFC。

說這么多，讓我們來創(chuàng)建一個EVC的工程。是不是和VC很像，需要提醒大家注意的是，由于嵌入式設(shè)備支持的CPU種類很多，我們在選擇創(chuàng)建工程類型的同時，也要把該工程所支持的CPU類型選擇好。創(chuàng)建工程的過程和VC是一樣的。當(dāng)然不同的平臺支持的工程類型是不同的，比如Pocket PC 2003有支持MFC和API的兩種工程，而SmartPhone 2003則只有支持API的一種工程。

EVC中比VC環(huán)境中多了一行下拉菜單的選項，分別用來選擇：工程、SDK、CPU類型和輸出設(shè)備。以Pocket PC為例，在實際設(shè)備上調(diào)試應(yīng)該選擇Win32(WCE ARMV4)Debug ，而在模擬器上則需要選擇Win32(WCE emulator)Debug。

VS.net開發(fā)入門[!--empirenews.page--]

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

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

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

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

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

Windows CE 開發(fā)的忠告

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

按建立應(yīng)用程序的方式來說，我們原以為將它移植到Windows CE中是一項相對簡單的C語言編程練習(xí)。然而，我們不久便遇到好些困難。從粗心大意的錯誤開始，比如在基于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é)字符編寫代碼時，很容易出錯(我有過許多次錯誤)。

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

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

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

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

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

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

不要混淆TCHARs和bytes

如果你正在Windows CE上寫非Unicode應(yīng)用程序，你或許要將所有的字符串從單個字符(chars)轉(zhuǎn)換為寬字符(widechars)(例如，C變量類型whcar_t)。幾乎所有Windows CE支持的Win32和運行時間庫函數(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)存時經(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，因為對于所有的平臺來說sizeof(char)的值等于1。然而，當(dāng)你用TCHARS代替多個字符時，很容易忘記這種固有的概念，于是將代碼編寫成下面的形式：

int myfunc(TCHAR *p)

{

TCHAR *pszFileName;

PszFileName = (TCHAR*)malloc(MAXFILELEN);

If (pszFileName)

tcsncpy(pszFileName, p, MAXFILELEN);

/*etc*/

這是不行的。它馬上會導(dǎo)致出錯。這里的錯誤在于malloc函數(shù)中指定變量大小為bytes，然而_tcsncpy函數(shù)中使用的第三個變量卻指定為TCHARs而不是bytes。當(dāng)UNICODE被定義時，一個TCHAR等于兩個字節(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)存地址

在Intel系列處理器上，你可以在一奇數(shù)內(nèi)存地址儲存任何變量或數(shù)組，不會導(dǎo)致任何致命的錯誤影響。但在H/PC上，這一點不一定能行 ? 你必須對大于一個字節(jié)的數(shù)據(jù)類型小心謹(jǐn)慎，包括定義為無符號短型(unsigned short) 的wchar_t。當(dāng)你設(shè)法訪問它們的時候，將它們置于奇地址會導(dǎo)致溢出。[!--empirenews.page--]

編輯器經(jīng)常在這些問題上提醒你。你無法管理堆棧變量地址，并且編輯器會檢查確定這些地址與變量類型是否相匹配。同樣，運行時間庫必須保證從堆中分配的內(nèi)存總是滿足一個word邊界 ，所以你一般不必擔(dān)心那兩點。但是，如果應(yīng)用程序含有用memcpy()函數(shù)拷貝內(nèi)存區(qū)域的代碼，或者使用了某種類型的指針?biāo)阈g(shù)以確定內(nèi)存地址，問題也許就出現(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 */

這段代碼是從堆中分配內(nèi)存并復(fù)制一個字符串，在字符串的開頭留一個HEADER_SIZE的大小。假設(shè)UNICODE定義了，那么該字符串就是一個widechar字符串。如果HEADER_SIZE是一個偶數(shù)，這段代碼就會正常工作，但如果HEADER_SIZE為奇數(shù)，這段代碼就會出錯，因為q指向的地址也將為奇數(shù)。

注意，當(dāng)你在Intel系列處理器中的Windows CE仿真器上測試這段代碼時，這個問題是不會發(fā)生的。

在這個例子中，只要確保HEADER_SIZE為偶數(shù)，你就可以避免問題的發(fā)生。然而，在某些情況下你也許不能這么做。例如，如果程序是從一臺式PC輸入數(shù)據(jù)，你也許不得不采用事先定義過的二進制格式，盡管它對H/PC不適合。在這種情況下，你必須采用函數(shù)，這些函數(shù)用字符指針控制字符串而不是TCHAR指針。如果你知道字符串的長度，就可以用memcpy()復(fù)制字符串。因此，采用逐個字節(jié)分析Unicode字符串的函數(shù)也許足以確定字符串在widechars中的長度。

在ANSI和Unicode字符串之間進行翻譯

如果你的Windows CE應(yīng)用程序接口于臺式PC，也許你必須操作PC機中的ANSI字符串?dāng)?shù)據(jù)(例如，char字符串)。即使你在程序中只用到Unicode字符串，這都是事實。

你不能在Windows CE上處理一個ANSI字符串，因為沒有操縱它們的庫函數(shù)。最好的解決辦法是將ANSI字符串轉(zhuǎn)換成Unicode字符串用到H/PC上，然后再將Unicode字符串轉(zhuǎn)換回ANSI字符串用到PC上。為了完成這些轉(zhuǎn)換，可采用MultiByteToWideChar()和WideCharToMultiByte () Win32 API 函數(shù)。

對于Windows CE 1.0的字符串轉(zhuǎn)換，劈開(hack)

在Windows CE 1.0 版本中，這些Win32API函數(shù)還沒有完成。所以如果你想既要支持CE 1.0又能支持CE 2.0，就必須采用其它函數(shù)。將ANSI字符串轉(zhuǎn)換成Unicode字符串可以用wsprintf()，其中第一個參數(shù)采用一widechar字符串，并且認(rèn)識"%S"(大寫)，意思是一個字符串。由于沒有wsscanf() 和 wsprintfA()，你必須想別的辦法將Unicode字符串轉(zhuǎn)換回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ù)更難以限制目標(biāo)指針?biāo)赶虻淖址拈L度。

選擇正確的字符串比較函數(shù)

如果你要分類Unicode標(biāo)準(zhǔn)字符串，你會有以下幾個函數(shù)可供選擇：

wcscmp(), wcsncmp(), wcsicmp(), 和wcsnicmp()

wcscoll(), wcsncoll(), wcsicoll(),和wcsnicoll()

CompareString()

第一類函數(shù)可用來對字符串進行比較，不參考當(dāng)?shù)?Locale)或外文字符。如果你永遠不想支持外文，或者你僅僅想測試一下兩個字符串的內(nèi)容是否相同，這類函數(shù)非常好用。

第二類函數(shù)使用現(xiàn)有的當(dāng)?shù)卦O(shè)置(current locale settings)(系統(tǒng)設(shè)置，除非你在字符串比較函數(shù)之前調(diào)用了wsetlocale()函數(shù))來比較兩個字符串。這些函數(shù)也能正確分類外文字符。如果當(dāng)?shù)氐淖址?quot;C"("C" locale)被選定，這些函數(shù)與第一類函數(shù)就具有了相同的功能。

第三類函數(shù)是Win32函數(shù)CompareString()。這個函數(shù)類似于第二類函數(shù)，但是它允許你指定當(dāng)?shù)卦O(shè)置(the locale)作為一個參數(shù)，而不是使用現(xiàn)有的當(dāng)?shù)卦O(shè)置(current locale settings)。CompareString()函數(shù)允許你選擇性地指定兩個字符串的長度。你可以將第二個參數(shù)設(shè)置為NORM_IGNORECASE，從而使函數(shù)比較字符串時不比較大小寫。[!--empirenews.page--]

通常，即使不將第二個參數(shù)設(shè)置為NORM_IGNORECASE，CompareString()函數(shù)也不用來區(qū)分大小寫。我們經(jīng)常用wcsncoll()函數(shù)來區(qū)分大小寫，除非使用當(dāng)?shù)氐淖址?quot;C"("C" locale)。所以，在我們的代碼中，不使用CompareString()函數(shù)來區(qū)分大小寫，而用wcsncoll()函數(shù)來區(qū)分大小寫

不要使用相對路徑

與Windows NT不一樣，Windows CE沒有當(dāng)前目錄這個概念，因此，任何路徑只是相對于根目錄而言的。如果你的軟件給文件或目錄使用相對路徑，那么你很可能把它們移到別的地方了。例如，路徑".\abc"在Windows CE中被當(dāng)作"\abc"看待。

移走了對calloc()和 time()函數(shù)的調(diào)用

C運行庫中的calloc()函數(shù)不能使用，但是malloc()函數(shù)可以代替calloc()函數(shù)。并且不要忘記，calloc()函數(shù)初始化時分配的內(nèi)存為零，而malloc()函數(shù)不一樣。同樣，time()函數(shù)也不能使用，但你可以使用Win32函數(shù)GetSystemTime()函數(shù)代替time()函數(shù)。

經(jīng)過以上的警告后，你會高興地學(xué)習(xí)最后令你驚訝的兩點忠告。

不需要改變Win32 輸入/輸出(I/O)文件的調(diào)用

Win32的輸入輸出函數(shù)，Windows CE也支持。允許你象訪問Win32文件系統(tǒng)那樣訪問對象。CreateFile()函數(shù)在Windows CE中不能辯認(rèn)標(biāo)志FILE_FLAG_RANDOM_ACCESS，但是這個標(biāo)志僅用作可選的磁盤訪問，并且不影響函數(shù)調(diào)用的功能。

不要擔(dān)心字節(jié)的狀態(tài)

當(dāng)我們把應(yīng)用程序?qū)懭隬indows CE時，有了一個美好的發(fā)現(xiàn)，那就是Windows CE的數(shù)字?jǐn)?shù)據(jù)類型的字節(jié)狀態(tài)與Intel結(jié)構(gòu)的字節(jié)狀態(tài)一樣，在所有的處理器上，Windows CE均支持。

幾乎象所有的數(shù)據(jù)庫引擎一樣，Raima數(shù)據(jù)庫管理器在數(shù)據(jù)庫文件中以二進制形式保存數(shù)字?jǐn)?shù)據(jù)。這就意味一個記錄無論何時寫入數(shù)據(jù)庫或從數(shù)據(jù)庫讀出，均被當(dāng)作一系列的字節(jié)來處理，不管它域的內(nèi)容。只要數(shù)據(jù)庫文件不要傳給別的任何系統(tǒng)，數(shù)字?jǐn)?shù)據(jù)的字節(jié)狀態(tài)問題就解決了。如果數(shù)據(jù)庫文件被一個來自原始系統(tǒng)且?guī)в胁煌止?jié)狀態(tài)的處理器訪問，數(shù)字?jǐn)?shù)據(jù)將被誤解。

無論何時，當(dāng)你在擁有不同處理器的機器上傳輸文件時，就會出現(xiàn)這個問題。在這個問題上，值得高興的是所有類型的處理器都使用相同的字節(jié)狀態(tài)。

在使用Windows CE時，這些忠告應(yīng)該引起你足夠的重視，避免學(xué)習(xí)時走彎路。