GRUB4DOS更新建议、bug反馈专帖

hhh333

既然有了一个新的?_boot，那就只对这个进行处理就OK了

chenall

这样子也没有用，还是没有办法正确判断是否从FB启动的。

解决问题的根本在于修改FBINST的源码，不过这些都是汇编的，我看不懂

chenall

使用pxe keep再chainloader 就不会死了，或者在chainloader之后再执行root (hd0,0)之类的语句也不会死

因为没有pxe keep这时的启动盘还是(pd)，启动时自动卸载PXE后再访问这个(pd)会出错，导致卡死（新的版本已经修正这个问题）

zhaohj

原帖由 chenall 于 2011-10-9 11:39 发表
使用pxe keep再chainloader 就不会死了，或者在chainloader之后再执行root (hd0,0)之类的语句也不会死

因为没有pxe keep这时的启动盘还是(pd)，启动时自动卸载PXE后再访问这个(pd)会出错，导致卡死（新的版本 ...

佩服C大分析问题及解决问题的能力！
目前这样可行：
checkrange 0x21 read 0x8280 && pxe keep
chainloader /grldr
boot
-------------------------
如果没有checkrange 0x21 read 0x8280 && pxe keep，只能启动到命令行模式，PXE丢失。

[ 本帖最后由 zhaohj 于 2011-10-10 08:23 编辑 ]

zxw

发现原?_Boot已更正为：?_BOOT了。
但?_Boot还保留着？

chenall

忘了改掉了，下次再改。。谢谢提醒。。

zxw

嘻，什么时候支持空设备了？



晕，换个其它字符串也是一样？


[ 本帖最后由 zxw 于 2011-10-11 22:02 编辑 ]

chenall

很早就改了，忘了是从哪个版本开始改的.

看起来NUL和不存在的文件名的效果是一样的，其实处理方法是不一样的。

对于nul直接忽略输出结果。其它情况会尝试写入。

只是新的版本对于输出重定向时文件写入错误的情况直接忽略了。所以看起来是一样的。

zxw

汗，我一直用:
>>  (md)+1,1
来实现这个功能。

[ 本帖最后由 zxw 于 2011-10-11 23:05 编辑 ]

chenall

请注意

使用 >> (md)+1,1，写入可能会导致系统出错，因为你这样写入实际上修改了中断0的地址，万一刚好有程序用到这个中断的话就会出问题了。

低端的内存不建议随意写入。

zxw

>> (md)+1,1
实际上不会写入吧。
嗯，还有一种恰好为\0的情况。谢谢指正。

[ 本帖最后由 zxw 于 2011-10-12 17:47 编辑 ]

zhaohj

有了nul 方便，与DOS接轨！
最好再设计一个空的敏感命令，等于kernel || clear
方便在菜单中使用。

sratlf

不点、chenall大能不能查下1004版的grub4dos是否产生了bug

2011-10-03 (tinybit)changed buf_addr from 0x20000 to 0x100000 to avoid possible conflict between dd_func and get_diskinfo.

如下六个菜单   使用1002版及之前的grub4dos都可以正常启动

换用1004版之后的grub4dos前三个没问题  可以正常启动  后三个均在分区阶段0x7B蓝屏


一个简单的规律  只要  map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)一句在 dd if=(fd1) of=(fd0) count=1 之后执行  就会蓝屏
  

1. title [01] XP
   
2. 
   
3. map /BOOT/IMGS/FIRADISK.IMG (fd1)
   
4. 
   
5. map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)
   
6. 
   
7. map --mem (md)0x6000+2880 (fd0)
   
8. 
   
9. map --hook
   
10. 
    
11. dd if=(fd1) of=(fd0) count=1
    
12. 
    
13. find --set-root /WIN$.ISO
    
14. 
    
15. map /WIN$.ISO (0xff)
    
16. 
    
17. map --rehook
    
18. 
    
