支持含有碎片的文件仿真

不点

map --in-situ 参数的意思是仅仅虚拟分区表，不虚拟数据扇区。所以，如果没有分区表，那就不能进行虚拟。

另外 --in-situ 参数是为 win98 设计的，现在估计一般都用不上了。因此，长期以来也没有改进相关的代码，比如说，拒绝对软盘的分区表进行操作，因为在早期我们认为，软盘不可能有分区表。

yaya 如果有时间的话，可以尝试修改一下，看看假如允许 --in-situ 对软盘进行操作，会不会出问题？

不点

没有激活分区的分区表，也是合法分区表。不应该判定为非法分区表。

不点

grub4dos 的 C 语言源代码有一个函数 probe_mbr() ，经过了长期的改造，现在应该十分稳定。它能够严格地检查分区表的合法性。随机的乱数据很难通过检查。同时，它又能适应所有的分区软件所建立的分区表（至少目前没有见到失败报告）。诚如 mdyblog 所说，有没有激活项，不能成为判断软盘或硬盘的标准。分区表是否合法，才应该成为判断的标准。

不点

您的代码等价于如下的简化代码：

map  (%boot%)0x4100+0x400000  (fd0)
map  (fd0)   (fd1)
map --hook

您可以先核实一下这个简化代码是否能够工作？

不点

那就让 yaya 解决 78 楼的问题吧。应该是个 bug 了。

不点

在启动 grub 主体程序之前，先检查是否有 grub4dos 先前所建立的 int13 存在，如果有，就将 int13 的数据结构部分记录下来，让新的 grub 环境明白，int13 是已经 hook 过了，并且所有的 map 也都予以承认。

int13 的数据结构位于 int13 代码段的偏移 0至偏移 13f 处，长度是 0x140。

不点

如果 int13 是 hook 过了的，那么 413h 处应该记录了以 kB为单位的用户可用内存量。这个界限之下的内存，可以被用户使用。这个界限处的 12KB内存，就是 int13的数据结构以及代码空间。从 0x4c 开始的 4 个字节，就是 int13 处理程序的入口地址，其中前两个字节是偏移地址，为 0x100，后两个字节位于 0x4e，当然它就是 int13处理程序的代码段的地址了。413处的值必须与4e处的值相匹配，并且int13处理程序的特征都正确，才认为这确实是grub4dos所建立的 int13 数据结构。

不点

at&t 的汇编语言格式很容易让人出错，intel 格式更容易理解。intel 用中括号表示地址，用不带中括号的数值表示立即数，这不容易让人误会。而 AT&T格式用$表示立即数，用不带 $ 的数值表示地址，这是很不自然的，很容易误导人的直觉。

不点

blocklist 是 grub4dos 内部命令，不是外部命令。直接执行命令便可。

不点

又发现这个最容易犯的错误 “find --set-root”，这会在一大批机器上导致死机，原因说过多次，不再重复。

任何有可能访问软盘、光盘的命令，都可能导致死机。find 命令只是其中之一。

为保证不死机，必须为 find 命令增加防死机参数 --ignore-floppies 和 --ignore-cd，就是说，让 find 命令只在硬盘里面查找，这就安全了。

不点

xianglang，在你说的情况，你完全可以用当前盘 () 来做。

grldr 启动时，当前盘是可以访问的，不管它是不是软盘。如果 grldr 是从软盘启动的，此时软盘当然是可以访问的。

就是说，启动时，你可以不用 find 命令，直接使用当前盘来定位文件，如果失败（即，不存在该文件），再用 find 来搜索各个硬盘的各个分区。如此一来，总是可以避免发生死机的。

不点

2011yaya2007777 发表于 2014-6-6 06:40
以前 fsys_ntfs.c 占用内存 3e0000-3e5fff；现在占用 3e0000-3ebfff。
死机的原因应当是加载 G4D 之后，加 ...

小心点，有可能是你多占用的内存所导致的内存冲突。grub4dos 的内存占用比较乱，没有仔细归纳总结，很容易自己就产生冲突。

不点

xianglang 已经报告得很清楚了：

Warning! Invalid first FAT entry(=0x7FFFFFF0) !

这个 FAT 分区的首个 FAT 表项是 0x7FFFFFF0，这是非标准的，就是说，微软公开的 FAT 标准里面没有这个。

这个早就发现了。我认为是微软或某个厂家故意制造的不兼容，目的是破坏 GNU GRUB 的运作。这个问题在 GRUB legacy 时代就出现了。我怀疑是 Windows 或者某个恶意程序修改 FAT 表首项造成的。

