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以下为应用程序使用部分。详细见下表：
　　地址范围用途
　　0x0000 0000到0x41FF FFFF　　由所有应用程序使用。共33个槽，每个槽占32MB。槽0（Slot 0）由当前占有CPU的进程使用。槽1由XIP DLL使用。其它槽用于进程使用，每个进程占用一个槽。
　　0x4200 0000到0x7FFF FFFF　　由所有应用程序共享的区域。32MB地址空间有时不能够满足一些进程的需求。那么进程可以使用这个范围的地址空间。在这个区域里应用程序可以建堆、创建内存映射文件、分配大的地址空间等。
　　0xA000 0000到0xBFFF FFFF　　在这个范围内核重复定义0x8000 0000到0x9FFF FFFF之间定义的物理地址映射空间。区别是在这范围映射的虚拟地址空间不能够用于缓冲。
　　我举例来说明：假设一个产品有64MB物理内存。如上文所述定义好OEMAddressTable后。内核启动后一个物理地址映射空间范围在0x8000 0000到0x8400 0000，那么内核会从0xA000 0000到0xA400 0000定义一个同样范围的地址空间，这个地址空间和0x8000 0000到0x8400 0000映射到相同的物理地址。但这个虚拟地址空间不能够用于缓冲。
　　0xC000 0000到0xC1FF FFFF系统保留空间
　　0xC200 0000到0xC3FF FFFF内核程序nk.exe使用的地址空间。
　　0xC400 0000到0xDFFF FFFF　　这个范围为用户定义的静态虚拟地址空间，但这个地址空间只能用于非缓冲使用。
　　利用OEMAddressTable定义物理地址映射空间后，每次内核启动时这个范围都不改变了，除非产品包含的物理内存容量发生变化。假如增加到128MB物理内存，那么物理地址映射空间也向后扩大了一倍。Windows CE.NET也允许用户创建静态的物理地址映射空间。用户可以调用CreateStaticMapping函数或者NKCreateStaticMapping函数来映射某一段物理地址到0xC400 0000和0xE000 0000之间的某一个范围。需要注意的是用这个函数创建的静态虚拟地址只能够由内核访问，而且不能用于缓冲。
　　0xE000 0000到0xFFFF FFFF　　内核使用的虚拟地址。当内核需要大的虚拟地址空间时，会在这个范围内分配。
　　
　　图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）。所以目前来看进程的地址空间还够用。