19. write (99) [FiraDisk]\nStartOptions=cdrom,vmem=find:/WIN$.ISO;floppy,vmem=find:/BOOT/IMGS/FIRADISK.IMG;\n\0
    
20. 
    
21. chainloader (0xff)
    
22. 
    
23. boot
    
24. 
    
25. 
    
26. 
    
27. title [02] XP
    
28. 
    
29. map /BOOT/IMGS/FIRADISK.IMG (fd1)
    
30. 
    
31. map --mem (md)0x6000+2880 (fd0)
    
32. 
    
33. map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)
    
34. 
    
35. map --hook
    
36. 
    
37. dd if=(fd1) of=(fd0) count=1
    
38. 
    
39. find --set-root /WIN$.ISO
    
40. 
    
41. map /WIN$.ISO (0xff)
    
42. 
    
43. map --rehook
    
44. 
    
45. write (99) [FiraDisk]\nStartOptions=cdrom,vmem=find:/WIN$.ISO;floppy,vmem=find:/BOOT/IMGS/FIRADISK.IMG;\n\0
    
46. 
    
47. chainloader (0xff)
    
48. 
    
49. boot
    
50. 
    
51. 
    
52. 
    
53. title [03] XP
    
54. 
    
55. map /BOOT/IMGS/FIRADISK.IMG (fd1)
    
56. 
    
57. map --mem (md)0x6000+2880 (fd0)
    
58. 
    
59. map --hook
    
60. 
    
61. map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)
    
62. 
    
63. dd if=(fd1) of=(fd0) count=1
    
64. 
    
65. find --set-root /WIN$.ISO
    
66. 
    
67. map /WIN$.ISO (0xff)
    
68. 
    
69. map --rehook
    
70. 
    
71. write (99) [FiraDisk]\nStartOptions=cdrom,vmem=find:/WIN$.ISO;floppy,vmem=find:/BOOT/IMGS/FIRADISK.IMG;\n\0
    
72. 
    
73. chainloader (0xff)
    
74. 
    
75. boot
    
76. 
    
77. 
    
78. 
    
79. title [04] XP BSOD
    
80. 
    
81. map /BOOT/IMGS/FIRADISK.IMG (fd1)
    
82. 
    
83. map --mem (md)0x6000+2880 (fd0)
    
84. 
    
85. map --hook
    
86. 
    
87. dd if=(fd1) of=(fd0) count=1
    
88. 
    
89. map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)
    
90. 
    
91. find --set-root /WIN$.ISO
    
92. 
    
93. map /WIN$.ISO (0xff)
    
94. 
    
95. map --rehook
    
96. 
    
97. write (99) [FiraDisk]\nStartOptions=cdrom,vmem=find:/WIN$.ISO;floppy,vmem=find:/BOOT/IMGS/FIRADISK.IMG;\n\0
    
98. 
    
99. chainloader (0xff)
    
100. 
     
101. boot
     
102. 
     
103. 
     
104. 
     
105. title [05] XP BSOD
     
106. 
     
107. map /BOOT/IMGS/FIRADISK.IMG (fd1)
     
108. 
     
109. map --mem (md)0x6000+2880 (fd0)
     
110. 
     
111. map --hook
     
112. 
     
113. dd if=(fd1) of=(fd0) count=1
     
114. 
     
115. find --set-root /WIN$.ISO
     
116. 
     
117. map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)
     
118. 
     
119. map /WIN$.ISO (0xff)
     
120. 
     
121. map --rehook
     
122. 
     
123. write (99) [FiraDisk]\nStartOptions=cdrom,vmem=find:/WIN$.ISO;floppy,vmem=find:/BOOT/IMGS/FIRADISK.IMG;\n\0
     
124. 
     
125. chainloader (0xff)
     
126. 
     
127. boot
     
128. 
     
129. 
     
130. 
     
131. title [06] XP BSOD
     
132. 
     
133. map /BOOT/IMGS/FIRADISK.IMG (fd1)
     
