GRUB4DOS更新建议、bug反馈专帖

hhh333

经过将grldr.mbr写入mbr并改名grldr为h3_mgrw7.bin，在NTFS下是成功的。又导出MBR仔细核对，发现是我在对grldr.mbr改名操作的时候有误，将09e7处的51改成00就OK了，我估计将这个51也当成文件名处理了，因为没有00这个结束符。但提示信息已经改好名了，所以出现这个文件没有找到的信息，它实际上根本就不是在找这个文件！我看了一下这个文件，它是按分区不同分段的，fat32的没有错误，所以可以找到。因此造成了一个伪BUG，确实不好意思！

有不有对grldr.mbr快速改名工具？我上面提到的“09e7处的51改成00”不会有副作用吧？

另外，我在用wee时，觉得每个命令前都来一个find似乎有点多余，何不在内部处理？真不太理解。难道它没有当前盘的概念？

不点

我确实不知道哪个改名工具更 “可靠”。任何软件都可能犯错误。这只有经过大量测试，才能知道。

既然你已经弄清楚原因了，也就无所谓了。开发人员的视角通常都是这样的，只要软件本身没有 bug，也就不再追究了。

不过，你说的 51 是何意思，我不明白。难道说，grldr.mbr 的文件名空间不够？在 NTFS 引导扇区上应该留足了

8（基本名）+1（小数点）+3（扩展名）+1（结尾的 00 字节） = 13

个字节的空间。

刚才看了，你说的 09eX 处，那根本不是 NTFS 的代码，而是 ext2 的代码。因此，NTFS 应该根本不受影响的。（因此你一定是又搞错了）。

NTFS 引导扇区位于 0A00 以后。存放 grldr 文件名大约在 0bd3 处附近。它后面有足够的空间，为文件名存放 13 个字节，完全没问题。

至于说前些天你提到的 wee127 的 map 问题，你也没说清楚（贴个图呀啥的）。看你无意解决问题，我也就没继续跟帖了。

wee 没有当前盘的概念，这倒是给你猜到了。wee 驻留在 MBR，当然没有当前分区的概念了。

不仅 wee 没有当前分区的概念，grldr.mbr 也没有。只有 GRLDR 才有当前分区的概念。

就 wee 和 grldr.mbr 而言，它们可以被别的软件启动，而他们并不假定别的软件能够传递正确的 DL。因此，它们没有当前盘的概念。

dvd008

不知道你的grldr.mbr 哪里来的

我的是:使用那个MAKE....ISO.EXE, 制作ISO,然后,提取引导文件,
重命名为.MBR.    GRLDR----GRLDR.MBR

如果先把GRLDR改名,如HRLDR,得到HRLDR.MBR

不同版本的GRLDR不同

hhh333

原帖由 不点 于 2011-9-15 10:20 发表
我确实不知道哪个改名工具更 “可靠”。任何软件都可能犯错误。这只有经过大量测试，才能知道。

既然你已经弄清楚原因了，也就无所谓了。开发人员的视角通常都是这样的，只要软件本身没有 bug，也就不再追究 ...

只能上个图了，是9月8日的grldr.mbr:


e351被覆盖了。以下是用bootice写grldr.mbr到MBR后再导出的，似乎在0980处比grldr.mbr往前错了一位。


[ 本帖最后由 hhh333 于 2011-9-15 13:04 编辑 ]

不点

这再次证明了，你改的是 ext2 引导扇区，根本不是 NTFS 引导扇区。再次提醒，你改的地方完全没有影响（完全不起作用），因为你的系统没有 ext2 分区，这永远不会用到的。你能确认你改这就起作用了？那可就真的有神仙相助了耶！

位于 A00 之后的，才是 NTFS 的引导扇区。

-----------------

