准备基于 fbinst 进行再开发，请各位提供帮助

不点

0010 是 S=16，但后面应该还有一个 H=????，你没看清楚。不可能不显示出 H 的值，就进入 GRLDR。

不点

这么说来，S=63，H=16。CHS 模式最大访问能力：63×16×1024=1032192 个扇区 = 516096 K，即大约 500M。就是说，用 CHS 模式启动一个小型的 PE 也是没问题的。但是要想用 CHS 模式加载一个 650M 的 ISO，那就不行了。好在这个电脑支持 LBA，所以，一切都没问题，CHS 模式的缺点就被掩盖了。

不点

编译环境是现成的，chenall 在 google code 上的 grub4dos 项目首页，就有一个 Windows 下的 colinux 环境，这个环境既可以编译 grub4dos、wee，也可以编译 fbinst。

考虑了好几天，软件的名字不容易确定，就叫做 “多重 MBR” 吧。今天也就可以正式发布源代码了。

源代码中，最难写的部分是 “如何把物理扇区序列号嵌入到 GRLDR 之中”。如果用 C 语言当然比较容易实现，但是，这里需要用 shell 来实现，所以，还是很费劲的，至今我没能找到比较高效的办法。目前这种实现是很 “低效” 的，在我的一台笔记本上，需要花费 15 分钟才能编译完，而其中 14 分钟是浪费在 “向 grldr 中嵌入扇区序列号” 上了。如果有谁能够针对这部分（即，“嵌入序列号”）用 shell 写出高效的代码，请帮忙。


2014 年 1 月 10 日更新：

今天成功地优化了 shell 代码，能够把编译时间控制在 3 分钟。同时，开始支持导入用户数据。用户数据文件必须取名为 userdata，长度不超过 14851×510=7574010 字节。把 userdata 放在源代码所在的文件夹下，然后运行 make 即可开始编译。

2014 年 1 月 14 日更新：修复了 GRLDR 的 bug，更新了 GRLDR 的代码。
2014 年 1 月 15 日更新：再次修复 GRLDR，更新 GRLDR 源代码。

不点

谢谢，请各位不要用 8M 的映像来测试了。因为 8M 的映像，其代码有毛病。

请选用 24M.img 或 24M_2.img 来测试。

不点

您好像是弄错了，24M 的不可能显示 ACED。

24M 在成功后会进入 GRLDR，如果想看屏幕显示，需要接连不断地按 P 键才行。

另外，提醒一下，虚拟机就用不着再测试了，因为虚拟机总是成功。

当然了，虚拟机测试是第一步，是给您自己 “壮胆” 的，以免自己不放心。

虚拟机测试之后，就可以把 U 盘插在真实机上测试了。

制作 U 盘时，最危险。危险就在于，弄错盘符，误把自己的本地硬盘给做掉了。

请再三核实，一定不要阴差阳错地写入到自己的本地硬盘。

不点

编译以后生成 24M 的映像文件，直接用来写入 U 盘的。而写 U 盘的工具自己搞定，不属于这个软件的管辖范围。

不点

mygamexxx，请同时给出启动时的调试输出信息。如果看不清，可长按 P 键保持暂停。

你的下载是否有错误？你是否完整下载了？解压是否正常？解压后的 24M.img 文件的长度是多大？你是如何把 24M.img 导入 U 盘的？是在什么操作系统下进行导入的？导入后又进入了什么系统？有没有可能是因为病毒写入 U 盘扇区导致 U 盘的数据被破坏？导入后，立即关机，然后开机，看看是否正常？

不点

2010qaqz111，开头的 8M 带扇区序列号，是 fbinst 的关键技术，用来突破 BIOS 的封杀的。主板 BIOS 用异常的 CHS 参数来破坏（开源软件的）启动过程。很难有更好的办法来对付，大概只有用 fbinst 的方法才有效。原来的 fbinst 我不再深入研究。新开发的系统不再叫做 fbinst，与 fbinst 不兼容。关键的技术大致相同，都是采用开头的 8M 带扇区序列号。区别在于，这次没有 UD 区了。用户可以把自己的 7M 数据嵌入开头的 8M 空间里面，当然了，那些扇区都是带有序列号的，用户需要自己设法使用这 7M 的数据。开发者（目前就是我）不负责处理这 7M 的数据。对比一下，在原来的 fbinst 中，开发者 Bean 为这 7M 建立了 ud 格式的文件系统，使得用户可以在进入 grub4dos 以后访问这个 ud 系统。现在，我不开发类似的文件系统，用户自己如果想要用这 7M 空间，那就得自己设法使用这个空间。用户可以不用这 7M 空间，只用可见区的 FAT32 空间。新的系统不仅没有了 UD 文件系统，也没有了隐藏区。只有可见区的 FAT32 系统。

