支持含有碎片的文件仿真

不点

修复的是 bootlace 里面的 bug，不是增强了 GPT 安装功能。

有人报告 0.4.6 的 bootlace 无法在 Linux 下正常运行，所以，yaya 就来解决这个 bug。

至于说 GPT，我猜本次并未涉及。

不点

英文论坛也报告了 9月5日 的 bug。我猜可能是某个地方的疏忽引起的。

改动太大了，难免有错漏之处。大家可以详细报告一下，让 chenall 知道问题在哪里，然后大家等待 chenall 修复。

不点

2011niumao 发表于 2014-9-8 12:17
google被墙上不去。9月2日以后的版本下载不到。
请问什么时候一楼可以再更新一下，更新到9月4日5日的？

下载地址是这里：

http://grub4dos.chenall.net/

收藏这个地址吧。

不点

bootlace 是 DOS 格式，我听说 64 位的 Windows 不再支持 16 位的 DOS 程序了。

因此，yaya 所提到的办法，应该是行不通的。

即使在 32 位的 XP 时代，bootlace 也不支持直接读写物理硬盘。这是因为 XP 已经禁止了 16 位 DOS 程序访问物理硬盘扇区的能力。只能通过一个文件来使用 bootlace。

首先用 dd for windows 把物理硬盘开头的 64 个扇区截获，放在一个文件中，比如文件名叫做 MBRfile。
第二步，运行 bootlace MBRfile 就把引导代码安装到 MBRfile 上了。
最后再用 dd for windows 把 MBRfile 写回到硬盘上。

yaya 所提到的用法，只适用于纯 DOS 或者 Win98 的 DOS 窗口，不能用于 NT 系列的 “命令提示符” 窗口。

可以从 grub4dos 进入一个 DOS 环境，然后再使用 yaya 的方法。不过，需要提醒的是，现在 BIOS 本身毛病很多，导致 DOS 不可靠，因此，DOS 下运行 bootlace 也就不可靠了。“不可靠” 的意思是说，bootlace 有可能写入到错误的扇区上，导致硬盘开头部分的扇区数据被覆盖掉，使整个硬盘都无法被操作系统识别，需要重新格式化才能解决。所以，通常我们建议尽量不要在 DOS 下运行 bootlace。

有人曾经建议，把 bootlace 移植到 grub4dos 环境，在 grub4dos 环境执行这个操作，就比较可靠了。其实也并不十分可靠。因为 grub4dos 的环境也照样是基于 BIOS 的，对于那些有毛病的 BIOS，照样容易出错。一般来说，如果 BIOS 支持 LBA，则通常可以认为是 100% 可靠的。而那些只支持 CHS 的 BIOS，则是非常不可靠的。即使 BIOS 支持 LBA，它也可能出现问题，因为 BIOS 可能仅仅支持 LBA 的读操作，而不支持 LBA 的写操作。如果 BIOS 不支持写入，则 bootlace 无法把启动代码写入到硬盘。我们看到，由于 BIOS 本身存在各种各样的毛病，在 BIOS 之下执行 bootlace 的操作，已经保证不了较高的可靠性了。这对于需要高可靠性的 bootlace 操作来说是致命的。大家都不希望 bootlace 失败，更不希望 bootlace 会造成破坏。也因此，把 bootlace 移植到 grub4dos 的工作，就没有必要再去做了。

综合一下，前面提到了两点：

其一，bootlace 在基于 BIOS 的环境不可靠。建议不要采用这种方式。
其二，bootlace 在 WIndows NT 系列下只能间接进行安装，不能直接进行安装，需要拐个弯，通过 dd for windows 来实现。不过，这种方法倒是可靠的，因为这不再使用主板本身的 BIOS 了，而是使用 Windows NT 所提供的虚拟 DOS 服务。注意，这里的 “可靠” 不等于 “安全”。“可靠” 是指 bootlace 不会犯错，不会出现莫名其妙的错误了。“安全” 是指当你使用 dd for windows 写盘时，你需要保证不写入到错误的盘上。如果你写入到错误的盘上，那就直接毁了这个被写的盘。因此，安全性与 bootlace 无关，而与操作者有关。这就解释了 “可靠” 不等于 “安全”。

