我找到的是MS做kernel内存管理的developer,所以应该是最权威的了. 目前驱动程序唯一能达到访问4gb以上地址内存的方法是通过一个ddk api: MmMapIoSpace. 其实这个api本来是用来给设备驱动程序进行特殊的地址映射用的,并非用来管理内存.

简单地说, bios会把可用的内存映射到一个并不一定连续的物理地址空间中,比如0地址开始的一段空间需要留给bios自己所以无法映射内存, 3gb-4gb范围内的地址有可能留给各种pci设备,也不能用作内存,这也是为什么win7 32bit在4gb地址线下看不到全部4gb内存的原因.

当然如果bios支持memory remap,那么多余的内存会比map到4gb以上的地址空间,而由于目前win7 32bit强行忽略掉了这部分mapping,所以即使bios map了也不会被使用.

ramdisk 4g的原理就是使用MmMapIoSpace来强行读写4gb以上的地址空间,注意是跳过操作系统的强行读写,把这段地址当作是io设备来操作,而并不一定是内存.

这种做法,主要有两个问题:

第一: 作为驱动程序,你是无法确切地知道究竟哪段物理地址空间里面是映射的你的多余的内存,目前的bios架构中,只有通过中断int 25, function 0xE820才能获知, 而这个bios中断只能在实模式下调用,也就是说windows启动之后,驱动程序是无法调用这个中断去获知的. 那么,ramdisk驱动就只能靠猜, 比如说他可以知道你装了4gb内存,而目前只认了3.5gb, 那么多出来的512m应该在4g-4.5g这个物理地址段.

但是,这个只是猜测,bios并不一定会把多出来的内存映射到那里, 也可能是4.1g-4.6g区间,甚至不一定是连续的空间. 而且,各种奇怪的硬件设备也有可能自己占用特殊的物理地址空间,比如假设有一块硬件占用了4g开始的16m空间,那么显然这段地址里面就不再是内存了.

好吧,那么如果ramdisk强行去读写错误的地址空间会如何呢? 简单地说: cpu不会报错, 但是结果是不可预料的, 比如如果这段地址空间根本是一个memory hole,那么往里面写东西就是白写,读操作返回的有可能都是0xFFFFFFFF, 这样地话,作为一个虚拟磁盘而言,其结果就是数据损坏.

更为严重的是:如果有一块特殊的硬件的io空间映射在4g以上的一段地址,而ramdisk强行去写入数据,就会直接对那块硬件进行io操作,有可能会损坏硬件或者发生更奇怪的事情,比如该设备莫名其妙开始工作了等等.

第二: 即使你的运气很好,bios把多余的内存正好连续地映射在4g开始的空间,也就是ramdisk完全猜对了的情况,还有一个问题是,ramdisk无法保证有没有其他任何代码也会去读写这段地址空间. 因为ramdisk是跳过os的内存管理直接进行io的,其他驱动程序也有可能做相同的事情,这样的结果一样是数据损坏. 比如ramdisk先往里面写了一个文件的内容,之后另一个驱动程序也在相同地址写了一些其他数据,那么ramdisk再读出来的时候就拿不到原来的数据了.

综上,在你无法100%确保以上两点肯定没事的情况下,使用ramdisk还是有风险的,最坏情况是用户数据丢失甚至硬件设备损坏.

其实真的要用超过4g内存,还是有其他更安全的办法的,比如换64位系统,或者用server版本(完全支持pae的),或者直接patch kernel (这个在上面的帖子里面有链接,可以在vista 32位里面直接用到128g内存)

如果真的一定要用ramdisk,请在设置好之后一定要做一个测试: copy一个可以撑满ramdisk大小的真实文件(比如电影之类),然后再从ramdisk里面copy出来,再用fc /b和原始文件进行二进制比较.多做几次测试,以确保正确性.每一个使用ramdisk的机器都应该做这样的测试,因为每台机器bios映射的方式可能不一样.

当然这个只能基本确保第一个问题不存在,还是无法排除第二个问题的可能性.万一有个驱动突然想起来往4g以上某个地址写点东西的话,你的文件就坏了