如果你看完了前面的帖子，你就会了解，这次整个 U 盘的结构，完全归我（即开发者）管辖，每次都是提供一个 IMG 映像，供用户写入 U 盘，根据使用说明，用户只有有限的操作权，比如说，普通用户大约只能把自己的文件拖入到 U 盘的 FAT32 文件系统里面，不可以随便更动 U 盘的其他扇区结构。熟悉内部结构的用户可以把自己的 7M 用户数据嵌入到 8M 以内的区域并自己安排它的用途（如上所述）。

不点

GRLDR 的 bug 已修复，请 mygamexxx 重新下载测试。

不点

2010qaqz111，你可能已经看出来了，我的新系统的开发理念与 Bean 的 fbinst 有差别。

1、新系统不处理 8M 以内的剩余 7M 空间，让用户自己来安排（或取舍）。fbinst 则建立 ud 系统，方便用户访问。

2、新系统不提供专门的工具，不提供各种安装参数的变化，只用一个映像文件来做。而 Bean 的 fbinst 提供了很多安装选项，方便用户选择和安装。

3、一旦发现有 BIOS 不适应问题，我的新系统的格式可能随时变动，这方面有着灵活性（这是对开发者来说的，开发者有完全的自由，可以随时变动 U 盘的格式）。外部工具的制作者可能也得随时跟进，调整自己的工具软件，以适应这些变化。相比之下，fbinst 要稳定得多，外部程序的作者不用修改自己的工具软件。

4、外部工具软件的制作者，可以研究这个 U 盘的设计，制作出自己的操作工具，方便最终用户使用。相比之下，fbinst 自带了工具，因此，fbinst 离开外部工具也能自成一体。

我为什么这样做呢？是因为哲学理念的不同造成的。

其一，是因为我个人身体状况不是很好，我想尽量少做点工作，同时又保证把软件的核心功能做到满意。

其二，是因为我个人比较懒，不想做太多的工作。

其三，是因为我个人在建立或处理（新的）文件系统方面缺乏必要的知识，也缺乏耐心，因此，我想省事，给自己 “减负”（减轻负担）。

其四，我想让工具软件的制作者们有事可做。如果我把所有的工作都做完了，那么别人的参与就少了。事实上我不可能做所有的工作，因为我不熟悉 Windows 编程，我只能寄希望于由其他作者们来完成这部分工作。如果其他作者们参与进来的多了，那么这个软件的后续开发就更有保障了。就是说，我开个头，而后续的开发工作将不存在困难，很多人都能参与进来，没有门槛（或者门槛很低）。诸位看看我的代码，核心代码简单透顶，第一阶段是 MBR，一个扇区，第二阶段也是一个扇区。总共只有两个扇区的 assembly 代码，随便一个开发者，花费半天时间，都可以研究完。工具软件的制作者就有可能会成为将来接替开发的开发者了（前提条件当然是说 BIOS 继续存在；如果 BIOS 消失了，当然就不用提了，因为不会再有人关心这个软件了）。

第一阶段的 MBR 引导记录代码，复制到最开头的 190 个扇区上。这 190 个扇区的每个扇区都带有 BPB 和分区表。

所以，工具软件的作者，应该研究分区表的变化规律，从而能够添加正确的分区表项。

第一个分区表项已经是 FAT32 了。还剩下 3 个表项可以由工具软件的作者来处理。

开头的 190 个扇区中的每个扇区，都应该有分区表项。每个表项含有 16 个字节。

除了第一个已经被 FAT32 占据的表项以外，新创建的表项，其前 8 个字节和表示分区长度的后 4 个字节应该是（在这 190 个扇区里面）保持不动的，而表示分区起始扇区号的 4 个字节在这 190 个扇区里面都是递降的。看到这个规律，那么，外部工具软件的作者要想写分区表已经不困难了。

