Windows CE 进程、线程和内存管理（三）

Windows CE 进程、线程和内存管理（三）


作者：付林林

三、内存管理

　　同其它Windows操作系统一样，Windows CE.NET也支持32位虚拟内存机制、按需分配内存和内存映射文件等。但是与其它Windows操作系统又有明显的不同。毕竟Windows CE是一种嵌入式实时性的操作系统，在内存管理方面必须要比其它Windows操作系统更节约物理内存和虚拟地址空间。在内存管理API方面，为了便于移植程序，Windows CE和其它Windows操作系统函数声明基本一致，这使一个在其它Windows下开发的程序员可以直接使用早就熟悉的API函数， 但是CE下内存管理的原理开发者还是应该熟悉的。

1、ROM和RAM
　　最早的基于Windows CE的民用产品，采用的存储设备都是ROM ＋ RAM ，ROM保存CE内核文件、应用程序，而RAM用于内核、所有应用程序运行时使用，关闭电源时必须给RAM提供电力来保存系统配置信息、用户产生的文件等。为了适应这样的存储硬件，CE采用了ROM文件系统和RAM文件系统。在ROM中存放的模块可以是压缩的，也可以是不压缩的，这取决于OEM。OEM在定制内核时可以设置是否压缩模块。如果是压缩的，模块在运行前先解压并全部存放到RAM中。如果是不压缩的，就本地执行（XIP，executed in place）。本地执行和其它Windows操作系统下执行应用程序、DLL方式一致，也就是应用了内存映射文件技术。在这里我顺便讲一下。在启动时应用程序或DLL的代码段不加载到物理内存中，内核只是分配虚拟地址空间给代码段，当执行代码时内核会到实际存放在硬盘上的文件中寻找代码并执行。采用这样的技术既可以节省可用内存又可以减少加载的时间。请注意，操作系统首先会到为硬盘准备的缓冲区里读取代码数据，如果没有就命令硬盘读取应用程序文件数据到缓冲区。所以缓冲区设置大点是有好处的。Windows CE的本地执行就是采用这样的技术来加载ROM内的应用程序和DLL的。所以Windows CE的DLL分为XIP DLL和非XIP DLL。这种加载方式的缺点就是执行相对较慢一点，如果用PB创建一个具有实时性特点的内核，一定不能选用XIP技术。
　　到后来基于Windows CE的产品开始采用FLASH、IDE等永久存储设备时，文件系统又加了个FAT。内核文件和其它应用程序也可以存放到永久存储设备中，内核由加载程序解压并加载到RAM的对象存储区域（object store），包含在内核中的所有系统应用程序文件和DLL文件都存放到这个区域。当执行一个应用程序时，内核将这个应用程序调用的系统DLL加载到Slot 1（0x0200 0000－0x03FF FFFF）。在Windows CE.NET中Slot 1专用于XIP DLL使用。
　　RAM文件系统专用于对象存储。在以前的文章中曾经讲过，它和ROM文件系统是Windows CE默认的文件系统。Windows CE启动后把RAM分为对象存储区域（object store）和应用程序内存区域（program memory）。对象存储区域采用RAM文件系统来保存文件，一般用于保存内核解开的所有文件。应用程序内存区域留给所有应用程序运行时使用。在Windows CE下"控制面板"－"系统"－"内存"中，可以调节这两个存储区域的比例，滑块向左，则释放对象存储区域的一些内存并将这些内存划到应用程序内存区域中。滑块向右则相反。

2、内存结构
　　Windows CE.NET只能管理512MB的物理内存和4GB大小的虚拟地址空间。不同的CPU内存管理方法也不同。对于MIPS和SHX系列CPU来说，物理地址映射是由CPU完成的，CE内核可以直接访问512MB的物理内存。对于x86系列和ARM系列的CPU来说，在内核启动过程中它会将现有物理内存地址全部映射到0x8000 0000以上的虚拟地址空间中供内核以后使用。OEM可以通过OEMAddressTable来详细定义虚拟地址和物理地址的映射关系。OEMAddressTable本身并不是一个文件，它只是存在于其它文件中描述虚拟地址和实际物理地址的映射关系的数据。比如文件oem init.asm中包含一段代码：dd 80000000h, 0, 04000000h 。它表示将整个物理地址（0x0400 0000＝64MB）共64MB映射到虚拟地址从0x8000 0000到0x8400 0000中。关于OEMAddressTable我将在以后关于PB的文章中讲述。
　　整个4GB虚拟地址空间主要划分为两部分，从0x8000 0000以上为内核使用部分，0x8000 0000以下为应用程序使用部分。详细见下表：

　

