支持含有碎片的文件仿真

不点

这是技术，是开发者的开发构想，与天朝的教育、与西方的哲学，都扯不上太大的关系。

我无权干涉别人对现状的不满。我也曾经不满现状。甚至正是因为不满现状，才有动力去改变现状。

但是到了我这样的岁数，我已经对现状比较满意了。

谁来封杀 grub4dos，或者不封杀，随便，我都能接受。我给我自己减负，我逐渐远离 IT 技术。

我也在用我自己的认识、通过自己的努力，把自己投身到这个丰富多彩的世界当中。

尽管有很多不尽人意的地方，可是这世界还是非常美好的。

这世界不是坏了需要修理，而是已经不错了，只是需要建设得更加美好罢了。

目前我的认识水平，就是这样的，想再提高，也不那么容易了。

不点

Hmax 是最大磁头号，不是磁头总数，所以，Hmax 最多只能是 255，不可能是 256。

通常 Hmax 取值为 254，也就是说，保证磁头总数可以用一个 byte 来表示。

而 Smax 更是不可以超过 63。怎可能是 0xff 呢？

不点

即使 S 和 H 错误，也不应该自动设定 in-situ 的值。只要你的命令行中没有设定 in-situ，它就不该设定。

又怀疑是 gcc 的问题了。假如有人攻击了 gcc，那么大部分开源软件都要瘫痪。

不点

那你就跟踪一下，看看什么地方的漏洞导致 S 和 H 探测出现重大错误。

不点

Try （hd1） 就有问题，没显示分区号，不正常。因此，代码需要继续锤炼。

不点

mdyblog 发表于 2015-2-9 17:25
反应个现象。
为什么GRUB4DOS访问盘末尾是出现 “不支持LBA64”？
盘才６４Ｇ，　32位LBA 地址就够了。

出错信息是 qemu 的主板 BIOS 发出的，不是 grub4dos 发出的。

1、试试 0.4.5，看看是否有相同的问题，方便开发者追踪问题的根源。
2、盘上的分区表是否不正常？假如分区起始扇区号为 0xFFFFFFFF，分区长度为 0xFFFFFFFF，那么这就可能超出 32 位的范围，需要访问 64 位的扇区号了。

to 开发者：

用跟踪调试等手段检查代码，看看什么代码导致 64 位的扇区号被传入主板 BIOS int13，造成问题。

不点

刚刚想到，你也是开发者，你也可以直接调试。

扩展分区里面的逻辑分区表，如果有毛病，照样有可能引起死机。比如，错误地指向了一个很大的扇区号，造成问题。



补充：确实如你所说，有可能是 qemu 自身 bios 的毛病，比如说，它在读取尾部的扇区时，自己出现了 bug。

你可以试试别的虚拟机，如果别的虚拟机没毛病，那就可以确定是 qemu 的毛病了。

不点

chenall 发表于 2015-2-10 08:53
这里又有报告0.4.6a的问题的

https://github.com/chenall/grub4dos/issues/37

这个报告依旧显示 try (hd0)，没有正常显示分区号。因此 0.4.6 仍然含有逻辑错误。

不点

2011yaya2007777 发表于 2015-2-10 21:25
请测试：http://bbs.c3.wuyou.net/forum.php?mod=attachment&aid=MjA5MjI2fGIxZDgzZTE3MmIzZGUxNmE0MjU3ODJiOTViNDlmYjhhfDE3MTc3NzM3MDM%3D&request=yes&_f=.7z

你可以贴在报告问题的那个网站上。或者你就直接提交修改后的编译结果，那些高手们都是每天下载最新版测试的，他们很敬业。

不点

mdyblog 发表于 2015-2-11 14:21
请问 C写的外置命令中怎
调用
#define builtin_cmd ((int (*)(char *cmd , const char *arg, int flags)) ...

建议看看这些函数的原来的函数的定义。这些函数都是指向内部的某个函数，它们的定义在 asm.S 文件的结尾处。flags 与内部函数的 flags 的意义是一样的，大多数情况下，函数体内部的处理过程都忽略 flags 的值，但也有少数例外。