134. 
     
135. map --mem (md)0x6000+2880 (fd0)
     
136. 
     
137. map --hook
     
138. 
     
139. dd if=(fd1) of=(fd0) count=1
     
140. 
     
141. find --set-root /WIN$.ISO
     
142. 
     
143. map /WIN$.ISO (0xff)
     
144. 
     
145. map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)
     
146. 
     
147. map --rehook
     
148. 
     
149. write (99) [FiraDisk]\nStartOptions=cdrom,vmem=find:/WIN$.ISO;floppy,vmem=find:/BOOT/IMGS/FIRADISK.IMG;\n\0
     
150. 
     
151. chainloader (0xff)
     
152. 
     
153. boot

复制代码

chenall

使用WINVBLK正常吗？不使用dd命令是否正常（可以直接映射一个空白的镜像）。

不点

怀疑是 firadisk 自己的 bug。

你使用的 dd 命令，正好复制一个扇区，也就是以 55 AA 结尾的引导扇区。

新版本会把 1M 处的 64K 当作 dd 的缓冲区。因此，执行这个 dd 之后，1M 处的一个扇区就是 dd 复制的那个扇区，结尾是 55 AA。

也就是说，新旧的差别就在于 1M 处有一个扇区的变化。旧版本在 1M 处没有合法的引导扇区标志 55 AA，而新版本就多出来一个 55 AA 的合法标志。

这样，进入 Windows 后，（猜测）firadisk 错误地把 (99) 当作一个合法的软盘进行处理了，所以，导致死机。

解决办法，（试试）在执行 map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99) 之前先清空 1M 处的一个扇区。

注意，(md)0x800+4 其实就是 1M 处的 4 个扇区。你应该把它的第一扇区清零。至少把第一扇区结尾的 55 AA 抹掉。

然后再执行 map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99) 命令。这样应该没问题了。

zhaohj

sratlf的报告看来已经找到问题的所在了。
其他不改，把下面这句：
map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)
改成
map --heads=2 --sectors-per-track=18 --mem (md)0x801+4 (99)
或
map --heads=2 --sectors-per-track=18 --mem (md)0x200+4 (99)
试试，以便避开1M处的55AA。反正不是1M开始就可以。

[ 本帖最后由 zhaohj 于 2011-10-14 08:59 编辑 ]

快雪时晴

能不能列出g4d使用的各个内存段啊，都不知道哪些是可以自由使用的

sratlf

@chenall

winvblock正常  没有出现0x7B蓝屏  不使用dd命令的话用firadisk也正常  没有蓝屏

@不点

谢谢  这样的话大概明白是什么原因了

@zhaohj

ok  这就试试  

还有突然想起来 能不能使用(rd)  应该不会占用grub的可能会使用的内存块吧

如map --heads=2 --sectors-per-track=18 --mem (rd)+4 (99)


============================================================
试了下  下面菜单  将(md)0x800更改为(md)0x801或(md)0x200可行  不会出现蓝屏

还有个问题不太明白  使用(md)0x800的话  在dd一行后面执行 map ... (99) 最后会蓝屏

但是先执行map ... (99) 再执行 dd一行命令就没问题  不会蓝屏  这个有什么区别吗

title [04] XP BSOD
map /BOOT/IMGS/FIRADISK.IMG (fd1)
map --mem (md)0x6000+2880 (fd0)
map --hook
dd if=(fd1) of=(fd0) count=1
map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)
find --set-root /WIN$.ISO
map /WIN$.ISO (0xff)
map --rehook
write (99) [FiraDisk]\nStartOptions=cdrom,vmem=find:/WIN$.ISO;floppy,vmem=find:/BOOT/IMGS/FIRADISK.IMG;\n\0
chainloader (0xff)
boot

[ 本帖最后由 sratlf 于 2011-10-14 11:02 编辑 ]

zhaohj