图1 Windows CE.NET内存结构

3、进程地址空间结构
　　进程地址空间结构如图2所示。这个图源至MSDN。Windows CE.NET同以前版本的Windows CE操作系统在进程地址空间上有所不同，以前的Windows CE把XIP DLL也加载到进程的32MB地址空间中，而Windows CE.NET把XIP DLL单独加载到Slot 1中，这样对于每个进程来说，它总的地址空间就大了一倍，也就是64MB。这个问题我在讲解进程的时候提到过。
　　当一个应用程序启动时，内核为这个程序选择一个空闲的槽（Slot），并且加载所有的代码、资源，并分配堆栈，加载DLL等。当这个进程得到CPU使用权时，它的整个地址空间被内核映射到Slot 0，也就是当前进程使用的地址空间，然后开始运行。图中给出的地址实际上是经过映射到Slot 0之后的结构。从图中可以看出，进程首先加载代码段，因为每个进程最低部64KB作为保留区域，所以代码段从0x0001 0000开始，内核为代码段分配足够的虚拟地址空间后，接着分配空间为只读数据和可读/可写数据，接着分配空间为资源数据，之后分配空间为默认堆和栈。非XIP DLL从进程最高地址向下开始加载。非XIP DLL的加载按如下规则：内核先检查要加载的DLL是否被其它进程加载过，如果加载过，就做一个地址的重定位。这样就避免了整个系统内多次加载相同DLL。如果没有加载过，就按照从槽的高地址到槽的低地址的顺序查找空闲的地址空间。然后分配足够的地址空间用于加载DLL。因为每个进程在执行前都要映射到Slot 0，而且进程使用的所有DLL可能来自不同的槽（Slot），为避免所有使用的DLL在映射到Slot 0中出现地址空间冲突的现象，内核的加载器（Loader）在加载DLL时会查找所有槽中加载的DLL的地址，保证在映射到Slot 0时不会发生地址冲突现象。假如系统内有两个进程，进程A只加载了DLL A，进程B需要加载DLL A和DLL B，那么进程B会留出DLL A的地址空间，然后加载DLL B，也就是说进程B映射到Slot 0时，DLL A的地址空间和DLL B的地址空间是相邻的，不会发生冲突。好在Windows CE下DLL都很小，而且一个应用程序使用的DLL多数是系统的DLL（存在于Slot 1）。所以目前来看进程的地址空间还够用。


图2 进程地址空间结构

4、堆和栈
　　堆是一段连续的较大的虚拟地址空间。应用程序在堆中可以动态地分配、释放所需大小的内存块。利用堆的优点是在一定范围内减小了内存碎块。而且开发者分配内存块前不必去了解CPU的类型。因为不同的CPU分页大小不相同，每个内存页可能是1KB、4KB或更多。在堆内分配内存块可以是任意大小的，而直接分配内存就必须以内存页为单位。当一个应用程序启动时，内核在进程所在的地址空间中为进程分配一个默认192KB大小的虚拟地址空间，但是并不立刻提交物理内存。如果在运行当中192KB不能满足需求，那么内核会在进程地址空间中重新查找一个足够大小的空闲的地址空间，然后复制原来堆的数据，最后释放原来的堆所占的地址空间。这是因为默认的堆的高地址处还有栈，所以必须重新分配一个。Windows CE.NET的堆有明显的缺点，不同于其它Windows操作系统下的堆管理，在Windows CE.NET创建的堆中创建的内存块不能够移动，多次创建内存块、释放内存块会产生内存碎块，这样的话当需要分配一个大一点的连续的内存块时，本来空闲的内存块加起来足够用，但是这些内存块是分隔的，不符合要求。像Windows 2000或98的内核会频繁的移动分散的正使用的内存块，使它们聚集在一起。这也是为什么有时需要句柄而不用指针的原因。由于Windows CE.NET的堆的缺点，开发者如果要频繁的在堆中创建、释放内存块的话，最好自己创建一个单独的堆，而不用默认的堆。而且我还建议最好直接在全局地址空间中（0x4200 0000到0x7FFF FFFF）分配所需地址空间。因为进程地址空间可用的实在太小了。关于堆函数我在这就不多说了，和其它Windows操作系统堆API基本一致。请参考帮助文档。
　　栈也是一段连续的虚拟地址空间，和堆相比空间要小的多，它是专为函数使用的。当调用一个函数时（包括线程），内核会产生一个默认的栈，并且内核会立刻提交少量的物理内存（也可以禁止内核立刻提交物理内存）。栈的大小和CPU有关，一般为64KB，并且保留顶部2KB为了防止溢出。可以修改栈的大小，具体修改方法在讲解线程的时候已经说过了，这里就不再重复了。修改栈的大小一般时候不会发生，如果采用在编译链接时修改大小，那么所有栈的大小都会改变，这不太合理。实际开发中最好不要在栈中分配很大、很多的内存块，如果分配的内存块超过了默认栈的限制，那么会引起访问非法并且内核会立刻终止进程。最好在进程的堆中分配大的内存块并且在函数返回前释放，或者在创建线程时指定栈的大小。