关于 ext2 中你提到的两个字节，以前专门讨论过。这两个字节对于启动过程不起作用，建议废除这两个字节的原有功能。grubinst 以及其他工具软件，有可能使用这两个字节。建议不要用这些工具来修改。鼓励手动修改，就是，不管这两个字节，直接覆盖。

如果改名工具仍然使用这两个字节，由于这两个字节可能已经被覆盖，因此有可能误导那些改名工具，使得它们把文件名放置在指令代码上，直接造成 grldr 启动失败。

因此建议，用手动改名，这样最安全。

[ 本帖最后由 不点 于 2011-9-15 13:45 编辑 ]

zxw

shift 连写的问题：

hhh333

终于找到真正的原因，确实不是09e0处的问题，是0bd0处必须用小写，而我的H3_MGRW7.BIN文件在盘上是大写的，这个不好理解。我再将文件改成小写的看怎么样....

测试了：文件名大小写无影响。但0bd0处必须用小写。

[ 本帖最后由 hhh333 于 2011-9-15 16:30 编辑 ]

chenall

你又犯了常识性错误。。变量在执行一行前就替换了。。。

[ 本帖最后由 chenall 于 2011-9-15 15:43 编辑 ]

zhaohj

原帖由 zxw 于 2011-9-15 14:37 发表
shift 连写的问题：

很久以前就碰到这种问题了。
与变量、参数有关的操作，分行写。
如：
!BAT
set /a x1=10
set /a x2=8
set /a x1=%x1%+%x2% && set /a x2=%x1%-%x2%
------------------
!BAT
set /a x1=10
set /a x2=8
set /a x1=%x1%+%x2%
set /a x2=%x1%-%x2%

是完全不同的结果。

zxw

嘻，明白了。谢谢指教。

快雪时晴

一行批处理：
先替换变量，再执行，而不是分段执行后再获取变量

dihuo0

不是shift 连写的问题，再复合语句中，变量会先解析，然后在执行整个复合语句，变量的值的变化不能及时反映出来。例如：
set var=1
set var=2 && echo %var%
echo %var%
执行的结果就是先输出1，在输出2。

hhh333

请问各位 USBCDROM 在g4d中会被识别成CD还USBHDD，0x8280会是什么数值？

不点

这问题还敢问？

CDROM 只能识别为 CD。

至于说 drive number，那可不一定是什么，由 BIOS 决定。

hhh333

哈，有点初级，但我用checkrange 0x9f read 0x8280 && set bd=cd来查是不是从CD启动，有的反馈得到的bd不等于cd。这个不是没办法检测？

哦，不点已经说了，设备number就不一定是0x9f了！

看来前面的判断方法还有问题，还要检测>=0xA0？

[ 本帖最后由 hhh333 于 2011-9-19 19:22 编辑 ]

不点

什么叫 >=0xA0 ????

由 BIOS 传入的 cd 号码，完全没有规范的规定！

你这个 0x9F 就小于 0xA0 了！！

要说规定，含含糊糊的有，就是在 0x80 以上。其实，假如某个垃圾主板故意设置在 0x80 以下，谁也没办法。

hhh333

那。。。。可如何是好？难道我要判断是不是从CD启动都没了办法了？

暂时莫考虑这些垃圾主板了，人家要垃圾我们也没有办法！通用的判断是不是从CD启动的办法有吗？怎么写这个代码？

[ 本帖最后由 hhh333 于 2011-9-19 20:18 编辑 ]

chenall

直接用root (cd)检测不就行了?
root (cd) && echo Boot From Cdrom....
也可以这样
cat --length=1 (cd)+1 && echo Boot From Cdrom....

只有从CD启动时才会有(cd)设备.

hhh333

如果有usbcdrom和cdrom同时存在，不会有问题吧？
或者这么用if %@root%==(cd) echo echo Boot From Cdrom....

chenall

嗯,if %@root%==(cd) 这个倒是不错的办法.

同时存在,只有启动盘才是(cd)

hhh333