不点

sunsea 发表于 2015-2-11 16:33
我现在有个磁盘，他的0扇区有一个隐藏分区（FAT16）的bpb还有一个正常分区的分区表，分区表没有隐藏分区 ...

0扇区（即 MBR，换句话说，是最开头的那个扇区）有一个分区的 BPB，以及一个分区表。单看这句话，grub4dos 肯定支持。这里根本不存在隐藏这回事。

比如说，你这个盘是 (hd0)，那么，你用 (hd0)/ntldr 即可访问你的 FAT16 的根目录之下的 NTLDR 了。

至于说分区表，照样起作用，利用分区表，你可以访问其他分区，例如 (hd0,0) 之类的。

不需要任何技巧，这些概念属于 grub4dos、文件系统等一系列概念中的基本功。

不点

你的 BPB 肯定有误，无法指向正确的分区位置。下面举例说明可能的错误大致会是什么样的：

位于偏移 0x0E 处的两字节 “保留扇区数” 错误，导致 grub4dos 无法找到该分区的 FAT 表。保留扇区数是 FAT 表之前的扇区数。不可以复制分区引导扇区上的数值，既然现在引导扇区位于 MBR，那么，FAT 表之前的扇区总数就得重新计算，它应该等于第一个 FAT 扇区的扇区号（MBR 的扇区号为 0）。

位于偏移 0x1C 处的四字节 “隐藏扇区数” 错误，导致 grub4dos 无法找到该分区的引导扇区。此时，它应该是 00 00 00 00 才对，因为它位于 MBR。

不点

sunsea 发表于 2015-2-11 17:32
啊，我知道了，bOOTICE把bpB拷贝错误了，现在知道了，谢谢

由于保留扇区数只是一个 2 字节的整数，其最大值也不过只有 65535 而已，因此，你的 FAT 应该是磁盘上的第一个物理分区才行（在物理上靠近磁盘开头），否则，当它靠后时，所需要的保留扇区数很大，超过 65535 个扇区，这样就不能用上述简单办法来访问了，需要动用 map --in-situ 或者 partnew 之类的技巧才行。

不点

用 map --in-situ 吧。用法大致是：map --in-situ (hd0)XXXXXX+YYYYYY (hd0) ; map --hook;

这条命令可以把一个扇区序列仿真为一个硬盘的第一分区，即 (hd0,0)。此时，你用 (hd0,0)/ NTLDR 就可以访问你的 FAT 文件系统下的 NTLDR 文件了。

用完之后，立即用 map (hd0) (hd0) 卸载仿真，然后用 map --rehook 使卸载生效。

当然另外一种方法，也可以用 partnew 命令来实现，你自己研究吧。reboot.pro 上有很多帖子都讨论过 partnew 的使用技巧。

不点

sunsea 发表于 2015-2-11 18:25
如果情况更极端一下，只知道bpb所在扇区呢

自己多动手试验吧，理论掌握得再多，也需要在实践中检验，才能成为可靠的理论。只有自己亲自摸索，才能把理论变成自己的知识。自己在摸索的过程中，还能有新的发现，那就切实成为自己的知识了。

不点

chenall 发表于 2015-2-13 13:42
我不明白这个 “运行当前程序的 命令行” 到底具体指的是什么,

我猜测是要获取到当前"正在运行的命令" ...

他要的大概是 当前正在运行的程序的命令行参数。

就是当一个外部程序被执行时，用户提供的命令行参数是什么，这个外部程序的作者，希望能够得到命令行参数，以便根据命令行参数的变化而采取不同的处理。

不点

mdyblog 发表于 2015-2-18 16:56
>>忘了更新了,早期的版本0是批处理本身后面发现这个没有什么用处
也就是 说 原来是从1开始的。
其实 ...

谢谢您，谢谢所有的朋友们。借此顺祝各位喜气洋洋，洋洋洒洒，阳光灿烂，扬眉吐气。