5、内存映射文件
　　与虚拟内存一样，内存映射文件用来保留一个地址空间，并提交物理存储器。早期的内存映射文件并不是提交物理内存供调用者使用，而是提交永久存储器上的文件数据。当然操作系统会为永久存储器保留一个读缓冲区，这样读取文件数据就快多了。内存映射文件的特点使它很适合于加载EXE或DLL文件。这样可以节省内存又减少了加载所需时间。还可以使用它来映射大容量的文件，这样就不必在读取文件数据前设置很大的缓冲区。另外内存映射文件常用于进程间通信，也是进程间通信的主要手段，其它进程之间通信机制都是基于内存映射文件来实现。为了更快的在进程之间通信，现在的内存映射文件也可以提交物理内存，这样内存映射文件既可以提交物理内存又可以提交文件。
　　Windows CE.NET同样支持无名和有名的内存映射文件。我建议在开发软件的过程中，如果需要读写大容量的文件，或者需要在不同进程内的线程之间通信，最好采用内存映射文件，而且最好在全局地址空间内（0x4200 0000到0x7FFF FFFF）分配。这会使我们事半功倍。

5.1 映射数据文件
　　第一步：调用CreateFileForMapping函数。在Windows CE.NET中推荐使用这个函数替代CreateFile函数。CreateFileForMapping函数由内核执行并创建文件，它也可以打开由CreateFile函数创建的文件。其参数同CreateFile相似。参数1指定文件路径，注意文件路径的格式是没有盘符的，参数2指定访问方式（读或写），参数3指定共享模式，参数4指定安全属性（必须设置为NULL），参数5指定是创建还是打开文件，参数6指定文件属性，参数7忽略。具体参数细节参见Windows CE.NET帮助。函数返回创建或者打开的文件的句柄。
　　第二步：调用CreateFileMapping函数。这个函数创建一个无名的或者有名的内存映射文件对象。参数1为文件句柄。这个值由CreateFileForMapping函数返回。参数2为安全属性（必须设置为NULL），参数3指定要映射的文件的保护属性（只读或者读写），参数4和参数5共同用于指定要映射的文件的大小。文件的容量过大将导致32位整数也不能表示，所以这里用64位变量表示，其中参数4为高32位数，参数5为低32位数。最后一个参数指定内存映射文件的名称。这里可以设置为NULL，表示不需要名字。
　　第三步：调用MapViewOfFile函数。这个函数用于保留一段足够的地址空间，并且将永久存储器上的文件数据映射到这个地址空间。映射后这段地址空间又叫做文件视图，映射范围可以是全部文件，也可以是部分文件。这里需要注意的是如果文件很大，那这个函数将在全局地址空间内分配地址空间。参数1指定内存映射文件对象的句柄，这个值由CreateFileMapping函数返回。参数2和CreateFileMapping函数中参数3很相似，都是用于限定访问权限。参数3和参数4共同用于指定映射区域的开始位置。其中参数3为高32位数，参数4为低32位数。参数5指定映射区域的大小。需要注意的是参数3和参数4指定的64位数开始位置可以不是64KB的倍数。而其它Windows操作系统就必须限制以64KB为单位。另外还要注意的是帮助文档中说不能保证一个文件的映射视图是连续的，并建议为了防止访问非法，应该加入结构化异常处理机制。这个可能性我认为很小，一般对于大于2MB的虚拟地址空间的申请，内核都会在全局地址空间中分配。全局地址空间（0x4200 0000到0x7FFF FFFF）近1GB的空间应该足够用了。毕竟Windows CE下的文件都很小。不过在代码中加入结构化异常处理也不是坏事。我们应该养成凡是读写文件数据时都加入结构化异常处理的习惯。
　　第四步：进行读/写操作。MapViewOfFile函数如果成功执行，那么返回映射视图的首地址。这时就可以把视图当成是一个缓冲区，开始读或写操作了。
　　第五步：执行结束工作。先调用UnmapViewOfFile函数撤销文件映射视图。参数只有一个，指定视图首地址。然后调用CloseHandle函数关闭内存映射文件对象，参数为句柄。最后再次调用CloseHandle函数，关闭打开的文件的句柄。