好了，该说说第三种方法了。那就是，使用 Linux，它也是可靠的方法。使用 Linux 之所以可靠，是因为 Linux 也不使用主板 BIOS。与 Windows NT 相比，使用 Linux 的好处是不用拐弯了，因为 Linux 下的 bootlace 支持直接写入物理硬盘。当然了，由于不再拐弯，所以，安全性也算是比较好了。

最后再总结一下，推荐的可靠方法只有两种：

1、使用 Windows NT，但需要 “拐弯” 经由 dd for windows 实现安装。
2、使用 Linux，直接安装。

具体使用方法，可以参考 grub4dos 软件包里面的 README 文件。


最后再补充强调一点。Windows NT 的 “命令提示符” 之下所运行的 DOS 程序，可以调用 DOS 服务，即 int21，这是由 NT 系统所提供的虚拟 DOS 服务。当然，其他相关的 DOS 服务也会由 NT 系统来提供。但是，NT 系统不提供 int13 这个 BIOS 服务。所以，INT13 方式的读写磁盘，都会返回失败信息。这就是为什么不能在 NT 的 “命令提示符” 下使用 bootlace 0x80 的原因，只能使用 bootlace MyFile 的方式，这种方式使用的是虚拟 DOS 的 int21 磁盘服务，而不是使用 BIOS 的 int13 磁盘服务。

严格来说，bootlace 支持三种运行环境：

1、带有 BIOS 的 DOS 环境。例如，实模式下的 DOS 环境，使用主板提供的 BIOS。再比如，Win98 的 DOS 窗口，既含有虚拟的 DOS 服务，也含有虚拟的 BIOS 服务。bootlace 既可以使用 int13 BIOS 服务，也可以使用 int21 DOS 服务。
2、不带 BIOS 的 DOS 环境。Windows NT 的命令提示符就是这样的环境，它阉割掉了 BIOS 的 int13 磁盘服务，只能使用虚拟的 DOS 磁盘服务 int21。
3、Linux 32 位（或 64 位）环境，bootlace（或 bootlace64）使用 Linux 的系统调用进行磁盘的读写。

不点

你的命令行敲错了，grub.exe 中间插入了一个多余的逗号。

根据你的描述，目前我初步认为，这不是 bug。

你这个用法是把 grub.exe 当作 Linux 内核格式来执行。Linux 内核格式是不接受外面传来的 grub 信息的。

所以，root 的指定是无效的。

不过，你可以在命令行指定 root，就是在 echo 命令的前后执行 root 命令，这样就没问题了。

不点

mdyblog 发表于 2014-10-8 15:00
请问，map 的信息如何完全屏蔽，又不丢失 条件码？ 如图所示:

debug off 也没屏蔽掉 map 的输出？不会吧？这大概得让 chenall、yaya 去解决了。

不点

mdyblog 发表于 2014-10-8 15:05
grub.exe 无法像grldr 一样 传递 当前 根分区信息。
这和一般理解和习惯很不同啊！！
可惜啊。

还有，这个原因出在 调用者wee63 还是 被调用者grub.exe???
能出(cd), 说明还是传递了信息。 "(cd)"本身也是信息啊！

我又考虑了一下，传递根分区的信息，应该也是可能的。稍后我看看能否解决这个问题。

不点

mdyblog 发表于 2014-10-8 15:05
逗号是笔误， 拷贝到帖子上时笔误。实际没有。否则也出不了上图。

意思是grub.exe 无法像grldr 一样 ...

我上载了一个版本，你看看有没有问题。
http://bbs.wuyou.net/forum.php?m ... &extra=page%3D1

不点

是不是需要用 \x20 来表示一个空格啊？

不点

mdyblog 发表于 2014-10-11 08:54
debug off
map /IMG/SSHYDOS.IMG (fd0) >nul && set ok=1

