在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
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/fredzeng/archive/2007/04/04/1551898.aspx