淡出之后，看到你们继续前进，由衷高兴。

希望开发者们注意身体，不要熬夜，稳步前进，不急不躁。

不点

从 ud 盘启动时，ud 可以访问。如果转而启动另一个 grldr，则已经不是从 ud 盘启动了，而是相当于从 bios 直接启动了某个引导扇区，不是从 ud 启动，也不是从光盘启动，此时 ud 是不能访问的。

解决办法：不要在 grub 环境又启动一个新的 grub 环境，丧失原来的 ud 访问能力。

不点

我说的是现状，你说的是要改变现状，不是一个概念。很抱歉，我帮不了了，我退出这个话题。

下面是想说给开发者的。

一个软件在功能上尽量可以去完善。但有时候，功能的完善与硬件兼容性发生冲突，迫使你放弃一部分功能，而保证兼容性。一切都是权衡，并无什么绝对的正确性在里面。看问题的角度不同，正确性的概念也不同。也并非所有的用户所提的要求，你都能满足。有可能你满足了一部分用户的要求，却带来了另外的问题。软件不是万能的，它能解决大部分问题，就是基本成功的。如果要以极限挑战的眼光去看问题，那就是企图让功能性达到丰满，这有可能以某种方式损坏兼容性。本问题所提到的 ud 被屏蔽，是我做的。因为grldr启动的时候，要检查是否从ud启动。如果是的，则把 ud 区当作当前 root 区，跳过其他启动步骤。把 ud 区当作当前默认 root 的好处是，ud 区靠前，能够最大限度地适应各种恶劣的 bios 环境。因为优先检查 ud，所以，当后续不是 ud 启动时（比如启动某个软盘映像时，或者启动硬盘的 Windows 时），就不能继续再把 ud 区当作当前 root 了。为了避免 ud 标志被后续的 boot 命令检测到，我在第一次检测 ud 之后，就抹掉了 ud 标志。此时 ud 已经被承认，但后续的启动，如果不是直接模拟 bios 而加载 ud 的第一扇区的话，则无法检测到 ud 标志了，因为这是故意屏蔽掉了。我这说的仍然是现状。至于说这样做是否合理，那我可不敢保证。那将由现在的开发者去权衡和决定。假如能够把这个问题做好，达到两全其美，那也是好事。假如不想动脑筋，不想太费劲去思考这些逻辑问题，那可以保持现状。一句话，看开发者的裁决而定。