在我修补的 FAT 代码中，已经 work around 了该问题，所以不会出现识别不了 FAT 分区的问题。yaya 后来编写的 FAT 代码，可能没有考虑这个问题，所以就暴露出问题了。

不点

ud 的文件系统格式是 fb，从 ud 启动后，fb 文件系统的驱动程序把这个宿主盘也当做 fb 文件系统格式来处理了。这是因为，宿主盘的开头符合 fb 文件系统的格式。

其实也可以修改 fb 文件系统的驱动程序，让其不要驱动宿主盘。不过，究竟这样做有什么好处，还很难说。

不点

sratlf 发表于 2014-6-18 17:57
还有个问题  如果ud=hd0的情况下  磁盘交换会有什么影响  比如

map (hd0) (hd1)

你是不是写错了？

应该是 map (hd1)  (hd0) 吧？你写成了 (fd0)，通常不会这么映射的。

ud 不受交换盘符的影响。任何 map 命令都不影响 ud 区的使用。

hd0 与 hd1 交换并 hook 之后，hd1 当然就变成了 新的 hd0，它当然不会是 ud 的宿主盘。真正的宿主盘是旧的 hd0，也就是新的 hd1。

不点

ud 区不受 map 影响，但宿主盘经过映射后能否被 fb 驱动程序识别为 fb 文件系统格式，我还不知道。

也可以考虑修改驱动程序，让宿主盘永远不被识别为 fb 文件系统格式。

具体应该怎样，我没有仔细研究过，由开发者来权衡吧。

不点

很难修的，光驱处于淘汰的地位，不值得去费劲了。一开始就有报告说，光驱位于 IDE slave 就无法访问，只有 master 可以访问。算了吧，不要纠结了。

光驱驱动有可能在今后某个时候被阉割掉。

不点

有关 svn 项目管理之类的，一概不懂，帮不上。我估计 Bean 和 Roy 可能比较熟悉这方面的知识。

不点

2011yaya2007777 发表于 2014-7-3 16:56
在 dev@grub4dos_dev:/mnt/cofs/yaya-0.4.6a$  目录，使用 make 可以正常编译，有 .diff 文件
在 dev@grub ...

我也发现这里有个问题。用 git 下载的内容，编译后不出现 diff 文件，它不使用本地改动了的文件（例如 stage2.c），而是使用未经改动的文件。

我只好换用 svn 才解决这个问题。chenall 似乎应该修正一下 build 脚本。

不点

chenall 发表于 2014-7-3 20:20
嗯,之前的build脚本主要考虑了SVN的情况,,所以使用git时会出现这种情况.

回头我尝试修改一下build脚本.
...

我实在不想学新知识了，即便很简单，我也不想学了。大概是因为身体情况不好吧，也可能是因为脑子也变得迟钝了。

svn 的知识是从 bean 的帖子里学会的，我自己从来都没有专门去学 svn。所以直到现在，我对 svn 都很陌生。git 更是陌生，我估计很多人对 git 都比较陌生。你最好像 bean 那样多花费一些笔墨来介绍 git 的使用，让大家熟悉基本的、常用的功能。

是的，我觉得 yaya 应该学会，这样就不至于在论坛上堆积了 n 多的补丁，都让 chenall 一次性打上。

不点

chenall 发表于 2014-6-25 11:21
汗,忘记贴链接了.
http://grub4dos.chenall.net/grub4dos_dev_2014-06-25.7z
看里面的 使用说明(readme). ...

@chenall,

你的这个 grub4dos_dev 已经无法下载了。是删除了？还是挪动到别处了？从你的 Blog 上也找不到下载它的链接了。

不点

chenall 发表于 2014-7-25 13:00
移了一个位置,前面加上dl就行了.
http://dl.grub4dos.chenall.net/grub4dos_dev_2014-06-25.7z

知道这个位置了。谢谢。也谢谢 zxw。

但是，假如我忘了这个位置，又有什么办法可以找到呢？

我在百度里面搜 grub4dos_dev ，累死了也找不到。在你的 blog 的搜索框里面搜，也搜不到。在 download 里面也找不到。

假如时间久了，我找不到现在这个帖子了，那就更是找不到了。于是只能麻烦你，而且，你不一定正好在线，这时间就耽误了。

这个帖子里面有很多东西，是不是可以整理一下，写一篇博文，方便大家学习，方便下载软件呢？

不点

估计是你搞错了，造成莫名其妙的错觉。

你可以看看 asm.S 开头的那些变量，尤其是 install_partition 和 boot_drive 变量。

