原文标题：《Platform Builder实践之两个要点》

　　增加对大容量物理内存的支持和永久存储注册表是在定制内核工作中常遇到的问题。本篇文章将对这两个方面阐述相关的知识并指导读者如何在PB中实现。

　　对大容量物理内存的支持

　　在PC上增加物理内存是很方便的，插上内存条后只要自检程序识别，那么桌面操作系统就能够支持。而在基于CE的产品上就没那么简单了。如果物理内存大于64MB，就要在定制内核时做一些工作。

　　一旦内存管理单元（MMU）开始工作，CPU就不再直接访问物理内存了，对于运行在x86和ARM系列CPU上的CE内核来说，必须先确立物理内存地址同虚拟内存地址的映射关系。这种关系实际是在一个名为OEMAddressTable的表中定义的。这个表在前面的文章中已经提到过。CE提供了两种虚拟地址映射方法，分别为静态映射和动态映射，这个表属于静态映射方法。静态映射的虚拟地址空间只能由内核访问，而动态映射的地址空间可以由用户模式的应用程序访问。OEMAddressTable在文件%_WINCEROOT%\Public\Common\Oak\Csp\i486\Oal\OEMInit.asm中。在这个文件的最后有一段代码：

; RAM 0x80000000 -> 0x00000000, size 64M dd 80000000h, 0, 04000000h dd 0, 0, 0

　　这段代码表示将虚拟地址80000000映射到物理地址0，大小为64MB。将04000000h改成实际的物理内存大小，然后保存。接着单击PB菜单“Build”－“Open Build Release Directory”，在命令行中先用cd命令进入上述目录，如：

cd %_WINCEROOT%\Public\Common\Oak\Csp\i486\Oal

　　然后键入下列命令：

build -c sysgen i486oal

　　build命令根据配置文件内容编译整个目录，sysgen批处理将build 编译的文件i486oal.lib文件复制到CE的安装目录和内核工程目录下。我安装的BSP是基于x86的，所以相应目录为%_WINCEROOT%\PUBLIC\COMMON\OAK\LIB\X86\RETAIL和%_PROJECTROOT%\cesysgen\oak\lib\x86\retail两个目录。上一步做完之后，接着开始修改config.bib文件。在以前的文章中讲过在config.bib文件中定义内存区域。在config.bib中预设的配置没有超过64MB的，所以要自己手工添加。可根据原有的IMGRAM64配置更改，原有的IMGRAM64如下：

; 64 MB of RAM (note: AUTOSIZE will adjust boundary) IF IMGRAM64 NK 80220000 009E0000 RAMIMAGE RAM 80C00000 03000000 RAM UMABUF 83C00000 00400000 RESERVED ENDIF

　　假如要支持128MB，更改如下：

IF IMGRAM16 ! IF IMGRAM32 ! IF IMGRAM64 ! NK 80220000 009E0000 RAMIMAGE RAM 80C00000 07000000 RAM UMABUF 87C00000 00400000 RESERVED ENDIF ENDIF ENDIF

　　在这里没有更改NK的大小，只是修改了RAM的大小。

　　在config.bib定义之后，还可以在OAL层通过变量或者函数更改物理内存的大小，适合设备可能出现增加或减小内存的情况。CE的帮助文档介绍了几种方法，这里只提一下CreateStaticMapping函数。CreateStaticMapping函数作为config.bib文件的补充，适合在用户模式的应用程序或驱动程序中调用，调用这个函数能够将指定首地址的物理内存块映射到虚拟地址空间，函数返回虚拟地址。虚拟地址范围在C400 0000 到 E000 0000之间，这是内核的地址空间，只能由内核访问。相比较VirtualCopy函数用于动态地将指定首地址的物理内存块映射到虚拟地址空间，这个虚拟地址空间一般为用户进程的地址空间，因为VirtualCopy函数被设计专用于驱动程序调用，它常被用于将一个物理内存块映射到不同的虚拟地址空间。

　　实现永久保存注册表数据

　　关于注册表在前面的文章中已经介绍过了，这里只讲述如何实现永久保存注册表数据。

　　注册表类型分为基于对象存储的注册表和基于HIVE的注册表，在定制内核的时候只能选择其中一种。从理论上讲这两种注册表都能够实现永久保存注册表数据，但是采用不同的类型会影响CE的启动顺序和启动速度，还会影响内存的使用量。我还是趋向于采用基于HIVE的注册表来实现永久保存注册表数据，这也是一个发展趋势。在讲解之前先简单描述如果CE采用基于HIVE的注册表，那么在启动时如何加载已经保存的注册表数据：

　　1、nk.exe执行，启动filesys.exe。

　　2、filesys.exe加载引导HIVE，此时引导HIVE位于nk.bin解压之后的文件中。

　　3、filesys.exe启动device.exe，之后处于等待状态，等待device.exe将包含系统HIVE的文件系统和存储设备的驱动程序加载完毕。而这个文件系统和存储设备的驱动程序存在于引导HIVE中。

　　4、device.exe加载上述所说的文件系统驱动程序和存储设备驱动程序，使之开始工作。之后device.exe处于等待状态。

　　5、filesys.exe被唤醒，加载并且安装系统HIVE。之后filesys.exe处于等待状态。

　　6、nk.exe按照系统HIVE的信息开始执行初始化工作。其中包括加载驱动程序和启动一些应用程序。其中加载驱动程序一般由device.exe执行，而启动应用程序由filesys.exe执行。这时device.exe和filesys.exe已经被唤醒。

　　因为引导HIVE和系统HIVE肯定有重复的地方，所以可能出现重复加载了驱动程序或者重复启动了应用程序。为此，CE允许在描述驱动程序的注册表信息中加入防止重复的标志，而应用程序可以采用事件对象来防止重复启动，如device.exe。

　　下面讲述如何设置基于HIVE的注册表（假如保存系统HIVE的是FAT文件系统）：

　　1、在PB中加入"Hive-based Registry"，如果是Geode平台，再加入BSP_ENABLE_FSREGHIVE环境变量。

　　2、打开platform.reg，找到如下信息：

; HIVE BOOT SECTION [HKEY_LOCAL_MACHINE\init\BootVars] "SYSTEMHIVE"="Documents and Settings\\system.hv" "PROFILEDIR"="Documents and Settings" "Start DevMgr"=dword:0 IF BSP_ENABLE_FSREGHIVE "Start DevMgr"=dword:1 ENDIF ; END HIVE BOOT SECTION

　　"SYSTEMHIVE"的值为系统HIVE文件的路径。"Start DevMgr"是一个布尔值，指示是否开始就执行设备管理器device.exe，按照CE帮助文档的说法，只有想把系统HIVE存储在对象存储中才在此设置为0，所以一般都要设置为1。

　　3、如果是多用户，可以在上述的注册表位置下输入"DefaultUser"=""，指定默认的用户名。如果是单用户系统，可以不设置。

　　4、保证将包含系统HIVE的文件系统驱动程序的注册表信息和存储设备的驱动程序的注