求有关wince的中文入门资料（有分放！！！！）

找不到。不知谁有？最好有介绍PB的。给个连接也好

操作系统的基本体系结构
Windows CE 是由许多离散模块构成的，每一模块都提供特定的功能。这些模块中的一部分被划分成组件。组件使 Windows CE 变得非常紧凑（只占不到 200 KB 的 RAM），因此只占用了运行设备所需的最小的ROM、RAM 以及其它硬件资源。Windows CE  包含提供操作系统最关键功能的 4 个模块：内核模块；对象存储模块；图形、窗口和事件子系统 （GWES） 模块以及通信模块。Windows CE  还包含一些附加的可选择模块，这些模块可支持的任务有管理可安装设备驱动程序、支持 COM 等。内核内核是 OS 的核心，通过 Coredll 模块表示。它提供在所有设备中都出现的基本操作系统功能。内核负责内存管理、进程管理以及特定文件管理等功能。它还管理虚拟内存、调度、多重任务处理以及例外处理等。Windows CE 的任何配置都需要用到 Coredll 模块的大多数组件。有一些内核组件是可选的，只有在涉及系统功能操作时，才需要这些组件，例如电话技术、多媒体技术以及图形设备接口（GDI） 技术等。对象存储Filesys 模块支持Windows CE  对象存储 API 函数。对象存储所支持的永久性存储器的类型如下表所示。存储器类型                 说明文件系统            包含应用程序和数据文件系统注册表          存储应用程序必须快速访问的系统配置信息以及其它任何信息Windows CE 数据库   提供结构化存储对象存储可将用户数据和应用程序数据存入文件或注册器。在操作系统构造进程（该进程中只包括那些必需选项）的过程中，对于这些不同的对象存储组件，可以选取，也可以忽略。GWESGWES 是用户、应用程序和 OS 之间的图形用户接口。GWES  通过处理键盘、笔针动作来接受用户输入，并选择传送到应用程序和OS 的信息。GWES 通过创建并管理在显示设备和打印机上显示的窗口、图形以及文本来处理输出。GWES  的中心是窗口。所有应用程序都需要窗口以接收来自 OS 的消息，即使那些为缺少图形显示的设备创建的应用程序也是如此。GWES 提供控制器、菜单、对话框以及图形显示的设备资源，还提供 GDI 以控制文本与图形显示。通信通信组件提供对下列通信硬件和数据协议的支持：? 串行 I/O 支持? 远程访问服务（RAS）? 传输控制协议/ Internet 协议 (TCP/IP)? 局域网 （LAN）? 电话技术 API （TAPI）? Windows CE 的无线服务可选组件除上述主要模块之外，还可使用其它的操作系统模块。这些模块与组件主要有：? 设备管理器和设备驱动程序? 多媒体（声音）支持模块? COM 支持模块? Windows CE  外壳模块Windows CE 提供的每一模块或组件都支持一组可用的相关 API 函数。

为Windows CE平台开发嵌入式系统
------------------------------------------------------------------------------
--

Microsoft Windows CE 上的Platform Builder 2.11把Windows CE操作系统的强大功能和
一个集成开发环境以及Win32上内容丰富的嵌入式开发工具集结合了起来。本文描述了在
高级的32位嵌入式应用中使用Windows CE和Windows CE Platform Builder 2.11的特点和
好处，它还描述了在把一个PC上的硬件开发平台作为低成本的原型目标时如何快速而方便
地评估操作系统及其附带工具。Windows CE的Platform Builder的低成本原型功能在允许
OEM并行地开发软件和硬件方面证明了自己独特而不可或缺的价值。

绪论

Microsoft Windows CE轻而易举地主宰着嵌入式系统市场。面向从最基本的系统到高级的
32位嵌入式系统，Windows CE是一个小规模而又高度可定制的操作系统。它是一个全新的
系统，以最现代的技术设计和优化，适用于现有的和下一代的32位微处理器家族，包括基
于MIPS、PowerPC、SH-3、SH-4、ARM、StrongARM和Pentium核心的功能强大的新型处理器
。Handheld PC（H/PC）是最先利用Windows CE功能的一类设备，但H/PC是这一崭新而功
能强大的系统现在唯一实现了的应用。可以预见，在未来的几个月或一年内，业界将掀起
一股热潮，纷纷在便携式电子设备和紧凑的专用系统运行Windows CE。Windows CE允许嵌
入式应用软件在公开接口上产生产品数据的功能将激起一股控制和HMI产品涌入市场的潮
流。

