HITEA 版 (精华区)
发信人: hfl (凤凰·风中轻舞), 信区: HITEA
标 题: VxD世界——Win95 内存揭秘
发信站: 哈工大紫丁香 (2002年04月02日20:47:25 星期二), 站内信件
上期“走进VxD世界”中我们谈到了Win95中0~4MB线性内存空间分配情况。下面
我们接着讲余下的4MB~4GB线性内存空间的分配。
4MB~2GB
Win32应用程序的代码、数据和资源都存放在这段内存中了,这部分内存,对于每
个Win32应用程序来说都是私有的。这里是最能体现保护模式分页机制作用的地方
。两个Win32应用程序,对相同的线性地址(4MB~2GB范围内)进行读写,实际
上,它们是在对不同的物理地址进行读写。让我们算一下,这段内存对应多少个
Page Directory Entry。我们知道一个Page Directory Entry对应4MB线性内存,那
4MB~2GB的内存就对应于1024 / 2 - 1 = 511个Page Directory Entry。也就是说
Win95通过操纵这511个Page Directory Entry实现了Win32应用程序“独立”的线性
地址空间。打个比方来说吧,现在有511个抽屉,上帝告诉A说:这些抽屉里都是金
币,同时告诉B说:这些抽屉里都是银币。并规定只有上帝能打开抽屉。其实抽屉里
可能只有一枚铜板,也可能什么都没有。这时,A想看看某个抽屉里到底是不是金币
,于是上帝就背地里临时往那个抽屉中放一个金币,然后打开抽屉让A看,于是A就
信了。这个伎俩同样作用于B,B也相信了那511个抽屉里都是他想要的银币。保护
模式下的操作系统(这里当然指Win95)就相当于上帝,而被骗的A和B就相当于运
行于保护模式下的Win32应用程序。那只操纵抽屉的上帝之手就是分页机制。
2GB~3GB
这部分内存空间我们称之为“应用程序共享内存区”,这里存放着Ring 3级应用程
序需要共享的数据和代码。其中包括Win95系统DLL(如User32.dll,Kernel32.dll等
)、内存映射文件、Win16应用程序以及DPMI调用分配的内存。
通过把要共享的数据映射到2GB~3GB之间的线性内存空间,可以实现Win32应用
程序间的数据共享。
Win16应用程序是需要共享线性地址空间的,这是Windows 3.1的历史遗留问题。为
了使以前运行于Windows 3.1的Win16应用程序能在Win95下有同样的运行效果,于
是Microsoft决定把Win16应用程序放到这段共享内存区来运行。应该说这是比较合
理的决策:既省时省力,又保证了对上一代产品的良好兼容性。
再从分页机制的角度上来思考一下这段“共享内存区”是如何实现的。2GB~3GB
的线性空间对应着256个Page Directory Entry。无论谁在运行,Win95都不会改变这
256个Page Directory Entry,也就是说2GB~3GB的线性地址空间对应的物理地址
是一样的。这样,Win95什么也不用做就实现了2GB~3GB线性地址空间的内存共
享。
3GB~4GB
这部分内存空间称为“系统内存区”。只有Ring 0级的VMM和VxD可以访问这部分
内存空间。这部分内存也是共享的。虽说Ring 3的应用程序无法直接共享这部分内
存空间(也就是说SDK中讲述的方法无法做到),但是我们还是称之为共享内存区
,至少从分页机制的角度上说,对应于这部分内存的Page Directory Entry是不变的
。其实Win32应用程序还是有办法访问这部分内存空间的。一般作法是,在VxD中分
配一块内存,然后把指向那块内存的32位地址指针传给Win32应用程序,这样就可
以在Win32应用程序中直接访问那块内存了。前面我们在讲0~4MB内存空间时,提
到High-linear address,即DOS VM备份的地方,就在3GB~4GB内存空间中。
对于Windows应用程序开发者来说,实现内存共享有时是非常重要的。对于VxD开
发者来说,还应注意,对于经常需要存取的共享内存页面,必须调用VMM的
_LinPageLock服务进行锁定,否则会出现Out-Of-Context Memory Reference。
--
@..@
(\--/) 注意:不要因为上网熬红了你的眼睛
(.>__<.)
^^^ ^^^
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.229.253]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
页面执行时间:4.128毫秒