也许 pseudo 用红色标明的 >nul，是说错误就在此处呢？我猜测，他或许是暗示 “>” 和 “nul” 之间应该有个空格？

不点

mdyblog 发表于 2014-10-11 09:16
谢谢！
下面测试 set 命令不翻译\x20

很抱歉，我不熟悉 grub4dos 里面的批处理程序设计。恐怕你得问问 chenall 才行。chenall 也许有现成的办法来解决这个问题，即使没办法，他也会把它当作 bug 予以修复。

不点

你可以改源代码，重新编译。有的部分是汇编写的，有的部分是 C 语言。这对你来说都不难。你修改了 wee，那么 wee 就是你自己的了。

不点

mdyblog 发表于 2014-10-11 11:05
请问wee源码在哪儿？

wee 的项目在 google code 上，属于 grubutils 项目的一部分。但 google 已经处于半死不活的状态了。我估计 chenall 迟早要把它迁移到 github 上。你等着吧。

不点

mdyblog 发表于 2014-10-11 12:11
请麻烦给个网址，下来看看。

grubutils 在这儿：
https://code.google.com/p/grubut ... se/#svn%2Fgrubutils

wee 在这儿：
https://code.google.com/p/grubut ... n%2Fgrubutils%2Fwee

用 chenall 建立的那个 grub4dos 编译环境，就可以编译 wee。

不点

mdyblog 发表于 2014-11-1 13:29
报告一个现象， 不知道 是否算BUG。或者我用的不对？

root (hd32)   这里就出现磁盘问题：

怎么不说说 0.4.5c 的情况？

0.4.6 与 0.4.5 的磁盘仿真代码有差别，这一点你该明白吧？所以，涉及到仿真的问题，一定要拿 0.4.5 作为参照物进行对比才行。不然的话，还留着 0.4.5 干什么用？

不点

mdyblog 发表于 2014-11-1 15:54
0.45C 好像没有 usb加速。
usb加速 对我更重要。
扇区序列  --in-situ   也是我今年央求2011yaya20077 ...

0.4.5 本来就有 --in-situ 支持。如果没有，如果它的含义不明确，你凭什么让 yaya 加上？

不点

mdyblog 发表于 2014-11-1 16:09
》》0.4.5 本来就有 --in-situ 支持。如果没有，如果它的含义不明确，你凭什么让 yaya 加上？
原来的 -- ...

其一，既然0.4.5没有这功能，你又是怎么完成上面测试的？

其二，两者的出错信息不同。0.4.5是未能识别出 iso 为合法 iso 格式，不严重。而 0.4.6 显示的错误是 "磁盘读" 错误，是严重的。假如你换个普通的 iso 文件，0.4.5 就不会报错了。你不妨用个普通的 iso 文件试试。

不点

mdyblog 发表于 2014-11-1 16:46
>>其一，既然0.4.5没有这功能，
0.45c 也在同步更新， 助手2014-10-29的版本。
我以为0.45c “定”型 ...

据我所知，0.4.5的仿真功能没改动过。一直是支持仿真扇区序列的。

0.4.5的报错，含义是未识别出文件系统为合法的iso。你用的iso可能是只有0.4.6才支持的格式。你要是愿意测试，你很容易找个普通未增强的 iso 文件来测试，或者自己用 mkisofs 新建一个小的 iso 文件来测试。不想测试也就算了。

不点

chenall 发表于 2014-11-1 18:08
首先需要确认执行map命令时的文件是否和你存的文件一致

使用cat --hex命令可以看到文件内容。

chenall 你如果身体吃得消的话，可以建立一个环境，测试这一问题。看看是不是 grub4dos 的仿真在某个环节有漏洞。难道说，不支持没有分区表的 --in-situ 仿真？希望首先要把这个事实搞清楚，至于说能不能修复 bug，则是次要的问题。

不点

(hd32)+10 是不够的，应该是 (hd32)+17 才能看到 iso9660 的文件系统结构数据。