sratlf 还没明白不点大的解释。
新版dd命令使用1M开始的64kb区域作为缓存，dd if=(fd1) of=(fd0) count=1，执行后在(md)0x800+1中缓存了(fd1)的MBR
map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)这里把dd的缓存即(fd1)的MBR也写进了(99)
这样导致读(99)盘出现问题，相当于(99)盘不起作用了。
map前清空就没问题了：echo -n > (md)0x800+1

sratlf

理解了  谢谢

chenall

难怪，之前我看到报告测了几次都没有发现问题。

因为我都是直接使用map (md)+xxxx的，产生内存盘其实直接map (md)+xxxx (yy)就可以了
没必要map (md)xxx+yyy (zz)，除非特别需求。

这个问题的原因这样就很明显了，因为你映射的(99)带有55AA标志，所以firadisk把这个当成是一个软盘来处理了。

快雪时晴

原帖由 chenall 于 2011-10-14 12:33 发表
难怪，之前我看到报告测了几次都没有发现问题。

因为我都是直接使用map (md)+xxxx的，产生内存盘其实直接map (md)+xxxx (yy)就可以了
没必要map (md)xxx+yyy (zz)，除非特别需求。

这个问题的原因这样就 ...

grub4dos-help-2011-05-27帮助里说：

在grub4dos环境中，以下两块内存可以放心使用：

1、0x60000开始处1KB（即内存384KB开始的长度为1KB的区域），经常用于菜单或批处理临时使用。

2、0x40000－0x44FFF（即内存256KB至275KB之间，长度为20KB）也是可以使用的（这一段是最常使用的，且空间较大）。

其它16MB以内的内存最好不要随意使用，很多有特殊的用途。
保守一些的话，尽量使用32M以上的内存空间做临时文件用。

32M绝对地址：0x2000000 ；

32M扇区表示法：（md)0x10000+?（问号是数值多少，就代表从32M处开始的多少个扇区）

而不指定(md)+xx的话，岂不是直接从物理内存0开始？

grub4dos中有两个比较特别的设备：

(md) 、(rd)

(md) 设备访问内存是从物理地址 0 开始，而 (rd) 可以访问起始于任何基地址的内存。

我又看了另一个chenall博客里介绍的内存变量的说明，内存0开始可存放的是中断向量表，如此(md)+4岂不覆盖了？？

5、中断向量表
0000:0000H—— 1024字节

参见INT 21H之功能25H(设置中断号入口地址)和35H(读取中断号入口地址)

chenall

map --mem (md)+xxx (yy)

这个是不会改动到(md)+xxx部份的内存的，因为有使用了--mem参数

--mem会把这一部份内存复制过去，原内存不会改动。

低端内存不建议使用是不建议改写。比如

write (md)+xxx之类的。

不点

我觉得对于内存的使用，有必要补充一句话。grub4dos 处于不断发展之中，很多东西不能定型。目前粗略地谈到几个可以被用户使用的内存地址区域。对于那些使用内存很少的用户而言，这完全绰绰有余了。但是对于另外一些希望多多使用内存的用户而言，则 “百分百” 肯定是不够用的。

看看 karyonix 和 Sha0 都是怎么处理的？他们竟然不约而同地都用一个虚拟的磁盘来存放他们自己程序所需要的信息。

这就告诉我们，内存的使用，有各种方式。有些方式非常巧妙，不容易引起冲突。

将来 grub4dos 要支持 vesa 了，那样又要占据不少内存了。随着开发的进展，内存的使用或许会发生变化。但开发人员也会把兼容性问题放在一个很重要的位置的。所以，已经公开了的自由内存，应该是可以放心使用的。

－－－－－－－－－－－－－－