在我维护 grub4dos 的时候，对于用户所提的问题，如果我能去解决，我尽量自己去做，这样自己就放心，那是因为自己精力充沛，同时也担心别人做的不符合自己的想法。所以都是尽量由自己来完成。假如我自己完成不了，那我就坦率承认自己做不了，放弃。放弃之后，有可能别人能够做这个工作，那么，这就涉及到这个工作如何融入 grub4dos 的问题。肯定不是无条件都可以随便融入的，一定要经过检验。新的工作往往会带来新的问题。有时候，问题很快都会暴露。但有时候，问题潜藏很深，需要很多年才能暴露。举例来说，原来的 gnu grub legacy 里面的 ntfs 代码有问题，我没有能力写 ntfs 代码，甚至也没有能力看懂 linux 当中的 ntfs 代码，所以，无法解决 ntfs 的有关问题。后来 bean 加入了团队，bean 能够做这个工作，目前的代码就是 bean 的。bean 做这个工作的同时，也把旧的代码保留了下来，好像取名为 fsys_ntfs.old，那意思是，万一不行，还可以恢复原始代码。经过多年的检验之后，确实没问题，所以，旧的代码好像已经删除了。新的代码其实也不是完全没问题，多年以后，chenall 和 yaya 都发现了一些问题，并解决了。还有一个例子是，yaya 对于 grub4dos 的改进和增强。我们看到了，有些问题，例如 mbr 和 pbr 代码中的问题，是最近才发现和解决的。可见，有些问题会潜藏很久。我们为什么长期以来都维护了两个版本，一个是 0.4.5c, 一个是 0.4.6a，那就是因为，对新的功能需要有一个锤炼的过程，新功能有可能影响启动的成功率，也有可能带来兼容性等其他问题。假如这些问题都能得到解决，那么大家就可以放心地使用新版本了。旧版本作为一个参照物，永远保留着它的价值。不同的用户根据自己的需要，选用不同的版本。gandalf 提供的 scdrom 代码，好像存在内存冲突，不稳定，后来由我移植 smart boot manager 的 cdrom 代码，替换了 gandalf 的代码。同样是 gandalf，他所做的基于 vga 图形模式的中文化代码则非常稳定，我们一直保留了下来，直到我们彻底转向 vbe 之前。cdrom 驱动支持是 gandalf 首先引进的，他有首创之功，不可抹杀。我所说的重点在于，代码的稳定性以及后续的表现，是需要锤炼的。这决不等于否认初始工作的价值。类似地，bean 所做的 gfxmenu 图形菜单，也是填补了当时的空缺。只是因为 gfxmenu 天然的独立性，它不同于 grub4dos 的内置代码，它是调用外部的 message 里面的代码，所以，不容易与 grub4dos 无缝对接。所以，我们后来推荐采用新的 vbe 图形菜单模式。karyonix 提供的好几个补丁，都直接采纳了，经过后续若干年的检验，证明是没问题的。大家熟悉的 winvblock 软件的作者是 shao miller，他同时也是 syslinux 的开发团队成员。他所提供的一个与 eltorito cdrom 有关的补丁，刚一开始时，我觉得可以采纳。但后来我仔细想想，还是严格要求吧，是技术就得讲技术，在较好和最好之间就有那么一点点差别，既然能够做到最好或更好，就不能退而求其次。我以 "应该避免占用宝贵的 int13 代码空间" 为理由，在得到 chenall 的同意之后，撤销了 shao miller 的补丁。同时我对 eltorito.sys 这个软件打了补丁，并且纳入到 grub4dos 内部一起维护。这属于 "两种做法都能达到目的，但究竟哪种最好？" 的问题。我主张修改 eltorito.sys 这个软件，而 shao miller 主张修改 grub4dos 的 int13 处理程序。这就是分歧所在。假如是仅凭感情和照顾面子，那确实应该采纳 shao miller 的补丁。但我反复思考，觉得不采纳他的补丁，是对 shao miller 最大的尊重。因为我觉得，那是对他提出了更高的要求，他不属于那种需要照顾面子的人，因此我其实是承认并尊重了他的水平。如果要照顾某个人的面子，实际上则是否认了这个人的高水平，因此适得其反，反而照顾不了他的面子。在我看来，指出一个人的工作中的瑕疵，就是对他的一种极大的尊重。同样地，假如有人指出我的缺陷，我也认为是对我的尊重，是瞧得起我。补充：从后来的实践以及今后长远发展的眼光来看，保持 int13 不被更改的这个做法，其合理性似乎越来越明显了。dos 越来越不适应恶劣的bios环境了，现在 dos 基本上都是作为第二启动，即，首先启动 grub4dos 或 syslinux，然后才能启动 dos。尤其是 dos 作为 eltorito 光盘的主角，已经很不常见了。grub4dos 的用户群，主要是 windows 的。因此，假如仅仅为了很狭窄的、越来越边缘化的领域而修改 int13，那么这种修改，其使用率极低，绝大多数情况下都用不上。而它占用 10 多个字节的宝贵的 int13 代码空间，就越发显得不合理了。所以任何事情都是权衡。也许某件事乍一看是合理的，但经过某种仔细权衡和分析以后，其不合理性就暴露出来了。

过去了的事情，都是历史。历史是可以借鉴的，历史也是可以评判的。没有绝对的正确与错误，只有自己的权衡和倾向。这世界很大，自由度也很大。尤其是对于开源软件来说，自由度是相当大的。自己不满意的事情，可以有很多种处理办法，包括另起炉灶。当初我给 gnu grub 开发团队提交补丁，未被采纳，所以我就被迫另起炉灶。这是完全可以复制的，"另起炉灶" 永远是一个选项。任何人，只要他愿意，他都可以另起炉灶。

