http://blog.csdn.net/fredzeng/archive/2007/04/04/1551898.aspx

在CE4.2/5.0里面滚打多年的兄弟应该经常用这个函数吧。这个函数方便驱动和应用程序范围任何的物理地址，包括物理内存啊，设备控制器的寄存器啊，甚至GPIO也可以在AP里面随便拉上拉下。

这个函数虽然方便，但是并不安全，你想你好不容易把一个功能完善的image给build出来了，结果碰到了一个写AP的"高手"，把你的寄存器和共享内存中的数据修改得一塌糊涂，最后报出bug来说你驱动的你会不会晕倒！

还好从CE6.0开始我们可以安枕无忧了，因为AP再也不能调用VirtualCopy函数来直接访问物理地址了，但因此带来了一些应用上的不便。

VirtualCopy 的限制来源于CE6.0之后kernel的巨大变革，在CE5.0之前的Windows CE操作系统中，kenrel就仅仅是kern.exe（nk.exe），这个exe其实是OAL、KITL和Kernel三个的合体，nk.exe是运行于内核模式（kernel mode），也就具有了访问特殊地址的权限，然后除此之外的代码默认都是运行于用户模式（user mode），所以它们的驱动和AP都是等级的，都在用户模式运行，要运行在kernel模式也可以，调用一个API SetKmode（）就行了。因为驱动是肯定要访问物理地址的，所以CE5.0以前的OS都是运行用户模式的程式访问物理地址的，然后又为了方便做从物理地址到虚拟地址的映射，就提供了一系列的帮助函数，virtualcopy就是最常用的函数之一。

CE6.0 开始，kernel模式变得比较正规，类似于台式机上的windows系统了，驱动和ap的权限是严格区分的，大部分的驱动程序运行在kernel模式，它们可以用virtualcopy读写物理地址对应的物理设备，但用户模式的AP将从此没有直接访问物理地址的权限，virtualcopy每次调用都会失败返回。

在这里还要注意的是，其实并不是用户模式就不能使用virtualcopy，virtualcopy只是不能在用户模式的AP中使用，但是却还可以在用户模式的驱动使用，但是在用户模式的驱动中使用也有条件，那就是必须在对应的注册表中设置可以访问的内存地址的范围才行。

在某些场合，一些特殊功能的AP确实需要访问物理地址的，比如设置保存物理内存指定位置的全局变量，开发读写GPIO的测试工具等等。在这种情况下一种简单的方法是实现一个最简单的跑在kernel模式的流驱动，提供一个deviceiocontrol的接口来帮助AP申请对应于物理内存地址的虚拟内存地址。

除了virtualcopy之外，CE6下还有很多API是AP和user模式的驱动不能调用的，给大家参考一下，大家要把CE50下的AP移植到6.0下一定要注意找到替代

Virtual Memory APIs
CeVirtualSharedAlloc
LockPages
LockPagesEx
UnlockPages
UnlockPagesEx
VirtualAllocCopyEx
VirtualCopyEx
VirtualSetAttributes
CreateStaticMapping
NKDeleteStaticMapping
VirtualCopy

File System APIs
ReadRegistryFromOEM
SetStoreQueueBase
WriteRegistryToOEM

Power APIs
PowerOffSystem （很多测试AP用到）

Miscellaneous APIs
SetOOMEvent