CE 6内存模型

rel="File-List" href="file:///C:%5CDOCUME%7E1%5CADMINI%7E1%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml"> 要画 CE 6 的内存布局倒是比 CE 5 方便多了，

rel="File-List" href="file:///C:%5CDOCUME%7E1%5CADMINI%7E1%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C02%5Cclip_filelist.xml">

       这个模型和桌面系统非常的相像。所有的用户进程都共享1GB以下的空间，内核，包括提供系统服务的filesys等部分，都成为内核进程nk.exe的一部分，以dll的形式活动在内核空间。

       所幸2GB到3GB的静态映射空间和CE 5没有任何变化，对于需要移植内核的开发人员，也不需要进行修改。

       和CE 5相比，这样的内存模型显得更安全：

       首先、用户进程之间很难再进行互相访问了。在CE 5之中，虽然也存在一定的地址保护，但只是很装装门面的。一个合法的用户进程，只需要使用SetProPermissions，就可以轻松访问到其他进程。举例而言，进程A的基地址是0x8000000，A内部有个变量a的相对地址是0x3124；进程B的基地址是0x20000000。现在B希望访问变量a，当然直接读取地址0x3124是不行的，由于FSCR的存在，0x3124会被转换成0x20003124。那么B直接读取0x8003124呢，是不是就可以了？确实，只要使用完整的地址，就可以绕开FSCR了。但是，这时候程序还是会出错，系统会抛出一个Data Abort，因为B还没有访问A进程空间的权限。一个简单的做法是调用SetProcPermissions((DWORD)-1)，B就可以安全地使用地址0x8003124访问变量a了。SetProcPermissons和“装装门面”的保护原理，以后再讨论，这里只需说明，这是通过缺页中断实现的。在CE 6中，因为不再使用FSCR，这种方式就不再有效了。

       其次、用户进程很难再访问内核空间了。在CE 5中，有一个API叫SetKMode，以供用户进程切换到系统态，来访问内核空间。这个接口的存在，可能是因为诸如file，device等系统服务进程经常需要走走后门，所以特地留下的。但是在CE 6中这些系统dll完全在内核态下运行了，这个后门也就名正言顺地取消了。

       说到底，这样的系统，更像是一个桌面系统。而对于常常喜欢走后门的嵌入式开发程序员来说，的确是感到很不爽的。