另外，map --status 也可以报告仿真盘的一些情况。比如，可以了解，宿主盘的起始扇区和长度，是否正确。

不点

我估计确实是个 bug，为了程序的完美，应该解决。

另一方面，mdyblog 可以绕过这个 bug，即，不使用 --in-situ 功能，就不会碰上这个 bug。

你只要把没有分区表的 IMG 仿真为软盘，就没问题了。就是说，只要不使用 --in-situ，就不会碰上 bug。

另外需要说明的是，--in-situ 设计的目的，不是像你这样的使用，它主要是为了应付 Win98 才设计出来的。通常是用不上的。你把它作为一个中间过渡虚拟盘来用，其本身就不是常规用法。--in-situ 的盘作为中间过渡盘来用，确实还未检验过，所以这个 bug 就一直存在，直到被你 “不正常的使用” 首次发现。

你们继续报告，这个 bug 可能由我来解决比较合适，因为相关代码是我写的。

不点

chenall 发表于 2014-11-2 00:00
关于in-situ的用法我也不是很了解,之前我还曾经想使用这个功能来实现一键GHOST(DOS版的)..

在GRUB4DOS中 ...

解释一下 --in-situ

它的字面含义是 “在原地”。如果把一个 volume 卷进行 “原地” 仿真，那么仿真后的虚拟盘是原先这个 volume 卷所在的整个硬盘，而不是仅仅只包含这个 volume 卷。仿真程序只把分区表进行虚拟（大家对此是理解的，那就是 “作假”）。仿真程序把 volume 所在的区域划归 (hdX,0)，即，把它当作虚拟盘的第一分区，并且激活它。分区表中原有的分区项目都会向后推移。如果原来的分区表的四个项目是满的，则拒绝使用 --in-situ 进行仿真。

在 --in-situ 仿真之下，虚拟盘的第一扇区（MBR）是整个硬盘的 MBR，而不是这个 volume 卷的第一扇区。由于虚拟盘与真实盘的扇区位置完全相同，没有偏移，所以，这个仿真取名为 “在原地” 仿真。

对比一下，加深了解。

假如是不带 --in-situ 的普通仿真，那么，这个 volume 卷的第一扇区将成为虚拟盘的 MBR（即，第一扇区）。注意，volume 卷的第一扇区肯定不是真实硬盘的第一扇区，但它却成为虚拟盘的第一扇区了，这就有偏移了，所以，这就不是 “在原地” 仿真了。

通常用不上 --in-situ。有时候使用 partnew 命令真实地写入分区表，可能更好。注意微软会忽略 ID 为 00 的分区。所以，假如你在 MBR 上用 partnew 创建了一个分区 ID 为 00 的分区，那么微软的操作系统是看不见它的。但新版的 grub4dos 还能正常访问这样的分区里面的文件系统。所以，灵活运用 ID 00，会收到意想不到的效果。

不点

chenall 发表于 2014-11-2 09:29
谢谢,这样子就比较清楚了..

另外能不能麻烦再解释一下另一个 --in-place的用途,和--in-situ的区别

--in-place 和 --in-situ 的字面意思相同，都是 “在原地” 的意思。它们有两个差别：

其一，--in-place 是未公开的选项。--in-situ 是已公开的选项。
其二，当分区表的四个表项已经占满时，--in-situ 会拒绝仿真，而 --in-place 会继续仿真。继续仿真时，有一个表项会被挤出去。具体是哪个被挤出去，我也记不得了，可以通过试验来弄清楚。

在 --in-situ 仿真已经生效以后，如果进入某个实模式操作系统环境（DOS），而且某个软件写入了 MBR 扇区，则有可能会把仿真的分区表写入到真实的分区表上，引起分区顺序的变动，连同激活标志也改变了。这个变动所带来的问题不是灾难性的，因为所有的分区项目都在。但在 --in-place 的情况下，被挤出的那个分区表项将永久丢失。所以，使用 --in-situ 或 --in-place 生效之后，最好不要再去运行那些分区软件了。运行分区软件也可以，只是注意不要让它对 --in-situ 和 --in-place 虚拟盘进行分区操作。

