wince6.0 下如何编写能使直接访问硬件的软件？
wince6.0 下如何编写能使直接访问硬件的软件？
以前在wince5.0 下使用MmMapIoSpace就可以很容易做到了。
但是wince6.0 下的应用程序和驱动已经不在同一个空间了。
如何做到？
有时候写一个应用程序去直接操纵硬件对调试驱动非常有帮助，
在wince6.0 下有些人也写了这类型软件，比如sunrain_hjb的wince6.0寄存器读写软件，但是没有源码，不知道如何做到的。
我想调试一些复杂的驱动的时候，写一个比较完整的，或者专门针对这个驱动的。
有人说使用可以用setkmode去让ap临时进入kernel模式，然后在对内存进行操作，对这个不是很理解。
请达人出来指点一下。
[解决办法]
IOCTRL---MmMapIoSpace
[解决办法]
unsigned int *gpio_base;
PHYSICAL_ADDRESS PortAddress = {0x56000060, 0};
gpio_base =(unsigned int *)MmMapIoSpace( PortAddress, 0x04,FALSE ); // 获得内存
*gpio_base = 0x0585ff87; // 直接访问硬件
MmUnmapIoSpace(gpio_base,0x04);//释放内存
[解决办法]
要看你是写应用、写用户态驱动还是内核态驱动。应用和用户态驱动一样，都无法如ce5的方式访问。
下面是我写过的一段内容，参考一下吧：
有些函数在用户态是必须注意使用的，如VirtualCopy和类似的MmMapIoSpace。用户态程序不允许使用VirtualCopy，但是用户态能通过转接服务来实现这功能。转接服务能代替用户态驱动来调用VirtualCopy，但是前提是转接服务要知道这些地址是可以访问的。在驱动的注册表入口，键值IOBase和IOLen来指出地址的位置和大小。当驱动使用VirtualCopy来，转接服务会检查这些键值，确保驱动能正常访问这些物理地址。下面是串口驱动的例子：
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial]
"IoBase"=dword:02F8
"IoLen"=dword:8
如果只有一块地址需要访问，使用dword类型。如果是多块地址，那么使用multi_sz类型。
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial]
"IoBase"=multi_sz:"2f8","3f6"
"IoLen"=multi_sz:"8","2"
由于这些地址只能被有特权的应用程序访问，那么需要确保这些地址不能被非特权程序访问。
用户态驱动不能调用以下函数：
1、VM虚拟内存函数：VirtualCopy[Ex], LockPages[Ex], CreateStaticMapping
2、中断函数：InterruptInitialize, InterruptDone, LoadIntChainHandler
3、不能直接使用IISR，需要通过转接服务来做GIISR。
4、OAL层的IOCTL不能直接使用。
禁止从用户态驱动回调任何进程。你不能在总线驱动中回调一个内核态的client驱动。如果一个总线驱动放到用户态运行，只能把总线上的client驱动也放到用户态中。那么这个总线上所有的client驱动，都必须和总线驱动放到同一个udevice进程中。
有些OEM厂商可能会把一些OAL IOCTL和函数，通过编写特有的转接服务，让内核态驱动提供给用户态使用。值得注意的是，通过内核态驱动来公开这些功能，实际上是公开了微软特意封装的内容，最好不要这样使用。
[解决办法]
应用程序通过createfile打开驱动，然后通过deviceiocontrol发指令给驱动，让驱动完成任务后将所需的参数再回传给应用。这种方式，CE5和CE6应该都是通用的吧！！这也是应用直接操作驱动从而操作硬件啊！
[解决办法]
UPX 3.03压缩的，解压之后用IDA打开，辅助Resource Hacker。一目了然。
googleman，我恐怕你要失望了。这个软件仍然是用驱动的，这个软件把驱动作为资源打包到PE里面去了。
首先，注意以下特征：
.data:00028490 aMemdrv unicode 0, <MEMDRV>,0 ; DATA XREF: .text:off_11A2Co
.data:0002849E ALIGN 0x10
.data:000284A0 aOpenDrvfileErr DCW 0xD ; DATA XREF: .text:off_11A30o
.data:000284A0 DCW 0xA
.data:000284A0 unicode 0, <Open drvfile Error %d>,0
.data:000284D0 aWindowsMemraw_ unicode 0, <\windows\memraw.dll>,0
.data:000284D0 ; DATA XREF: .text:off_11A34o
.data:000284F8 aMem1 unicode 0, <MEM1:>,0 ; DATA XREF: .text:off_11E28o
.data:00028504 aOrder unicode 0, <Order>,0 ; DATA XREF: .text:off_11E2Co
.data:00028510 aDll unicode 0, <Dll>,0 ; DATA XREF: .text:off_11E30o
.data:00028518 aMemraw_dll unicode 0, <MEMRaw.dll>,0 ; DATA XREF: .text:off_11E34o
.data:0002852E ALIGN 0x10
.data:00028530 aPrefix unicode 0, <Prefix>,0 ; DATA XREF: .text:off_11E38o
.data:0002853E ALIGN 0x10
.data:00028540 aMem unicode 0, <MEM>,0 ; DATA XREF: .text:off_11E3Co
.data:00028548 aIndex unicode 0, <Index>,0 ; DATA XREF: .text:off_11E40o
.data:00028554 aDriversMemdrv unicode 0, <Drivers\MEMDrv>,0 ; DATA XREF: .text:off_11E48o
.data:00028572 ALIGN 8
其次，用Resource Hacker打开，证实了我的猜测。有个命名为memdrv的资源，首字节是'MZ'，这不用多说了吧。
[解决办法]
一不做二不休，再看看提取出来的memdrv.dll都导出了什么：
MEM_Close
MEM_Deinit
MEM_IOControl
MEM_Init
MEM_Open
MEM_PowerDown
MEM_PowerUp
MEM_Read
MEM_Seek
MEM_Write
接着再看看它导入了什么：
MmMapIoSpace
MmUnmapIoSpace
LocalFree