不过也许正好可以借此机会谈谈 gfxmenu 的问题。gfxmenu 似乎要占用常规内存中的一些区域，我不十分确定它占据哪些区域，但大致上是在 0x50000 以上。因此，如果用户同时也使用 gfxmenu，那么常规内存的使用就非常紧张了，很容易发生冲突。由于 gfxmenu 占据 0x50000 以上的常规内存，因此，它还可能与 PXE 相冲突。gfxmenu 还要使用 2M 处和 4M 处的扩展内存，不过，那已经与用户无关了，只是开发人员需要注意罢了。已经公开的自由内存，都在常规内存的范围里面。这些内存可以被用户自由使用。

当然了，对 grub4dos 了解很深的用户，他将发现有更多的使用内存的方法。比如前面有人提到的，使用 32M 以上的扩展内存。但那都属于 “未公开”的区域，不算是自由使用区域。

还有一点可供参考。我们公开的文档说，位于 0x20000 － 0x2FFFF 的 64K 空间是 grub4dos 本身使用的缓冲区。表面上看，用户无法使用这个区域。但实际上，grub4dos 也只是会写入这个区域而已。这个区域本身并不被 grub4dos 读取。grub4dos 的几何参数相关函数会写入这个区域，从而破坏这个区域里面的数据。而假如用户也写入了这个区域，那应该没什么危险，不会造成 grub4dos 的内核运行失常。因此，这个区域倒是也同时可以作为用户的 “缓冲区” 来使用了。当用户希望 “暂时用一用” 某个空间的时候，可以考虑把这个区域当作临时空间来写入。如果用户在写入的时候（或者说写入前后）没有访问文件的动作，则 grub4dos 的内核不会调用几何参数相关函数，也就不会破坏用户刚刚写入的数据。

[ 本帖最后由 不点 于 2011-10-14 17:53 编辑 ]

hotdll

原帖由 chenall 于 2010-12-17 00:13 发表


没关系,我已经找到原因了,只是还没有编译上传.

正在修改批处理执行的函数.

以后可以直接在外部命令中调用批处理的CALL/goto 标签.

之前的版本只能调用GOTO,调用CALL会失败.

这样可以配合WENV的 ...

C大，10月9日版本，WENV 的CALL调用CALL命令会提示错误。

例如 WENV FOR /F %I IN ( ()/TESET.TXT ) do call call command1

9月28日版本正常。

[ 本帖最后由 hotdll 于 2011-10-15 17:49 编辑 ]

chenall

哪里不正常？

什么错误？哪里的错误？

幸运的草

G4D中文版的内置fontfile命令，是不是不支持小字库？我生成的小字库，用外部命令fontfile加载，无论中文还是英文版，都能正常显示。但用中文版的内置命令fontfile加载却不行？但加载HZK16大字库可以。

图一为中文内置命令fontfile加载小字库后的效果。

图二为外置命令加载小字库后的效果。

chenall

内置的fontfile是不支持小字库，小字库只是用于测试的。

[ 本帖最后由 chenall 于 2011-10-16 17:39 编辑 ]

hhh333

不点老大，能不能够让wee支持光盘文件系统？
这个需求主要是用bootmgr来启动时，不能直接调用grldr，必须通过调用grldr.mbr再调用grldr；而从光盘启动时通过这个grldr.mbr也不灵了，必须另外做一个grldr.mbr，我目前是用mkiso打包成grldr启动再导出引导文件来代替这个grldr.mbr，反正都不很理想。于是想到用wee，因为它可以被bootmgr直接调用的；而且grldr.mbr是不支持子目录的，而wee是支持的。

不点

hhh333，这问题也许能够做到，但那可不是说一蹴而就马上就完成了。有几个人需要这功能？又有几个人来开发？

不如这样，你给微软写一封信，要求它的 bootmgr “更上一层楼”，不要只加载 64K 的文件，而是要加载 512K 的文件。如此一来，bootmgr 加载整个的 grldr 就不成问题了。

不要以为微软不会采纳意见。只要是合理的意见，微软都有可能采纳。微软做这样的改动，那是轻而易举的事。如果你的意见提得早，说不定 win8 就可以赶上支持了。