现在我离开开发者的行列了，我不再做决定和权衡了。我以往所做过的事情，完全可以被借鉴。当然那些不妥的，也应该予以纠正。这由现在的维护者来负责。

我有我的优点和缺点。从最近几年与各位维护者、开发者和坛内外朋友们的交往来看，我体会到了高手如云。记得以前有人说过，胡荣华并非象棋第一人，民间有很多不曾露面的高手可以完胜胡荣华。我个人目前的特长和优势不在电脑技术方面。举例来说，chenall 和 yaya 非常棒。我在疗养期间，亲眼目睹 chenall 和 yaya 的配合，他们的电脑技术水平都在我之上，因此我也真的感到高兴，因而也彻底放心了。尽管我的英文也是下三烂的水平，我愿意在有机会的时候，能够替开发者们做一些力所能及的工作，因为我发现，目前活跃的这两位开发者，似乎都不太擅长英文。

想到了 jaclaz 这个意大利人，就多说几句。他后来改名为 wonko the sane。这个人真是信守诺言。很多年前，那时候英文论坛是 boot-land.net，现在是 reboot.pro. 当时我请求他替 grub4dos 做推广。他答应了。没想到，这么多年他都坚持回答 grub4dos 的问题，从不间断，从不松懈，令人肃然起敬。

不点

mdyblog 发表于 2015-2-27 07:28
>>假如能够把这个问题做好，达到两全其美，那也是好事。
-------------------
我分析了下。 应该可以 ...

随便说说一点看法，供参考。

你可以自己打补丁，提交给 chenall。chenall 接到补丁后，可以先测试一段时间，如果放心，就会正式采纳。chenall 甚至也有可能为你单独开辟一个系列，就像以前为 yaya 单独开辟一个系列那样，进行长期的测试和评估。一旦成熟，大家自然会全面采用你的版本。

如果你自己不愿意做或者没时间做，可以等待别人去做。可以说服开发团队成员去按照你的思路完成任务。如果开发团队成员由于种种原因做不了，那你可以在团队之外寻求高手支持，完成开发任务。

不点

mdyblog 发表于 2015-2-28 15:38
着急：
UD上 geometry --lba1sector 的问题。
914#

貌似着急也没用。你的主板 bios 不允许按单扇区读盘，你又有了新发现。祝贺。同时你分享给大家，大家也都能增加这样的知识。

当你发现更多类似的现象时，你的视野也就更开阔了，理解力也就进一步加强了。世上大概没有不可能的东西，只有尚未被发现的东西。

顺便说，会不会仅仅是 0.4.6 的 bug 呢？你能否确认 0.4.5 也有这个问题？

如果 0.4.5 没问题，赶紧请 yaya 修复 bug。

不点

从 ud 启动后，直接进入 grldr，此时会混乱吗？

有多少个机器会出现混乱？

是不是由于你的部署方式太奇特了（这一点你自己最清楚），因而造成混乱？

0.4.5 有问题吗？（前面问过的，没有得到答复）

以上这几个问题，是想帮你定位问题的根源，不是让你回答的。你自己有测试环境，因此你可以找毛病。最好是死活都找不出原因，那样你就有更多的机会去折腾了，折腾的结果会让你的电脑技术得到大大加强。

不点

4：0.4.5 有问题吗？（前面问过的，没有得到答复）
----------------
我等会儿再补上。（干嘛要测这么多版本，挺烦的，难道不能就做好一个版本，并维护好.大家始终向都一个版本看齐。节省劳动，提高效率）

惹你烦了，实在抱歉。不过，我不代表开发者。我只是凭我的理解力来回复的。没有任何强迫的意思，这一点请了解。如果帮不到你，请忽略我说的话。至于说为什么维护多个版本，我的理解是，存在皆合理，它一定有理由，你不妨猜测一下它的理由是啥。我觉得你不难猜到。或者你也可以直接问问开发者，让开发者给你详细解释解释。