5.2 进程之间通信
　　进程之间有时需要通信。系统提供的进程之间的通信机制比如COM、剪贴板等，在底层实现上都是利用内存映射文件技术。其实进程之间通信的思路很简单，在这里我顺便讲一下。在其它Windows操作系统中，每个进程独自占有4GB的地址空间，高2GB是内核的地址空间，而低2GB是进程的地址空间。一个进程所能访问的所有低2GB地址都是自己的地址空间，当访问内核地址空间时就会受到内核的限制。这样一个进程当然无法访问其它进程了。为解决进程间通信的问题，内存映射文件技术被利用作为解决方案。原来内存映射文件只映射类似磁盘一类的存储器上的文件。而为了更快速地在进程之间通信，内存映射文件还可以提交物理内存。实现方法是通过访问同一个内存映射文件对象（映射到物理内存），两个进程或多个进程就能够访问到同一块物理内存，这样一个进程写到物理内存的数据，其它进程就能够看到了。而Windows CE虽然每个进程只占有32MB的地址空间，而且所有进程全部处于4GB的地址空间中，但是彼此还是不能够随意访问的。在Windows CE下除了使用内存映射文件技术外，还有一种方法也很适合使用，就是利用对象存储。对象存储本身使用RAM文件系统，用普通的操作文件的API就可以创建、读取存在于对象存储区域内的文件。/Windows 目录就存在于对象存储区域内。我们可以利用在/Windows目录下创建文件来实现进程间通信。这种方法既实现简单，只需调用几个文件API函数，又可以减少通信时间，因为/Windows目录存在于物理内存中，数据I/O当然很快了。利用对象存储来实现进程之间的通信是我自己想出来的，MSDN或其它文档并没有这方面的说明。需要注意的就是对象存储区域的大小。另外从实现的代码量上看也不如内存映射文件技术。
　　下面讲解如何利用内存映射文件实现进程之间的通信。假设进程A和进程B需要通信，那么进程A需要先创建一个内存映射文件（之前不必调用CreateFileForMapping函数来创建文件，因为不需要创建文件）。这个内存映射文件可以是在永久存储器中，也可以是在内存中。为了减小通信时间，最好提交物理内存。进程A在调用CreateFileMapping函数时，参数1指定为INVALID_HANDLE_VALUE，这表示这个内存映射文件对象将要把物理内存提交到地址空间中。最后一个参数一定要指定一个名字。进程B也同样调用CreateFileMapping函数，而且参数相同。内核会根据名字来判断是否已经存在一个内存映射文件对象，如果创建了就返回原来的对象的句柄。接下去就不用细说了。参照5.1去执行就可以了。要注意的是进程B调用CreateFileMapping函数后要按如下代码检验函数执行结果：

HANDLE  hMap;
hMap = CreateFileMapping(INVALID_HANDLE_VALUE, 
   NULL,
   PAGE_READWRITE,
   0,
   1000,
   L"abc");
if (hMap == NULL || GetLastError() != ERROR_ALREADY_EXISTS)
{
 MessageBox(L"create file mapping fail");
 return;
}