Tuesday, December 18, 2007
注：(x)转脓(chung)文章Q版权归原作者所有?br>
最q一D|_(d)Ud讑֤开发越来越多的成ؓ(f)?jin)程序员C的话题。移动设备主要包括智能手机和PDAQ是嵌入式开发中很重要的一个方向。在手机领域被大多数手机厂商支持的J2ME无疑是领头羊Q微软CEq_的SmartPhone也逐渐成ؓ(f)x(chng)焦点。一直不温不火的PDA?jng)场Q也在行业应用领域有所收获QPocket PC׃其开发与Windowsq_的一致性而得C(jin)开发h员的青睐?nbsp;
在长期关注程序员论坛的过E中Q我发现׃Windows CE开发的独特性，加之多个版本q存、缺乏中文参考资料，所以论坛上充斥着大量相同的入门问题。我希望在这里能够ؓ(f)刚{入Windows CE开发的E序员明C些概念，现有的Windows CE版本与开发工具之间的关系l大家解释清楚?br>
1. Windows CE与^台开?br>
Windows CE是微软ؓ(f)嵌入式设备打造的操作pȝQ而嵌入式讑֤可谓多种多样Q这p求CE操作pȝ必须是可定制的，所以微软将Windows CE设计为模块化的操作系l。说单点Q我们可以把Windows CE惛_成一盒积木，你可以用U木搭徏ZQ何物体，但不一定要把所有的U木都用上?br>
Windows CE搭徏出来的物体就是^収ͼ是适应某种有固定标准的嵌入式设备的操作pȝ子集Q最著名的^台就是Pocket PC?jin)，是提供给没有键盘的掌上?sh)脑用的q_。由于^台和g的一致性，所以有时候我们也用^台的名称来称呼整个系l——硬件与操作pȝ的d?br>
我们也可以自己开发^収ͼ开发工h微Y提供的Platform BuilderQPlatform Builder的版本号是和W(xu)indows CE的版本号一致的?br>
更多E序员关?j)的是应用程序的开发，而应用程序开发是针对特定q_的，我们在开发之前必d装目标^台的SDKQ才能够开发出适应目标q_的开发工兗?br>
Windows CE开发环境综q?br>
初学者另外一个比较糊涂的概念是版本的问题Q现在市(jng)面上能够见到Windows CE的两代品，它们的内核分别基于Windows CE 3.0和W(xu)indows CE.NETQ即4.0Q?br>
微Y今q刚面世的Pocket PC 2003和Smart Phone 2003l称为Windows Mobile 2003Q我们大多数时候还是习(fn)惯地沿用老称谓?br>
而市(jng)面上l常见到的Pocket PC 2002是基于Windows CE 3.0的^収ͼ而Pocket PC 2003则是ZWindows CE.NET的^収ͼ需要注意的是，Pocket PC 2003的内核是Windows CE.NET 4.2。而SmartPhone2003也是ZWindows CE.NET的。SmartPhone的最初版本是2002Q基于Windows CE 3.0的，但是微Y没有推出SmartPhone2002的中文版?br>
清晰?jin)^CCE之间的关p，解释q_与开发工具之间的关系很Ҏ(gu)?jin)。微软提供给应用E序开发者的工具包括QEmbedded Visual Tools 3.0Q其中包括Embedded Visual C++ 3.0和Embedded Visual Basic 3.0QEmbedded Visual C++ 4.0和Visual Studio.NET?br>
开发工L(fng)版本h与Windows CE的版本号对应的。EVC3.0和EVB3.0是用来开发基于Windows CE 3.0q_的应用程序的Q比较常见的q_有：(x)Pocket PC 2002、Pocket PC 2000、Palm-size PC、HPC。而EVC4.0是用来开发Windows CE.NETq_的程序的Q主要包括Pocket PC 2003和SmartPhone 2003?br>
Visual Studio.NET针对嵌入式设备开发需要SDE的支持，而VS.NET 2003中包括了(jin)SDEQ不需要另外安装。Visual Studio.NET开发的E序需要目标^台支?NET Compact Framework。现在支?NET Compact Framework的^台有Pocket PC 2002和Pocket PC 2003。这里需要注意的是SmartPhone 2003是不支持.NET Compact Framework的?br>2. EVB/EVC开发入?br>
EVB开发入?br>
微Y已经宣布EVB不再支持Windows CE.NETQ所以EVB的最l版本是3.0。但׃EVB的易上手性和快速开发的特点Q在VS.NET横空Z之前Q它成ؓ(f)Windows CEq_上快速开发的不二之选。现在EVB仍然适合Windows CE 3.0q_上小型应用程序的快速开发。如果?zhn)不是专职的Windows CEE序员，而只是需要在Windows CEq_上开发整个系l的一部分Q那么EVB可以让?zhn)用很短的旉开发出(zhn)想要的E序?br>
EVB的开发环境的搭徏也是十分单，(zhn)可以从微Y的网站上下蝲EVT 2002Q其中包含了(jin)EVC 3.0、EVB 3.0和Pocket PC 2002 SDK和SmartPhone 2002 SDK。按照提C将EVB和Pocket PC 2002 SDK安装好后可以进行开发了(jin)。SDK中包含模拟器Q在没有实际讑֤的情况下Q可以利用模拟器来调试程序?br>
q里需要注意的是，开发环境和模拟器之间是通过|络q接协议q行通讯的，所以开发所用的计算Z必须有一个活动的|络q接。如果没有，可以安装微Y的虚拟网卡?br>
EVB的开发环境与VBcMQ因为Windows CE应用E序需要在模拟器或者实际设备上调试Q所以我们必选择E序的输出目标。如果?zhn)选择?jin)EmulationQ在(zhn)按下运行（或F5Q后QEVB自动启动模拟器Qƈ把程序下载到模拟器中?br>
׃新的Windows CE.NET不再支持EVBQ微软徏议EVBE序员(sh)用VB.NET开发新的程序，而对于原有的EVBE序也给Z(jin)q移路径Q关于这斚w的论qͼ(zhn)可以参考MSDN文章《Moving from eMbedded Visual Basic to Visual Basic .NET》?br>
EVC开发入?br>
无论是Win32q_q是WinCEq_QVisual C++都是一个强大的开发工兗而EVC也是WinCE上的L开发工兗EVC支持MFCcd的子集，可以l开发者提供最强大的支持，也Win32q_上的VCE序员可以很Ҏ(gu)地迁UdWinCEq_上。但׃MFCcd需要一个DLLQ所以对某些存储I间有限的嵌入式讑֤来说Q这是个很大的负担，所以SmartPhone׃支持MFC?br>
说这么多Q让我们来创Z个EVC的工E。是不是和VC很像Q需要提醒大家注意的是，׃嵌入式设备支持的CPUU类很多Q我们在选择创徏工程cd的同Ӟ也要把该工程所支持的CPUcd选择好。创建工E的q程和VC是一L(fng)。当然不同的q_支持的工E类型是不同的，比如Pocket PC 2003有支持MFC和API的两U工E，而SmartPhone 2003则只有支持API的一U工E?br>
EVC中比VC环境中多?jin)一行下拉菜单的选项Q分别用来选择Q工E、SDK、CPUcd和输?gu)备。以Pocket PCZQ在实际讑֤上调试应该选择Win32(WCE ARMV4)Debug Q而在模拟器上则需要选择Win32(WCE emulator)Debug?br>3.VS.net开发入?br>
又来到我们的.NET旉?jin)，我怎么说又Q最q大安被JAVA?NET搞得头昏脑胀?jin)吧Q不大家怎么吵，.NET Compact Framework对于手中~少开发利器的嵌入式程序员无疑是一大福韟뀂Visual Studio .NET 2003完全支持对移动设备的开发，好了(jin)Q让我们开始一D奇qȝ.NET之旅吧?br>
打开VS.net 2003Q选File - New – Project,打开?jin)上面的界面。让我们来徏立一个Visual C#的工E，然后选择Smart Device ApplicationQ然后OK?br>
你在q里要选择目标讑֤QPocket PC、SmartPhone、Windows CEQ指的是其他q_Q，下面则是选择创徏的工E类型，我们选择“Windows Application”Q左Ҏ(gu)选择的^台所支持的模拟器。最后点击OKQ我们就可以q入VS.NET的主界面?jin)?br>
选择输出讑֤的情况和EVB十分cMQ只需要选择输出讑֤Q而不用选择CPUcd。当然了(jin)Q因?NET是运行在虚拟Z的了(jin)。在CPUcd众多的嵌入式领域Q?NET和JAVA才能真正发挥自己的强V?br>
当然Q我们也可以选择VB.NET作ؓ(f)开发智能设备的语言Q情况和C#完全一栗目前智能设备开发只支持C# 和VB.NET。爱好C++的程序员可能q要{上一D|间?br>
Windows CE 开发的忠告
可以说当我们׃(jin)大部分时间将已有的应用程序移植到Microsoft Windows CE中。一般说来，q个计划不是太难。我们v步于Microsoft Win32代码Q当然Windows CE是基于Win32应用E序接口QAPIQ的。有利的是，我们的应用程序（即Raima 数据理器）(j)有方便的使用接口Qƈ包含一个大U由150个子函数l成的库Q这些函数都是由C语言写成Q可以用来创建、管理和讉K数据库?
按徏立应用程序的方式来说Q我们原以ؓ(f)它UL到Windows CE中是一相对简单的C语言~程l习(fn)。然而，我们不久侉K到好些困难。从_心(j)大意的错误开始，比如在基于Windows NT 的Windows CE仿真器上使用Microsoft Windows NT库，接着又违背W(xu)indows CE的编E戒律，?千万不要lUnicodeQ国际标准组l?0646标准Q字W分配奇数内存地址"?br>
大约有百分之?ji)十的问题或多或地与Unicode有关。尽Unicode~程不难Q但是，当给单字节字W编写代码时Q很Ҏ(gu)出错Q我有过许多ơ错误）(j)?br>
下面q些忠告是根据我们在Windows CE上编写Raima 数据理器的l验ȝ出来的，但我怿Q在做Q何其它Windows CEE序之前Q它们都值得借鉴。毕竟大多数Windows开发者，当他们创建第一个Windows CE应用E序Ӟ真正q用的是已掌握的Win32知识?br>4. WIN CE 开发忠?nbsp;[1]
不要在仿真器上用Windows NT?br>
q里所讨论的第一个错误实在太愚蠢?jin)，但我q是陷了(jin)q去Q也怽也会(x)。当用Microsoft VC++Q?.0版）(j)创徏一个Windows CEE序Ӟ你会(x)发现Q包含\径（includeQ?nbsp;库\径（libraryQ、及(qing)可执行程序\径被自动调整以匹配反应目标环境的选择。因此，比如说ؓ(f)Windows CE模拟器徏立应用程序时Q你?x)发玎ͼinclude路径没有指向Win32的包含文Ӟ在VC目录下）(j)Q而是指向Windows CE包含文gQ在WCE目录下）(j)。千万别M攏V?br>
׃Windows CE在Windows NT下运行，所以仿真器上运行的E序能够调用MWindows NT动态链接库(DLL)中的函数Q即使这个DLL不是模拟器的成员?sh)一栗显?dng)q不是很好的事，因ؓ(f)相同的函C许在手持PC(H/PC)或Windows CE讑֤上不可用Q而你的Y件最l要能在q些讑֤上运行?br>
W一ơ将非Unicode应用E序装入Windows CE仿真器时Q你?x)发玎ͼ许多正在使用的函数它都不支持Q例如美国国家标准协?ANSI)定义的字W函数strcpy()。这也许引诱你去链接Windows NT q行旉库，以便能解x(chng)有问题?br>
如果你是刚开始用Windows CE~程Q可能你能用的包含文件和库文件是明显的。答案就是，你不要采用那些在写普通Win32或非Windows CEE序时用的包含文g和库文g?br>
不要hTCHARs和bytes
如果你正在Windows CE上写非Unicode应用E序Q你或许要将所有的字符串从单个字符(chars)转换为宽字符(widechars)Q例如，C变量cdwhcar_tQ。几乎所有Windows CE支持的Win32和运行时间库函数都要求宽字符变量。Windows 95不支持UnicodeQ然而，Z(jin)使程序代码具有可UL性，你要可能采用tchar.h中定义的TCHARcdQ不要直接用wchar_t?br>
TCHAR是定义ؓ(f)wchar_tq是charQ取决于预处理器的符号UNICODE是否定义。同P所有有兛_W串处理函数的宏Q如_tcsncpy宏，它是定义为Unicode函数wcsncpyq是定义为ANSI函数strncpyQ取决于UNICODE是否定义?br>
在现存的Windows应用E序中，有些代码也许暗示字符长ؓ(f)单字节。这在给字符串分配内存时l常用到Q例如：(x)
int myfunc(char *p)
{
char *pszFileName;
pszFileName = malloc(MAXFILELEN);
if(pszFileName)
strncpy(pszFileName, p, MAXFILELEN);
/*etc*/
在这D代码中Q分配的内存块应该写?MAXFILELEN * sizeof(char))Q但是大多数E序员喜Ƣ将它简化ؓ(f)MAXFILELENQ因为对于所有的q_来说sizeof(char)的值等?。然而，当你用TCHARS代替多个字符Ӟ很容易忘记这U固有的概念Q于是将代码~写成下面的形式Q?br>
int myfunc(TCHAR *p)
{
TCHAR *pszFileName;
PszFileName = (TCHAR*)malloc(MAXFILELEN);
If (pszFileName)
tcsncpy(pszFileName, p, MAXFILELEN);
/*etc*/
q是不行的。它马上?x)导致出错。这里的错误在于malloc函数中指定变量大ؓ(f)bytesQ然而_tcsncpy函数中用的W三个变量却指定为TCHARs而不是bytes。当UNICODE被定义时Q一个TCHAR{于两个字节?bytes)?br>
上述代码D应该改写ؓ(f)Q?br>
int myfunc(TCHAR *p)
{
TCHAR *pszFileName;
PszFileName = (TCHAR*)malloc(MAXFILELEN * sizeof(TCHAR));
if(pszFileName)
tcsncpy(pszFileName, p, MAXFILELEN);
/*etc*/
5. WIN CE 开发忠?nbsp;[2]
不要Unicode 字符串放入奇数内存地址
在Intelpd处理器上Q你可以在一奇数内存地址储存?sh)M变量或数l，不会(x)DM致命的错误媄(jing)响。但在H/PC上，q一点不一定能?nbsp;? 你必d大于一个字节的数据cd心(j)谨慎Q包括定义ؓ(f)无符L(fng)型（unsigned shortQ?nbsp;的wchar_t。当你设法访问它们的时候，它们置于奇地址?x)导致溢出?br>
~辑器经常在q些问题?sh)提醒你。你无法理堆栈变量地址Qƈ且编辑器?x)检查确定这些地址与变量类型是否相匚w。同Pq行旉库必M证从堆中分配的内存L满一个word边界 Q所以你一般不必担?j)那两点。但是，如果应用E序含有用memcpy()函数拯内存区域的代码，或者用了(jin)某种cd的指针算术以定内存地址Q问题(sh)许就出现?jin)。考虑下面的例子：(x)
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 */
q段代码是从堆中分配内存q复制一个字W串Q在字符串的开头留一个HEADER_SIZE的大。假设UNICODE定义?jin)，那么该字W串是一个widechar字符丌Ӏ如果HEADER_SIZE是一个偶敎ͼq段代码׃(x)正常工作Q但如果HEADER_SIZE为奇敎ͼq段代码׃(x)出错Q因为q指向的地址也将为奇数?br>
注意Q当你在Intelpd处理器中的Windows CE仿真器上试q段代码Ӟq个问题是不?x)发生的?br>
在这个例子中Q只要确保HEADER_SIZE为偶敎ͼ你就可以避免问题的发生。然而，在某些情况下你也怸能这么做。例如，如果E序是从一台式PC输入数据Q你也许不得不采用事先定义过的二q制格式Q尽它对H/PC不适合。在q种情况下，你必采用函敎ͼq些函数用字W指针控制字W串而不是TCHAR指针。如果你知道字符串的长度Q就可以用memcpy()复制字符丌Ӏ因此，采用逐个字节分析Unicode字符串的函数也许以定字符串在widechars中的长度?br>
在ANSI和Unicode字符串之间进行翻?br>
如果你的Windows CE应用E序接口于台式PCQ也怽必须操作PCZ的ANSI字符串数据（例如Qchar字符Ԍ(j)。即使你在程序中只用到Unicode字符Ԍq都是事实?br>
你不能在Windows CE上处理一个ANSI字符Ԍ因ؓ(f)没有操纵它们的库函数。最好的解决办法是将ANSI字符串{换成Unicode字符串用到H/PC上，然后再将Unicode字符串{换回ANSI字符串用到PC上。ؓ(f)?jin)完成这些{换，可采用MultiByteToWideChar()和W(xu)ideCharToMultiByte () Win32 API 函数?br>
对于Windows CE 1.0的字W串转换Q劈开QhackQ?br>
在Windows CE 1.0 版本中，q些Win32API函数q没有完成。所以如果你x(chng)要支持CE 1.0又能支持CE 2.0Q就必须采用其它函数。将ANSI字符串{换成Unicode字符串可以用wsprintf()Q其中第一个参数采用一widechar字符Ԍq且认识"%S"(大写)Q意思是一个字W串。由于没有wsscanf() ?nbsp;wsprintfA()Q你必须惛_的办法将Unicode字符串{换回ANSI字符丌Ӏ由于Windows CE 1.0不在国家语言支持(NLS)中，你也许得求助于hackQ如下所C：(x)
/*
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*/
q种适合于Windows CE 1.0的实现办法比使用wsprintf()函数要容易，因ؓ(f)使用wsprintf()函数更难以限制目标指针所指向的字W串的长度?br>6. Win CE 开发忠?nbsp;[3]
选择正确的字W串比较函数
如果你要分类Unicode标准字符Ԍ你会(x)有以下几个函数可供选择Q?br>
wcscmp(), wcsncmp(), wcsicmp(), 和wcsnicmp()
wcscoll(), wcsncoll(), wcsicoll(),和wcsnicoll()
CompareString()
W一cd数可用来对字W串q行比较Q不参考当圎ͼLocaleQ或外文字符。如果你永远不想支持外文Q或者你仅仅x(chng)试一下两个字W串的内Ҏ(gu)否相同，q类函数非常好用?br>
W二cdC用现有的当地讄(current locale settings)Q系l设|，除非你在字符串比较函C前调用了(jin)wsetlocale()函数Q来比较两个字符丌Ӏ这些函C能正分cd文字W。如果当地的字符"C"Q?C" localeQ被选定Q这些函CW一cd数就h?jin)相同的功能?br>
W三cd数是Win32函数CompareString()。这个函数类gW二cd敎ͼ但是它允怽指定当地讄Qthe localeQ作Z个参敎ͼ而不是用现有的当地讄(current locale settings)。CompareString()函数允许你选择性地指定两个字符串的长度。你可以第二个参数讄为NORM_IGNORECASEQ从而函数比较字符串时不比较大写?br>
通常Q即使不第二个参数讄为NORM_IGNORECASEQCompareString()函数也不用来区分大小写。我们经常用wcsncoll()函数来区分大写Q除非用当地的字符"C"Q?C" localeQ。所以，在我们的代码中，不用CompareString()函数来区分大写Q而用wcsncoll()函数来区分大写
不要使用相对路径
与Windows NT不一PW(xu)indows CE没有当前目录q个概念Q因此，M路径只是相对于根目录而言的。如果你的Y件给文g或目录用相对\径，那么你很可能把它们移到别的地方了(jin)。例如，路径".\abc"在Windows CE中被当作"\abc"看待?br>
U走?jin)对calloc()?nbsp;time()函数的调?br>
Cq行库中的calloc()函数不能使用Q但是malloc()函数可以代替calloc()函数。ƈ且不要忘讎ͼcalloc()函数初始化时分配的内存(sh)ؓ(f)Ӟ而malloc()函数不一栗同Ptime()函数也不能用，但你可以使用Win32函数GetSystemTime()函数代替time()函数?br>
l过以上的警告后Q你?x)高兴地学?fn)最后o(h)你惊讶的两点忠告?br>
不需要改变Win32 输入/输出QI/OQ文件的调用
Win32的输入输出函敎ͼW(xu)indows CE也支持。允怽象访问Win32文gpȝ那样讉K对象。CreateFile()函数在Windows CE中不能辩认标志FILE_FLAG_RANDOM_ACCESSQ但是这个标志仅用作可选的盘讉KQƈ且不影响函数调用的功能?br>
不要担心(j)字节的状?br>
当我们把应用E序写入Windows CEӞ有了(jin)一个美好的发现Q那是Windows CE的数字数据类型的字节状态与Intell构的字节状态一P在所有的处理器上QW(xu)indows CE均支持?br>
几乎象所有的数据库引擎一PRaima数据库管理器在数据库文g中以二进制Ş式保存数字数据。这意味一个记录无Z时写入数据库或从数据库读出，均被当作一pd的字节来处理Q不它域的内容。只要数据库文g不要传给别的MpȝQ数字数据的字节状态问题就解决?jin)。如果数据库文g被一个来自原始系l且带有不同字节状态的处理器访问，数字数据被误解?br>
无论何时Q当你在拥有不同处理器的机器上传输文件时Q就?x)出现这个问题。在q个问题?sh)，值得高兴的是所有类型的处理器都使用相同的字节状态?br>
在用Windows CEӞq些忠告应该引v你够的重视Q避免学?fn)时走弯路?
]]>