5：以上这几个问题，是想帮你定位问题的根源，不是让你回答的。你自己有测试环境，因此你可以找毛病。最好是死活都找不出原因，那样你就有更多的机会去折腾了，折腾的结果会让你的电脑技术得到大大加强。
-----------------------
我却相反。
我只是希望尽快解决问题。至于提高“电脑技术”，已经不再是我的关注了。（每个人有自己的关注点，否则一事无成）
如果有人能解决，我就不折腾了。

如果能够不折腾就把问题解决了，那是最理想的了。不过，事情往往不那么顺利。世上没有完美的东西，软件的 bug 会有很多。功能越多，产生 bug 的概率就越大。bug 就是人所犯的错误。错误是很难避免的。出现 bug，总得有人去折腾。有的 bug 能持续好几年才得到解决。

不点

1. 单扇区读盘的参数，是我设计的。它应该能够处理未经 map 的盘。至于说 map 之后，情况复杂，那涉及到修改 int13 handler，让其能够发现宿主母盘的单扇区读的特性，并采取单扇区读。这部分工作没有做，因为 int13 的代码空间已经达到 12K 的极限，没法再插入有关单扇区读的代码了。这就是说，在那些有问题的电脑上，用户只能凑合着使用 grub4dos，而不能获得全方位的支持。意思是说，在那些只能进行单扇区读盘的 bios 之下，用户使用不带 --mem 的 map 命令创建虚拟盘，则虚拟盘可能不是单扇区读的，这意味着，访问虚拟盘有可能造成死机。因此，在这种情况下，用户不可以使用不带 --mem 的 map 命令。很抱歉，这一点没有写在文档里面。不过，已经发现的 bug 机器很少，所以，一般情况下，可以忽略这个问题。chenall 设计了一个方法，用户在启动时快速按 S 键可以进入单扇区读模式。所以，第三方开发者和应用者们没必要关心单扇区读的问题了。用户在首次启动发生死机时，他会想到，需要调试。那么在调试选项里面，就有 S 键进入单扇区读盘模式。在启动之初一旦检测到用户按了 S 键，grub4dos 就自动设定启动盘为单扇区读盘模式。特别指出，当机器是从 ud 启动时，当前 root 分区是 ud，而此时执行 geometry --lba1sector ，将把 ud 的宿主盘设定为单扇区读盘模式。ud 盘和pd盘类似，都没有通常的扇区的概念。具有扇区概念的盘，那是 ud 的宿主盘，不是 ud 盘本身。ud 和 pd 都不是 bios 盘。

不点

2. fbinsttool 是否支持单扇区读盘参数设定。这个我不知道。我个人认为，通过 fbinsttool 设定单扇区读盘，固然会避免死机，但影响正常机器的启动速度。仅仅就这个话题而论，我认为采用我所开发的 multimbr，是目前最好的选择。multimbr 在第一阶段读取 grldr 的过程中，全部采用单扇区读盘。微软的 bios 启动代码也是单扇区读盘。与微软的做法保持一致，这样能够提高启动的成功率，能够尽量避免进入某个封杀陷阱。当grldr接管控制后，由用户负责设定单扇区读盘模式。当用户发现死机，那么下次启动时，就可以通过快速按 S 键来设定启动盘为单扇区读盘模式。所以，在 multimbr 的情形，开发者和应用者根本没必要管这个事了，这就简化了制作启动盘的逻辑，做到了既无参数设定，又能通吃所有的情况（当然了，新的 bios 攻击除外，人家掌握话语权，非要封杀，那没办法）。

不点

3. grub4dos 所提供的读盘函数，似乎都是 c 语言的。你只有直接调用汇编语言，才能实现你自己的单扇区读盘。

grub4dos 的 c 语言读盘，是采用缓冲区的。每次要读一个磁道。在 lba 的情形，每次读 127 个扇区。

