我认为的重点：中断处理 作为一嵌入式的的软件开发者，你可能最关心windows CE消息的处理规则是如何影响你的外部系统接口时序的。windows CE通过细心设计和准确的衡量以保证其中断时序以及其它相关的特性与嵌入式的系统设计是完全兼容的。
看清本质：Windows CE的存储结构
像其它的32 位Windows平台一样，Windows CE操作系统也有虚拟内 存的特性。内存总在某一时间按页分配给应用程序，页的大小由系统设计者决定(并在操作系统为目标硬件平台创建时被指定)。例如 在手持电脑，内存页大小是典型的1KB 或者4KB 。
在初始化期间(导入)，Windows CE创造一个独立的被所有程序共享的4GB 虚拟地址空间。当程序引用一个虚拟的地址时，它被内核记录在物理的内存上。 这使得应用程序软件开发者不必去考虑目标系统内存的物理的布局。虽然所有程序共享单一地址空间，应用程序仍然可避免相互误用。Windows CE 通过改变每页的保护来防止误调用的发生，而不是分配给每一程序不同地址空间。 作为应用程序开发者，你可能不会太在乎目标系统的内存的物理的结构。 内存可以全部是随机存取内存，或者它可能包括闪存卡或者硬盘驱动器。Windows CE操作系统为你管理内存资源，同时WIN32 API 向你提供必要的分配、使用和释放的内存的接口。然而，作为一个嵌入式的系统的设计者，你仍需要细心的考虑将在你的硬件平台上执行的应用程序的内存需要，并且全面考虑成本、速度和可靠性，平衡各种目标的冲突。
无论你的系统内存的配置如何，ROM(只读内存)将占用十分重要的地位。不同于其它的32位Windows操作系统，Windows CE操作系统的代码在只读内存中，并且在那个只读内存中原地执行。 依据你的产品需要，你也能选择在只读内存中放置应用程序代码。 例如，Pocket Word，Pocket Excel和其它应用程序程序，包括在手持电脑只读内存中被提供的。存储在ROM中的程序组在Windows CE下当地执行，所以嵌入式系统的设计者能够只占用很少的RAM用于堆栈存储的需要。相应地，你的嵌入式应用程序可以利用RAM既作为程序的内存又可作临时存储空间。
为了进一步的增加应用程序软件的性能， Windows CE采用按需求将内存分页；操作系统仅仅需要解压缩并且装入基于RAM的一小部分程序准备执行。ROM和 基于RAM的程序的灵活性与速度意味着基于Windows CE的设备能够被构造成各种内存结构形式。
Photoshop教程 数据结构 五笔输入法专题 QQ病毒专题 共享上网专题 Google工具和服务专题
不得不说的话题：意外情况的处理
意外情况处理是强大的编程技术，相应一套的WIN32 API 起函数能容易的发现未预料到的错误状况，并且使之恢复。结构化的意外情况处理，允许危险段的代码可能由于硬件资源的问题、设备的冲突和微小的编码错误而导致失败，以使这部分程序与其余的应用程序分开。这保护了应用程序，使之免于过早的终止或者产生敏感的系统问题。
结构化的意外情况处理包括定义一系列声明作为保护，并且为第一套的声明定义了另一个套声明作为意外情况句柄。 意外情况句柄定义了一个或多个声明来保障系统的运行，而不管保护声明的现有的状态。
在大多数32 位Windows平台上应用WIN32 API 的程序员在运用意外情况句柄的时候通常有两种选择，用C或 C++ 编写应用程序，并且利用WIN32提供的处理意外情况的宏，或者利用C++ 编写应用程序，并且使用C++ 语言定义的意外情况处理函数。
对于这种程序的编写，Windows CE的开发者因无法访问C++的（面向Windows CE的Visual C++ 目前还不支持意外情况处理，所以必须使用WIN32 API的意外情况处理宏。
为了应用WIN32意外情况处理，你将使用一套在WIN32 API 中被定义的宏。 下面一段代码显示其基本概念：
__try {
// The statements in here have a possibility of failure
// and so are guarded.
}
__finally {
// This is the exception handler. This code will execute
// after the guarded statements, no matter what happened
// in the guarded block of code above.
}
// This code will execute normally if the program flow allows
// it (no goto, exit, etc.)
__try 以及__finally 宏产生了使用意外情况句柄的所必要的底层代码。
意外情况的处理对诸如在嵌入式的应用程序中的那些普通的多线程序是有用的。WIN32结构化意外情况处理宏 是一种容易并且强大的保护应用程序使之免受未预料到的失败的方法。
临近尾声的重点：设备处理
有无数硬件设备(外围设备)与应用Windows的平台(Windows NT以及 Windows 95)台式机是兼容的，并且每一年都有更多的东西在市场上涌现。而Windows CE的平台，通常不支持台式计算机支持的设备的很多品种的外围硬件。 然而，为一嵌入式的的系统创造可靠的设备接口在嵌入式的程序设计的过程中，是比较富有挑战性的部分。 这部分地因为典型的嵌入式的系统接口的时序与其它可操作性的需要远比台式电脑计算系统和应用程序的更难。幸运的是，WIN32 API 提供了一套丰富的设备接口方法，使得设备接口程序写起来更容易并且更加适合于特定嵌入式的系统的需要。
WIN32 API是如何在你的硬件平台为你提供一套一致的基于流的设备接口的呢？。 为了使用设备，你首先利用适合于设备类型的函数打开它。 对于大多数设备，你利用的函数是在下列例子中的CreateFile 函数：
HANDLE hPort = CreateFile("COM1"); // Open the serial port
CreateFile函数打开规定的设备(串口)并且返回用于以后在该种设备上的操作(例如读和写)的句柄。 各种各样函数的(包括ReadFile ，WriteFile ，LockFile 和其他)接受这个句柄为参数，并且允许你(例如)读写数据，检查设备状态，并且将从其它程序的存取被锁住的设备或者文件列入清单。 文件输入输出操作被处理成与其它设备类型利用同样的API 函数，并且在文件之内包括随机的访问的函数。 被若干程序或线索同时访问的设备和文件可以分区域地利用LockFile 函数锁定。
在你的应用程序已完成设备或者文件之后，它将调用CloseFile 函数关闭设备，并且进行必要的清除设备的工作。
压轴之戏：定制设备和WIN32
当你开发一个新的硬件平台并且它支持输入输出设备，在模拟设计的不同层次上，你将不得不作出决策和折衷方案。例如，除非你只使用通常的off-the-shelf硬件，否则你必然要编写用户设备驱动程序来支持你的新外围设备，当然，你也可以根据需要配置你的Windows CE来包含一些设备处理必要的组件。同时从应用程序的层次，为满足新的设备的需要，你需要编写接口代码。在有如此多变量的情况下，你如何保持你的设备的一致行呢?答案就在WIN32 API 中。在WIN32 API环境下，写你的目标驱动程序，你有理由相信那些WIN32所提供的接口代码是完全可信的，可检验和可维护的基本代码。Windows CE设备驱动程序开发工具包，或者简称DDK ，提供了如何创造WIN32功能强大的设备驱动程序信息和范例。
最后的废话：总结
本文为你概略地介绍了面向Windows CE的WIN32 API，其目的是为了突出这种被广泛应用的并且十分重要的API的一般的特点和优点。有许多其它的细节你需要在第一次使用Windows CE嵌入式产品之前来学习掌握；做为投石问路的一篇文章，不敢说所有观点都是正确的，但是至少在某种程度上让你我多了一次技术上的交流，这也许是最重要的，谢谢你读完此文，呵呵！