|
回复 #26 zhaohj 的帖子
好了,这下就全清楚了。
先前由于没有贴 BIOS 数据区的内容,所以仅仅凭借 int15 的显示来说话。但 int15 在常规内存中不具有 “话语权”,因此,先前的分析是无效的。
在常规内存中,真正具有事实工业标准地位的是 0x413 处的 “常规内存总量”。
在 PXE 启动时,常规内存总量变成了 517K,如果此时使用 map,则会占据 12K,结果,常规内存将会减少到 505K。这正是 Windows 报告的数值,无法启动 Windows。
就是说,DELL 的 PXE 是很糟糕的。它的 EBDA 也是很糟糕的。
EDBA 通常只有 1K,2K 或 4K,而 DELL 的 EDBA 占据 16K。
DELL 的 PXE 又占据了 624K - 517K = 107K。
EBDA 和 PXE 两者总共占据 123K。这就造成 grub4dos 的 map 没有足够空间可用的情况。
======================================
剩下一个疑问:为何旧的 grub4dos 能够启动 Windows?
旧的 grub4dos 的 map 没有修正 int15,而 Windows NT 则使用 int15 来确定常规内存。由于旧的 int15 完全没有保护 12K 的仿真代码,即,相当于这些代码不占据常规内存,因此,骗过了 Windows NT 的启动程序。经过 karyonix 修正的 int15 则保护了 12K 的仿真代码,于是,Windows 就发现,内存不够了,因此,Windows 拒绝继续运行。
好了,这就完全解释清楚了。karyonix 的代码,并未表现出错误(其实也有小错误,不过没有影响到 DELL 这台机器的情况,这些小错误以后也会加以更正的)。它只是太真实了,所以,反而无法启动 Windows 了。
已经证明了,问题的根源在于 DELL 的 PXE 代码以及 EBDA 占用了过多的内存,只剩下 5K 的空间留给别的程序(例如磁盘仿真)使用。这是 grub4dos 无法启动 Windows 的根源。解决办法正如前面所说,可以使用 memdisk 来代替 grub4dos,也可以使用 wee127 等,不再重复说明了。它们可能只需要 5K 就能完成仿真的任务。
===================================
从这一系列的报告中,我们可以了解到不少知识。
其一,主板制造商用 0x413 来指示常规内存的占用情况。而在主板的 int15 中,根本不反映常规内存的占用情况。这一点与以往所公布的资料是一致的。这确立了 0x413 (在常规内存方面)的事实工业标准地位。
其二,Windows NT 不使用 0x413 这个具有事实工业标准地位的规范,它反其道而行之,使用 int15 来确定常规内存的使用情况。旧版的 grub4dos 之所以能够 “蒙混过关”,就是因为省略了 int15 的步骤,导致仿真代码(所占据的空间)实际上处于不被 int15 保护的状态,使得 Windows 以为仿真代码没有占用空间,因而幸运地启动了 Windows。新的 grub4dos 之所以不能启动 Windows,则是因为增补了 int15 代码,让 Windows 明白,仿真代码占据了 12K 的空间,于是,Windows 发现,总的剩余空间不够 512K,从而拒绝启动。所有这一切证明了,Windows NT 并不看 0x413 处的值,而只看 int15 的返回结果。
好了,我们已经知道了,硬件制造商和微软(确切地说,是微软的 NT)使用的是不同的规范。在 DOS 和 Win9x 时代,大家都使用 0x413 这个统一的规范(那时候,甚至 int15/E820 这个规范都可能是不存在的,或者刚刚诞生不久)。
======================
以上就是这一系列报告的概况(或综述)。至于说如何解决这一问题,大家先发表各自的意见吧。 |
|