由于 FAT32 分区故意设置为 8G 左右，超出了 CHS 的访问能力，所以，新创建的表项，其 CHS 值可以都搞成固定值：柱面号 C=1023，磁头号 H=254，扇区号 S=63。这样就简单了，新创建的表项，其前 8 个字节就是 00 FE FF FF XX FE FF FF，此处，XX 可以是 0C 表示 FAT32 分区，或者 07 表示 NTFS，或者是 0F 表示扩展分区，这些大家都懂的。精于计算的工具软件的作者，一定不难把这搞定。

---

在作出以上解释之后，我想，诸位可能也就看出来了：现在我可以 “撒手不管” 了。剩下的事，大都是用户自己的事，或者是工具软件开发者的事了。

已经制作好的这个 U 盘，估计差不多应该可以 “通吃” 了。即使不能通吃，由于内置了调试输出，所以，其失败根源很容易定位，再也不会出现 “模棱两可”、“说不清楚” 的情况了。与原来的 fbinst 相比，这也算是一个重大的改进。

---

还需要补充说明的一点是，内置的这个 grldr 版本，已经屏蔽掉了 PXE。这是因为，从 U 盘启动时，一定不是从 PXE 启动，所以，这个内置的 grldr 版本就把 PXE 功能屏蔽掉了。另外，前面还提到，默认时执行单扇区访问。用户可以通过执行一次 geometry --lba127sector 命令来切换到高速的多扇区访问。

不点

mygamexxx 发表于 2014-1-15 08:14
新版全乱了：
hd1.0不见了，
hd1,4变成了hd1,1

谢谢您的辛苦测试和报告。又更新了，好事多磨，这次应该 “健壮” 了吧？

不点

anxi_dongri 发表于 2014-1-15 11:06
变成网上坑爹的扩容盘了，数据拷贝多了肯定丢失喽

是有点不那么自然。不过，自己小心，应该没什么大事的。顶多是拷贝进去的文件丢失了，或者拷贝失败。应该不会有别的危害。

如果想保证文件系统的完整性，那你可以只在 16G 以上的 U 盘上使用。

大家各自根据自己的爱好、根据自己的判断、根据自己的理解，来自由地使用吧。



补充一句吧，fbinst 以及这里的新系统，都是 “变态” 的启动工具。使用这些工具的人，也多多少少都有些 “变态” 的成分，不属于 “常态”。跟诸位开个玩笑，大家都很变态（包括我在内）。

不点

在第 10 页（100 楼），公布了 24M 映像文件的结构。简述如下：

扇区 0 - 扇区 189，共 190 个扇区，填充的是第一阶段的扇区。外部工具可以为每个扇区增加分区表项，别的就不要动了。

扇区 190，共 1 个扇区，是第二阶段的扇区（stage2）。这个扇区就不要动它了。当然，如果想改进它的话，那可以修改它的程序代码。

扇区 191 - 扇区 1341，共 1151 个扇区，是第三阶段的扇区（grldr）。这也不需要改动。

扇区 1342 - 扇区 16192，共 14851 个扇区（大约 7M），是空白扇区，但每个扇区都带有物理序列号。我觉得也不需要动它。

扇区 16193 - 扇区 48480，共 32288 个扇区（大约 16M），是 FAT32 的分区结构数据。目前是固定的，用户不可以随意修改。其开头的 31 个扇区（0x1F 个扇区）是保留扇区数，紧接着是两份 FAT 表，每一份占用 0x3F00 个扇区，两份共占用 0x7E00 个扇区。最后剩下一个扇区，就是 FAT32 根目录的数据。31 + 0x7E00 + 1 = 32288。目前来说，这些也都不能动。

看到没有？在理想的情况下，根本不需要改动什么。开头的 190 个扇区，一旦添加了用户的分区表项，那也就是固定的了，以后也就不会轻易改动了。如果 grldr 有更新，那只需要把新的 grldr 嵌入进去就行了。grldr 的位置是固定的，外部程序可以轻松搞定。甚至手动也能搞定（自己编译 mbr_24M.img，然后按照 grldr 的位置，取出 grldr 部分共 1151 个扇区，再导入到 U 盘对应的位置便可）。其他都应该保持不动。

用户自己在 FAT32 之下建立的文件，当然可以在资源管理器里面随便增删，这不会有什么不良影响的。

不点

2010qaqz111 发表于 2014-1-15 18:13
区 1342 - 扇区 16192，共 14851 个扇区（大约 7M），是空白扇区，但每个扇区都带有物理序列号。我觉得也 ...