刚才dalin_01 (子夜听雨)测试了，确实用usbcdrom时%@root%也是(cd)，0x8280中是0xef，还是大于0xA0的！

不点

我似乎觉得，root (cd) 更好一些。

这是因为，root (cd) 要有 mount 的动作，而这就要检查介质中是否有 ISO9660 文件系统。

因此这样是 “保险” 的（即 “可靠” 的）。

hhh333

又碰到一个难题，set a=TOM && BOP，即一个变量中有&&显然直接用不行，&&会当成连接符处理

chenall

这个自己去想办法解决,办法有N多种....

zhaohj

最简单可能是
echo -e TOM \&\& BOP | set a=

不点

@hhh333

抱歉我前面的帖子有些莽撞。是因为在潜意识中对你的要求过高，所以才那样。部分原因是由于跟你比较熟悉。

你之所以有那些疑问，正是因为你对磁盘、文件系统的结构不熟悉造成的。而这点知识应该算是必备的知识。下面我就简单说说。

最开始的时候，只有软盘。DOS 把软盘弄成 FAT 格式。软盘第一扇区就是 FAT 的引导代码。你要善用 hexedit 工具，看看软盘扇区的模样。

到后来，有了硬盘，硬盘太大，就划分成若干个 “分区”，每个分区就是一个 FAT 文件系统，DOS 把每个分区称为一个 drive。可见，它实际上把每个分区当作一个 “软盘驱动器” 来对待了。每个分区的第一扇区，就是 FAT 的引导代码。由于硬盘需要划分分区，所以硬盘需要有分区表，这个分区表就位于整个硬盘的最开头（MBR）。所以，你还应该熟悉 MBR 的模样。用 hexedit 工具查看一下吧。

再后来，有了光盘。这完全不兼容于软盘、硬盘的结构。光盘上的文件系统叫做 iso9660 文件系统。它没有 MBR，也没有 FAT 的引导扇区。

由于光盘文件系统格式与软硬盘不兼容，而实际上又需要兼容，因此出现了 “模拟软盘” 和 “模拟硬盘” 两种启动格式，再加上 “无模拟” 格式，光盘的启动格式总共也就这三种。这三种格式属于启动规范，它们不是新的光盘文件系统格式，它们只是在 ISO9660 文件系统的框架下，补充规定的、专用于启动的规范。“模拟软盘” （或 “模拟硬盘”），顾名思义，就是在光盘上划出一部分扇区，用来仿真一个软盘（或者仿真一个硬盘）。这些用于模拟的扇区，当然也有 FAT 的引导代码（或者 MBR）。除了这用于模拟的一小部分扇区以外，整个光盘仍然是 iso9660 文件系统，仍然是与旧的磁盘结构不兼容的。

grub4dos 中的光盘 (cd) 是 iso9660 的文件系统，它访问的是整个光盘的全部扇区。用 hexedit 工具查看它吧。

如果没有 hexedit 之类的工具，你也可以用 grub4dos 来查看软盘、硬盘、光盘的扇区数据。举例来说：

查看软盘：cat --hex (fd0)+20
查看硬盘：cat --hex (hd0)+20
查看光盘：cat --hex (cd)+20

[ 本帖最后由 不点 于 2011-9-20 18:18 编辑 ]

hhh333

不点老大就是老大，受教！我用hexedit仔细看一看。

hhh333

这个只能在g4d中用吧，我在MSCMD中还没找到方法。

另外请教有什么快速检测g4d是否已经装载unifont字库的方法

zxw

checkrange 0xbdc6aecb read 0x400000 && echo unifont OK.

[ 本帖最后由 zxw 于 2011-9-22 09:58 编辑 ]

dihuo0

今天我无意中发现最新版（grub4dos-0.4.5b-2011-09-18）grldr.mbr的内置菜单好像是有问题，用FbinstTool打开是乱码，后来用grldr.exe打开是空白。