传入的 DL 的值会被 0000:8200 处的代码自动存入到 boot_drive 变量中。

但 DH 值不会被自动存入 install_partition 的位 16 - 位 24 的字节上，你必须在传递控制之前修改好，即，你需要自己把 DH 的值存入 install_partition 的位 16 - 位 24 的字节上，然后再把控制转移到 0000:8200 处的代码。

同时，如果 0000:7C00 处含有合法的 BPB 引导扇区，则 grub4dos 有可能会利用这个 BPB 表来确定启动盘的信息。

就是说，在传递控制之前，如果能保证 0000:7C00 处含有某个主分区的引导扇区（或者碰巧是这样），则这个主分区就可能被 grub4dos 当作 boot 设备（以及当前 root 设备）。

不点

另外，我看到你的代码中有：

movb    $0, %dh

这个已经改变了 DH 的值，不知你注意了没有。

传递 DH=FFh，这个分区号是整个硬盘。你只有将 DH 传递给 GRLDR 时，才会自动修改 install_partition 的值。这个修改的动作是由 GRLDR 的第二扇区代码完成的。由于你越过 16 扇区，所以，没能成功修改，因此默认的分区号就是 FFh，它代表整个硬盘。这应该是一种错误，导致默认分区号不正确，无法找到菜单。

另外，你说连盘号也弄错了，竟然成为 (fd0) 了。我怀疑，你确实是从软盘启动的，你的 0000:7C00  处含有主分区的 BPB 引导扇区。grub4dos 可能就是依据这个来判断启动设备，并把它作为 “根设备” 的。

不点

是的，整体加载 grldr 是最省心的，免得自己还要处理很多细节。有人说，细节决定成败。细节也是令人头疼的事，不容易处理妥当。

当你整体加载 grldr 时，你需要传递给 grldr 的 CPU 寄存器是 DL= BIOS 盘号，DH=分区号码（0xFF 代表没有分区表的整个磁盘）。

你最好同时把启动分区的引导扇区（它含有 BPB 表）也放在 0000:7C00 处。这个分区应该是主分区。如果引导扇区是某个逻辑分区的，那就不要放了，因为逻辑分区不起作用。软盘的引导扇区也是可以放在 0000:7C00 处的。

不点

你这属于 “开拓、尝试、创新”。这期间会出现很多意想不到的问题。有的是自己的编程失误造成的，有的是对于某个知识的理解有错误或有偏差造成的，有的则是某个相关软件的 bug 造成的。

我不知道你的程序是如何接管控制的。你是不是打算写一个启动软件？

如果是的话，我建议你不要这么做。这不是打击你。是根据我的理解、依照我的判断，给你提出的建议。

其一，启动软件已经有很多了，而且都不错，它们多年来解决了很多问题，能够顺利运行。如果你再制作一个，则有重复发明轮子之嫌，劳动的成效不大。你的软件要想成熟，也得经历那些痛苦的过程。要知道，大量的情况都是 BIOS 厂家故意制造的问题，如果你的软件有问题，不能适应这乱七八糟的 BIOS，那么大多数用户可能根本就不向你报告，而是直接放弃你的软件。这个过程十分艰难，排错十分痛苦。

其二，BIOS 正遭遇封杀和淘汰。虽然未来有变数，但至少封杀是明显的，如果不是傻子，都能感觉到。在这样的情况下，编写 BIOS 启动软件，我觉得是不太划算的。你出了力，得到的成效怎么样？怕是不太满意的。

其三，即使你编写的软件很有成效，很火爆，那样也不妙。为什么呢？因为那时你就面临着直接的封杀了。grub4dos 本来就不算是一个软件，也没打算从 gnu grub 分离出来。但在很早的时候，就遇到了封杀，我很吃惊，也很好奇。假如没人封杀的话，说不定我会半途而废，早早地就转移兴趣到别处了，而不会坚持这么多年。

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

如果我说了这么多，你还是决定要继续前行，那我恭喜你。你一定是有准备的，你一定是偏向虎山行的那种人。其实，我也差不多算是这样的人。

你大概想填补目前的空缺，制作一个能够适应 BIOS 和 EFI 两种环境的启动软件。不过一定要有失败的准备，因为任何事情都有可能失败。还要矢志不渝长期坚持开发，不能断断续续的。另外还需要机敏，能够敏锐地察觉到软件运行的状况，了解是否已经被攻击了，如何化解攻击。开发启动软件在技术上不难，难的是应对那些无穷无尽的非技术问题。

不点