是的。它是 userdata 的区域。如果你把自己的文件 userdata 放在源代码之下，运行 make 来编译，那么，userdata 会被添加上扇区序列号，并被放在 mbr_24M.img 的合适位置。

不点

mygamexxx 发表于 2014-1-15 18:17
其他分区正常了，就是不见hd1,0
ls (hd1,0)/
返回无此分区

需要用 cat --hex (hd1)+1 看看分区表是否正常。

不点

找到毛病了。脑子开始钝化了，把 & 写成了 &&，造成低级错误。看来我真的该退出电脑软件的开发了。

这次应该没问题了。

不点

是不是菜单有隐蔽的错误？

命令行执行 font，有什么错误显示吗？

不点

请 liuhu6682 说说失败的现象，屏幕有没有信息显示？换用其他启动软件能否成功？能够成功启动的软件的名称以及版本是什么？

成功启动时，请截取 U 盘开头的 8M，压缩以后上载，供研究。

不点

linhu6682，感谢你辛苦截取 U 盘扇区。但是，你截获的扇区是从第一分区开始的，不是从 MBR 开始的。请你再截获一次，这次记住是要截取含有分区表的 MBR 扇区，从 MBR 扇区开始，截取 256 个扇区就够了。如果不懂，请用 BOOTICE 截获扇区的功能。注意：千万别毁掉你的硬盘！我们能否成功启动，不要紧；你的硬盘数据，是最要紧的。

不点

zbkh，抱歉，不能全部答复你的问题。请用 Google 或 百度搜索相关内容。

你的第1条，我认为你的理解基本是正确的。

第2条，既可以说是标准，又可以说不是标准。Win98 时代的硬盘通常都是这样，微软都是喜欢把 MBR 空间保留为 63 个扇区，第一分区起始于扇区号 63。但 U 盘很复杂，没有规范。即使以前有规范，也可能被破坏（甚至有可能故意破坏）。

第3条，不一定。BIOS 很混乱，不会按照某个固定模式去运行。如果 BIOS 很有规律，那么就不需要这里的 fbinst 以及新的发展了。

请自己搜索其他有关的资料。

不点

linhu6682 发表于 2014-1-17 23:13
按大师的指点重新截取 U 盘扇区，不知道这次有没有错。

干得不错。你再确认一下，这次的 256个扇区，与先前的 8M 是不是紧连着的。

我会研究的，并且可能会提供若干个映像让你测试。你先休息吧。

不点

给 linhu6682 做测试的一系列测试版可能都要放在这楼了。

其他人根据自己的兴趣，也可选择测试。


更新：

系列测试1 是 24M 的大小，按照以前的方法写入 U 盘进行测试。

alter_mbr_512_byte 里面是三个 512 字节的单扇区 mbr 文件。在 “系列测试1” 写入 U 盘测试完成之后，马上就可以写入某个单扇区文件，进行测试。就是说，只有开头的一个扇区与 “系列测试1” 不同，后续的扇区保持不动。这样，连同 “系列测试1” 在内，总共就是四个测试了。

不点

显示 0000，表示 U 盘被认成软盘，显示 3F60，表示最开头的扇区从 BIOS 那里成功接管了控制。

接下来是故意暂停 3 秒，防止一闪而过，目的是让用户看清显示信息，确认我们的代码成功获得了控制权。

暂停 3 秒之后，要尝试读 MBR，结果发现，MBR 刚好也是最开头的扇区，即序列号为 3F60，这表示 BIOS 没有隐藏磁道。然后探测 LBA 支持，发现 BIOS 支持 LBA，于是打印出 AA55。

既然很顺利，那么接下来就读内置的 grldr，并启动 grldr。

进入 grub 环境以后，不该有 FAT 警告信息。可能有什么地方不正常。

其他的朋友就不必再贴这些成功的情况了。只有当失败时，才需要详细描述失败的现象。

不点

感谢 liuhu6682 提供这些信息。我认为不是你的错。既然设置为 AUTO 模式，UltraISO 的 U+ 能够顺利启动，那么，如果我们的软件不能启动，那还是不太正常的。我们应该努力让它 “正常”（如果可能的话；如果发现不可能，那就放弃）。所以，我们的测试工作应该继续做下去。大凡干任何事情，我们要么认真做好每一个细节，要么完全放弃。

所以，我想请你确认，在 AUTO 模式时， U+ 是否能够成功启动？如果能，那我们还得继续研究和测试。