所以，即使你只是要读一个扇区，grub4dos 实际上也要读 127 个扇区。只不过在单扇区读盘的情况，是分为 127 个 int13 调用，这当然很慢了。而在多扇区读盘的模式下，127 个扇区仅需一个 int13 调用，当然就很快了。

不点

2011yaya2007777 发表于 2015-2-28 18:25
请 chenall 看看，今天打了一个补丁，上传到我的分支，不知为何没有进入你的主干。

你这个帖子被后面的大量帖子淹没了。你最好开个新帖，提醒 chenall。

不点

mdyblog 发表于 2015-3-1 09:07
1： 原来是这个原因。也就是读一个扇区，实际读127个！慢了127倍。

2：能提供其它函数， 或在提供一 ...

2：能提供其它函数， 或在提供一个开关，就让他不要一次连着读127个扇区。

这一条，目前用已经公开的函数接口，好像是做不到。但我没有仔细研究，也许能做到，也未可知。你可以向开发者提要求，要求提供单扇区读盘函数。如果开发者觉得有必要，他会满足你的要求。如果他觉得没必要而拒绝，他会给你解释理由。

缓冲机制是 gnu grub 原有的机制，不是 grub4dos 特有的。原来的 gnu grub 就是按照磁道读盘的。只不过原来是按照 63 扇区作为 lba 模式的一个虚拟磁道，我改成了 127 扇区作为 lba 模式的虚拟磁道。

chenall 写了一个外部命令，就叫做 bios，它可以实现单扇区读盘。你只要懂得 int13 的调用规范，就可以使用 bios 这个命令。具体用法，你自己搜索。

不点

mdyblog 发表于 2015-3-1 10:40
1： 现在基本确定是ud引起的软件混乱导致死翘翘。

关闭ud就好了。

你的报告，大致上可以理解为，单扇区读盘模式有 bug，需要排解。至于说如何排解，我好像也帮不上什么忙，那就由你们来做了。

对于 grub4dos，随着时间的推移，我的记忆会越来越模糊。趁着现在还保留了一部分记忆，我尽量多来这里回答问题。

能答复多少，就是多少。答复不了的，那就没办法了，我尽力了，因此我也不会后悔。具体的排解 bug、写代码，都很伤身体，我也都做不了了。我只能出点小力，不能出大力了。

不点

你用 map --status 可以报告仿真的状态，因此可以比较一下，从而发现两种方法的不同之处。

我觉得，第一种写法就可以。第二种或许也行。

通常不需要第二种写法。第二种写法的应用场合大致是这样的：

当你需要把某个盘映射为一个虚拟盘，同时不想继承原盘的几何参数，而是希望虚拟盘具有不同的几何参数，此时就需要第二种写法，例如：

map --sectors-per-track=63 --heads=255 (fd0)+1 (hd0)

再例如：

map --sectors-per-track=63 --heads=255 (hd0)+1 (hd1)

如此创建的虚拟盘，具有 H=255，S=63 的几何参数。这就是说，虚拟盘的几何参数可以与原盘不同。

比较一下，如果像下面这样：

map (fd0) (hd0)
map (hd0) (hd1)

则虚拟盘继承了原盘的几何参数，这是整盘仿真，属于简单的直接映射。这种映射，直接由主板 bios 来确定几何参数。

而前面的改变几何参数的那种写法，则属于仿真范畴，就连几何参数也被虚拟化了。


【再补充】

如果执行 map (hd0) (hd0)，则意味着用户准备撤销 hd0 的仿真，也即，让 hd0 恢复为真实的、原来的 bios 盘。

如果执行 map --sectors-per-track=63 --heads=255 (hd0)+1 (hd0)，则会创建虚拟盘 (hd0)，它的扇区数据等价于原来的、真实的 BIOS 盘 (hd0)，但其几何参数则是虚拟的，即，不管原来的 (hd0) 是什么样的几何参数，新的虚拟 (hd0) 的几何参数将是固定的 H=255，S=63。