Windows CE Platform Builder 2.11提供您需要的操作系统和开发工具以创建高级嵌入式
应用程序。它和高性能的Developer Studio集成在一起，让您获得高效率和项目管理能力
，以及在Windows CE操作系统下创建嵌入式应用程序的完整的工具包。这个集成环境包括
了Win32 API--业界领先的应用编程接口。Win32提供了丰富且容错性极好的服务。另外，
存在着成千上万的其他工具、软件库、书籍及其他资源供Win32开发者使用，自然，有着
更多的谙熟Win32 API的软件开发者。

Windows CE Platform Builder 2.11改变了嵌入式软件工具获得和使用的方式，大幅降低
了嵌入式产品开发的成本。Windows CE和Platform Builder不仅仅是改变了嵌入式系统开
发的经济模型，它们还改变了评估模型。Windows Platform Builder 2.11可通过零售渠
道获得，在价格上与其他同类型嵌入是开发工具比起来也具有相当优势。微软的开发工具
在结合高性能和突出的价值方面一向做得非常好，Platform Builder也不例外。

形势分析

当今的嵌入式设计队伍处于高度分化状态中。有着多得让人眼花缭乱的实现目标和工具，
包括微控制器、微处理器、定制和专用的操作系统、实时操作系统附件和内核，以及非标
准化的嵌入式开发系统和重要的工具。目标和工具上的多样化也困扰着嵌入式系统的主要
购买者，使得支持所有平台的环境的维护变得几乎不可能。这一障碍导致制造商和主要销
售团体坚持嵌入式系统开发者必须遵守标准平台和开发工具的原则。作为嵌入式平台的
Windows CE满足甚至超过了这些需求。Windows CE和Platform Builder 2.11的设计实现
满足了嵌入式系统设计者的需求，是过去那些昂贵的专用嵌入式开发工具的亟需的替代方
案。Windows CE操作系统及相关开发工具之所以具有吸引力，其大部分原因在于他们提供
了广为人知并广为使用的开发环境，并且和具有嵌入式应用所需的高性能、高效率和便携
式操作系统结合在一起。Windows CE的高级特性，诸如网络、通信以及图形功能，和模块
化设计结合在一起，为中级开发人员创建高复杂度嵌入式系统提供了理想的环境。

现有技术并不能开发附带新型I/O系统的扩展嵌入式系统。Window CE提供象USB这样的外
围接口，允许高级I/O系统的即时支持。Windows CE驱动程序模型在驱动程序体系结构方
面有着很大的灵活性，允许现有驱动程序技术的快速引入。对嵌入式市场的这一新的开放
性也是Windows CE最具希望的所在。

现今的嵌入式系统并不接受开放数据接口。与现在的嵌入式系统关联的进程数据依靠一个
捆绑于系统上的单独的监控计算机收集获得。Windows CE的网络和通信功能使嵌入式系统
的开发者和用户能够使这些开放接口对嵌入式环境本地化。这一\"基础架构开放性\"也是
Windows CE在嵌入式市场获得空前欢迎的主要原因之一。

Windows CE的基本设计目标之一是简化嵌入式开发过程，这一目标的实现借助于当今嵌入
式系统设计者在编程时最为广泛使用的Win32 API的引入，并和Microsoft Visual C++等
开发系统结合在一起。同时，Windows CE提供一个稳定、灵活且被广泛支持的操作系统来
处理建立在嵌入式系统上的多种多样的硬件平台和软件应用程序。对嵌入式系统的开发者
和用户来说，Windows CE带来的实实在在的好处是无可否认的。

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点忠告应该引起你足够的重视，避免学习时走弯路。

嗯。还有没有？多多益善 :)