1月18日的映像，修改了 BPB 的一些域，想让 U 盘被你这个 AUTO 模式识别为硬盘，结果无效。而 Windows 肯定无法识别这个 U 盘，因为 Windows 发现 BPB 的信息有异常。Windows 很娇气，它的识别能力很差。不要在乎它。

请问对于 U+ （USB-HDD+）格式的 U 盘，Windows 能识别出它的文件系统吗？这个问题也很重要，请告知。

不点

sunsea, 这个软件的主旋律是 “启动成功率”。功能是次要的。我们缺乏的，正是启动成功率。功能方面，并不缺乏。即使功能有缺乏，也容易实现、容易填补。可以做好功能设计的人，有一大堆。而能做好启动成功率的，则十分罕见。

一个软件，如果不能在硬件上顺利运行，那么它的功能再强大、再完善，都形同虚设了。一个软件只要它被攻击，并且被强力攻击，直至被封死，那么它就成为没有实际意义的软件。花费力气，就要有用才是值得的。应该把有限的力气用在 “刀刃上”，不要浪费宝贵的精力。

grub4dos 就是这样一个软件。只要微软以及它所连带的利益集团存在下去并有着持续的控制力，那么像 grub4dos、Linux 之类的开源系统，就永远不会顺利运行。不仅开源软件不能顺利运行，闭源软件也同样不能顺利运行。只要你的闭源软件对微软不利，你的软件也注定是死路一条。

所以，目前我对 grub4dos、Linux、fbinst 等等这些东西，已经失去热情。我在观望，我在等待。我也在分析和判断。我期待着有一天，微软集团遇到强劲对手，让这个世界能够暂时走出垄断控制的阴影。

我甚至在想另外一个更大的问题。我发现微软、谷歌、苹果、小米、魅族……（此处省略一百万个公司），等等等等，所有这些公司，几乎无一例外地，都想搞垄断控制。这很可能是本质的，而无法避免。我们生活在这样一个混乱的时代，是很无奈的，恰如生活在一个战乱的时代也是很悲哀的一样。

时代会不会进步？进步到不再进行无谓的消耗？进步到大家都在生产财富而杜绝（或减少）破坏财富？这个梦想看来距离我们还十分遥远。

不点

外置失去成功率，没有意义。

可见区位于 24M 以后，这个区域的 grldr 有可能无法被 BIOS 访问到。

开头的 8M 空间是处于 “有利地势”，而 grldr 就位于这 8M 的前端，在 1M 以内，甚至也在 720K 以内。这样，在最坏的情况，BIOS 只有 720K 的访问能力，此时也能成功启动 grldr。最起码用户不至于抱怨 grldr 死机了，说 grldr 这个软件是垃圾。恶意 BIOS 攻击者所要达到的目的（之一），就是让人们痛恨开源软件，让人们认为开源软件是垃圾。

你可以把你的菜单外置，取名为 menu.lst，放在可见区 FAT32 的根目录，这样就会被内置菜单调用。

不点

mygamexxx，正如楼上 jack95 所说，是你自己的失误，你的 menu.lst 没有带字库。

在 grub4dos 发布的软件包中，就有一个示例用的 menu.lst 文件，你为何不试试这个文件呢？示例文件尾部的字库前面还专门添加了注释。

不点

mygamexxx 发表于 2014-1-21 06:38
grldr6自身已经内嵌中文字体，menu.lst还要重新加载字体吗
？

grldr 已经超过 200K，字体文件达 3M 多，压缩以后也有 1M，怎么可能全部嵌入到 GRLDR 中呢？

不点

mygamexxx, 要么你导出的字体文件有错误，比如说，格式不正确，或者有别的什么错误。

请你试试加载一个完整字库文件。在 chenall 的 google code 主站下载。

不点

sunsea，你不用管 userdata。目前你只需把 24M 写入你的 U 盘便可，别的不用管。16G 的 U 盘，也只有开头的 8G 有用。目前没有添加分区表项，无法利用后面的扇区。

这个软件的启动成功率还很成问题。所以，你那些更高级问题以及要求，都没有必要去实现。将来这个 U 盘的格式会变成什么样，还很难说。

为了适应各种变态的 BIOS，这个 U 盘的格式可能搞得面目全非。

现在先不要预测这个 U 盘一定是 FAT32 的格式，也不要假定将来一定可以让用户自己设定分区表。

先扔这儿吧，有时间了，慢慢做。