看到你在 MBROS 那个帖子 28 楼的 “原理知识普及”，满怀希望能看到真正的讲解，却只得到了几行含糊不清的（也许用个褒义词就是 “高度概括的”）条条。我得承认，我不可能把那个帖子序列里面的所有帖子都看完（身体条件不允许）。你也没有义务为我一个人解释详细的原理。但假如你愿意的话，你可以给我解释一下。我想知道下面两个问题：

1、MBRos 是否开源？
2、MBRos 比别的软件有哪些改进，不要笼统地说，要具体说。别的软件遇到什么问题？而 MBRos 又是如何突破和克服的？讲一下技术实现方面的东西，讲要点和巧妙之处，让别人一看就领会了的。不需要很多字，大概 200 字左右就可以说清楚。

如果由于某种原因你不便于答复或解释，那你就不要勉强自己了。我无意强求别人回答那些人家本来不想回答的问题。尤其是，假如（仅仅是假如）你有秘密不想透露太多的话，那就算了，我不强人所难。我不需要那些反复的、笼统的解释，而又不能让我领会其技术要点和技术突破。就是说，假如看完解释之后，仍然是一头雾水，仍然感到有某种神秘，莫名其妙，难以理解，那么我也不想看这样的解释。


补充说明两点，算是澄清，目的是尽量不至于让人误解：

1、我想知道一个技术是否开源，也就是确定我能否深入研究这项技术。不开源的技术也有很多，比如我很喜欢的 BOOTICE 就不是开源的。另一方面，也存在这样一些开源的技术：我既不用它，也不喜欢它。所以，我对于开源与否，都没有成见。开源也有糟糕的技术，而闭源也有优秀的技术。糟糕与优秀，不同的人有不同的评判。像 BOOTICE 这样的软件，我只需要用起来顺手就可以了。因此，我并不需要它是开源的。即使是开源的，我也不去看它的源代码，因为我已经大致清楚了它的工作原理，没必要看源代码。换句话说，我只需要使用 BOOTICE，而不需要深入研究 BOOTICE，也不需要去改造 BOOTICE。然而对于启动软件，那就不同了。我可能比较关心，因而有可能需要深入研究。这就需要知道这个启动软件是否开源了。因为如果不开源的话，我可能就没法深入研究了。好了，这就解释了我为何想知道 “mbros 是否开源” 的问题。

2、我想知道 mbros 在技术上都有哪些改进，是想 “打破沙锅问到底”，我想深入了解这项技术，不留下任何含糊不清的疑点，这是我的目的。如果你能够满足我的要求，那你就可以回答我的问题。如果由于某种原因不能满足我这样的好奇心，那就建议干脆不要回答我的问题了。如果你回答了我的一部分问题，我可能还要继续追问其他问题，一直问到我自己觉得没有什么可问的程度为止。如果你没有时间答复我的问题，或者没有兴趣答复我的问题，或者仅仅就是不想答复我的问题，那你最好一开始就不要答复了。大家都很忙，都有自己的事情在做，因此，这样也就可以避免浪费双方的时间了。

不点

运行一个程序文件或脚本批处理文件，其方法都是一样的，可以采用以下两种方法之一：

1、用 “ command 【文件名】”
2、省略 command 关键字，直接用 “文件名” 来运行。

内存文件也是一个文件。因此你可以直接运行它：

(md)0x200+1

或者

command  (md)0x200+1

不点

很抱歉，批处理功能是 chenall 开发的，我只是猜测应该这样运行。

我真的没有研究过它启动的细节。

不过我仍旧可以猜测一下出错的原因。可能是文件长度不精确造成的。

如果你的硬盘上的某个批处理文件能够正常运行（举例来说，假定它的长度是 137 字节，不足一个扇区），那么，当你把它放在内存扇区 (md)0x200+1 中的时候，它只占用扇区开头的 137 字节，而后续字节是没有占用的。

而 (md)0x200+1 表示的是整个扇区，它的大小是 512 字节。

所以，应该限定文件的字节数为 137，这样才准确表示该文件。怎么来表示它呢？这样：

(md)0x200+1,137

就是，在原来的表达式后面接着一个逗号，再接着文件的字节数。中间不要插入空格，因为它们合在一起才成为一个文件名。

不点

mdyblog 发表于 2014-8-22 18:05
你是说这些变量（尤其红色）需要初始化，是吗？0000:8208  我必须先写入实际DH值。

有正确DL，故 可 ...

建议你不要切掉开头 16 扇区，不要把事情复杂化。恕我直言，我看不到复杂化以后有什么好处。