不点

mdyblog 发表于 2014-11-2 07:33
谢谢！

我用的--in-situ 的目的， 为了避免兼容问题。

正如前面提到的，大多数情况下可以使用 partnew 来 “实做”，取代 --in-situ 的 “弄虚作假”。如果你非要使用 --in-situ，那就等着修复 bug。

不点

mdyblog 发表于 2014-11-2 09:15
麻烦再问个问题： 什么命令可打开 grub4bdos的多扇区读（写）加速功能？

geometry --lba127sector 后面可以跟着一个盘号，比如 (hd0) 或 (fd0) 之类的。如果不跟参数，那就对当前盘（即，当前 root 设备所在的磁盘）进行操作。

默认时已经是 geometry --lba127sector 的了，所以，你无需运行这条命令。

对于 buggy 的电脑，内置菜单的初始化命令的开头应该有 geometry --lba1sector 命令，控制磁盘读写都是按照慢速的单扇区模式进行的。

有一个专门讨论的帖子，谈到 geometry --lba1sector 命令应该总是放在内置菜单的开头，只不过默认时自动跳过，而在有问题的电脑上，开机启动 grub4dos 时按下某个热键（可以与 C 键和 Insert 键放在一起进行处理，比如，按 S 键表示慢速 Slow、安全 Secure、单扇区 Single Sector 启动），可以让 geometry --lba1sector 真的起作用，这样，皆大欢喜，都没问题了。希望 chenall 抽时间把这个细致的工作做好。

更新：又考虑了，可以在 init_bios_info() 函数里面直接添加并处理 geometry --lba1sector，无需更改现有的内置菜单。

不点

mdyblog 发表于 2014-11-2 10:19
对呀!
map  --in-place  ...  是何方神圣？什么时候加的。
grub4dos 随时跟进的说明书在哪儿啊？ 我一 ...

是未公开的，不想让普通人使用的参数。一开始就支持这个参数。在能够使用 --in-situ 的情况下，尽量不要使用 --in-place。

不点

请 mdyblog 试试这个版本，估计问题应该解决了。如果解决，就可以提交。

更新：刚刚改正了错误，请下载测试。

不点

chenall 发表于 2014-11-2 11:49
是的,这是比较好的方案.

另外当用户按了S之后应该要暂停并给一个提示.

不用任何提示。就像 C 键与 Insert 键一样，都没有提示。如果你想给 S 键一个提示，也是可以的。比如，可以在具体执行与 geometry --lba1sector 等价的函数之时，强制打印一条信息（这条信息不可屏蔽，并延迟 5 秒），表示对某某 drive 执行了 geometry --lba1sector 的动作，让用户明白，S 键已经起作用了。至于说在按 S 键的时候，倒是不需要给出提示。

这其实还是一个权衡问题。这样的用户不多，所以，我们不照顾他们。如果为了照顾他们，事先显示某个信息 5 秒钟，这就影响了大多数人的使用感受，就不好了。

只是在按 S 键以后（而且等到真正处理的时候）才显示信息，这样是比较好的。这是我的看法。究竟该怎样，还要看你来权衡和定夺。

不点

mdyblog 发表于 2014-11-2 13:19
请问 Insert 键 按下有什么功能/效果？

调试启动失败的时候，使用 Insert 可以在启动时，单步跟踪关键步骤的执行，每一步执行完成，会暂停，显示调试信息，并等待按键进入下一步的跟踪。

不点

我的意思是不用改动现在的 geometry 命令。

只是在 init_bios_info() 里面，在其结尾处，检查用户是否按过了 S 键，如果有按 S 键，就执行

geometry_func ("--lba1sector", 0); 或者类似的命令。

在执行这条命令的前后，给出一条信息，并等待 5 秒。信息可以像是这样的：

You pressed the S key, and "geometry --lba1sector" is successfully executed for drive 0x%X.