中国DOS联盟

以下是引用不点在2004-7-9 上午 09:34:35的发言：
光盘支持不是由我制作的, 完全是 GANDALF 兄制作的. 我现在没有时间顾及这个, 以后有时间再细看.

我现在的兴趣集中在捏合 BOOTGRUB 和 GRLDR 上了. 这个我早就有打算, 只是没有时间做. 现在差不多了.

不知为什么还是不行? 源程序在这里:

ftp://ftp2.linuxeden.com/tools/grldrstart.S

麻烦大家一同看看毛病在哪?

wengier 说 FAT16 不行, 那么 FAT32 以及 NTFS 怎么样呢?

我用FAT32和FAT16的均启动不了,选择菜单后按回车就死机.

注:我的FAT32分区是第二个分区,第一个分区是FAT16的.

第一个分区是 FAT16, 它只要失败, 总是失败. BOOTGRUB/GRLDR 总是查找第一个分区.

所以, 请用另外一个 FAT32/NTFS 的 C: 分区进行测试.

另外, 如果大家都猜测是 NTFS_CDROM 补丁的问题的话, 我可以去掉这个补丁重新编译一次.

GRLDR启动不了应该不是NTFS_CD补丁的问题.前面那个支持NTFS和CD的BOOTGRUB+GRLDR就可以正常启动,只是后来两者结合成一个GRLDR后就无法正常启动了.

我用BOOTGRUB+两者结合后的GRLDR可以启动FAT16和FAT32

麻烦 chenall 兄再测试一次, 这次用 GRLDR 的开头 4 个扇区制作一个 BOOTGRUB 文件, 看看可否用这个 BOOTGRUB + GRLDR 来启动.

以下是引用不点在2004-7-9 上午 03:03:40的发言：
麻烦 chenall 兄再测试一次, 这次用 GRLDR 的开头 4 个扇区制作一个 BOOTGRUB 文件, 看看可否用这个 BOOTGRUB + GRLDR 来启动.

请问BOOTGRUB文件在哪里下载?
是这个吗?
ftp://ftp.linuxeden.com/tinybit/bootgrub

我是说用 grldr 开头的 4 个扇区制作一个 BOOTGRUB 文件, 然后用它启动 GRLDR 文件.

我这里测试的结果, 仍然失败. 但是这个 BOOTGRUB 却可以启动以前老的 GRLDR 文件. 我的测试环境是 NTFS.

看来新的 NTFS_CDROM 补丁确实有问题.

我在VMWare虚拟机的FAT32主分区下又试了一下，用新的grldr开头的4个扇区制作成的bootgrub或以前的bootgrub启动grldr（不管是新的grldr还是旧的grldr）都非常成功，可以正常启动；但若在boot.ini中直接启动grldr则总是失败。我在真实机的FAT16主分区下测试的情况也完全相同，可见在各种FAT分区上的情况是一样的。因我没有NTFS的主分区，所以无法在NTFS上测试。因此，并不能证明NTFS_CD补丁有问题。可能是因为GRLDR不能如此结合才导致不能直接从结合后的GRLDR启动，而bootgrub+grldr则总是成功。

wengier 的测试, 给我的整合计划判了死刑.

不过, 成功有代价, 失败也有代价. 虽然此处失败了, 但我们还要继续.

现在是动脑筋的时候了. 我们不是从 GRLDR 截取 800 字节, 它就可以正常启动了吗? 现在我们提出一个问题: 究竟最大可以允许多大的 BOOTGRUB 字节数? 800字节成功了, 132872 字节失败了, 中间一定可以找到一个成功的最大值, 呵呵, 这个有另外的用途...........

我刚才试了一下，bootgrub的最大值好像是8191字节（即8KB减去一个字节）。再多一个字节都不行。

OK, 我刚才也得到这个结果, 正好是 16 扇区减去一个字节, 也就是 8191 字节.

这有两种可能:

1. 微软判断一个引导扇区文件, 如果小于 16 扇区, 它就认为合法, 否则, 它拒绝采用.

2. 微软可以采用任何大小的引导扇区文件, 但是具体装入内存之后, 可能覆盖掉了微软的程序, 导致控制无法传递到我们的 BOOTGRUB 来, 因此导致死机.

不管怎样, 现在好像 8191 个字节是安全了. 请大家多多测试, 看看在别的机器上这是否安全? 用其它任意字节例如 0xff 填充 bootgrub 的尾部, 看看结果是否一样(是否还是8191这个极限)?

注: bootgrub 只有开头 512 字节起引导作用, 其它字节都用不上, 都可以填充为任意字节.

=============

现在应当做另外一个试验, 这次只要 256 次就可判断出来了.

制作一个 8192 字节的 BOOTGRUB 文件. 我们知道 8191 字节是通过了, 我们假定微软采取上述第 2 个方案.

于是, 我们只需要改变 8192 字节中的最后一个字节, 将它从 00 一直变到 FF, 生成 BOOTGRUB_00 至 BOOTGRUB_FF 共 256 个文件. 我们看看这些文件是否有一个会成功. 如果微软采取的是上述第 2 个方案, 则肯定有一个 BOOTGRUB_xx 要成功的. 如果全部失败, 则可以肯定微软不是采用第 2 个方案, 而是采用第一个方案.

刚才那个我只试了不到10次就得出8191字节这个值了，这回要试256次（当然，有可能小于256次）呀？

能说一下测试bootgrub的最大长度的主要用途是什么吗？

如果微软是采取第 2 种方案, 那就是说, 它首先把 BOOTGRUB 读入内存, 那么, 我们在 BOOTGRUB 接管控制之后仍然可以查找内存中的 BOOTGRUB 映像. 这样, 我们就可以在 BOOTGRUB 中放入更多的代码, 而不是只有 512 字节了. 这个 512 字节的空间, 确实太狭窄了, 扩展的程序, 只好写入 MBR 之后的扇区, 这很不舒服. 如果有 8K 的代码空间, 我们就可以支持很多文件系统了.

不过无论MS是用的第一种还是第二种方案，现在不是已经基本上证明了8KB的bootgrub空间是安全的了吗（除非有网友报告说有问题）？8KB的空间对于支持各种文件系统来说自然已经是完全足够的了，连2KB就足以支持各种FAT和NTFS分区了。而如果是想将bootgrub的内容写入mbr及其后的扇区的话，那就与ntldr的限制无关了，即使再去测试也没有什么用处。

刚才看了故障恢复控制台的bootsect.dat文件，大小为8192字节，从cd4h后均为0
即最后一个字节也为0