无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站投放广告、加入VIP会员,请联系 微信:wuyouceo
楼主: zhaohj
打印 上一主题 下一主题

GRUB4DOS更新建议、bug反馈专帖

    [复制链接]
811#
发表于 2011-5-1 15:01:34 | 只看该作者
抽空更新了,麻烦再试试看有没有其它问题.
回复

使用道具 举报

812#
发表于 2011-5-1 15:16:39 | 只看该作者

回复 #815 chenall 的帖子

谢谢,测试OK。..
回复

使用道具 举报

813#
发表于 2011-5-1 19:41:21 | 只看该作者

find不到当前cd设备了?

                                      

findold.png (6 KB, 下载次数: 151)

findold.png

findnew.png (6.21 KB, 下载次数: 145)

findnew.png
回复

使用道具 举报

814#
发表于 2011-5-1 19:47:47 | 只看该作者

回复 #817 pseudo 的帖子

我的没有问题。
...

新版find或许把(hd96)也屏蔽了?

[ 本帖最后由 zxw 于 2011-5-1 19:55 编辑 ]
回复

使用道具 举报

815#
发表于 2011-5-1 20:09:03 | 只看该作者
试了没有发现问题??

你看看(cd)的设备号是多少.

新版的find改动只影响硬盘设备对CD没有影响.

也许是其它BUG?

有cd设备没有理由找不到的.

[ 本帖最后由 chenall 于 2011-5-1 20:11 编辑 ]
回复

使用道具 举报

816#
发表于 2011-5-1 20:14:36 | 只看该作者
我的结果和p大结果相同  找不到文件



新情况  截图是正常情况  27号版本正常  之后的所有版本都没有(cd)设备





[ 本帖最后由 sratlf 于 2011-5-1 20:24 编辑 ]
回复

使用道具 举报

817#
发表于 2011-5-1 20:34:22 | 只看该作者
建议find处理硬盘设备范围:0x80~0x97
回复

使用道具 举报

818#
发表于 2011-5-1 20:35:16 | 只看该作者
哦,看到上面的贴图我明白了.

不知是要算BUG,还是什么?

你们用的是什么虚拟机呀?CD设备是0x9f

而在find的定义中0x9f是属于硬盘的.所以才会这样..

你们用旧版的如果用以下命令来查找应该也是找不到的.甚至之前最早不支持(hdx)的版本也是找不到的.
find --devices=c /XXX

对一些我不是很清楚,CD设备可能的值到底是什么?0-0xff都有可能吗?还是..
回复

使用道具 举报

819#
发表于 2011-5-1 20:42:05 | 只看该作者
结合扇区大小、前一个设备号是否存在来判断,看是否可靠?

[ 本帖最后由 zxw 于 2011-5-1 20:53 编辑 ]
回复

使用道具 举报

820#
发表于 2011-5-1 20:45:11 | 只看该作者
对cd处理了一下,应该正常了.

传上来试一下.

grldr.rar

127.5 KB, 下载次数: 13, 下载积分: 无忧币 -2

回复

使用道具 举报

821#
发表于 2011-5-1 20:47:51 | 只看该作者

回复 #822 chenall 的帖子

虚拟用一只在用vmware workstation  cd设备号一直是0x9f(从6.5至目前的7.1)

实机usb-cdrom测试没准  以前测试过  在我机子上是0x9f  其他人的机子上是其他的

824#附件测试正常  0x9f的

[ 本帖最后由 sratlf 于 2011-5-1 20:49 编辑 ]
回复

使用道具 举报

822#
发表于 2011-5-1 22:46:37 | 只看该作者
@chenall:
最近的版本对"|"有限制了么?5个扇区则无事。


[ 本帖最后由 zxw 于 2011-5-1 22:47 编辑 ]
回复

使用道具 举报

823#
发表于 2011-5-1 22:51:12 | 只看该作者
自从支持输出转向开始就有进行限制了.并不是新版的问题

不能大于3K字节. >=0xc00就会提示这个错误的.
回复

使用道具 举报

824#
发表于 2011-5-1 22:54:37 | 只看该作者

回复 #827 chenall 的帖子

我记得以前的版本大概3月份就没有这个限制吧。我追踪一下。
回复

使用道具 举报

825#
发表于 2011-5-1 22:57:52 | 只看该作者
这个就没有必要追究了吧,

没事非要这样子转?
回复

使用道具 举报

826#
发表于 2011-5-1 23:06:18 | 只看该作者

回复 #829 chenall 的帖子

测试了一下,确实一直有这个限制。
嘿嘿,我的神啊,都是你的错。你那个脚本没事写那么大干什么?我就稀里糊涂地照搬了。^_^
http://bbs.znpc.net/viewthread.php?tid=6025&page=1&fromuid=14541#pid46861

[ 本帖最后由 zxw 于 2011-5-1 23:14 编辑 ]
回复

使用道具 举报

827#
发表于 2011-5-1 23:20:43 | 只看该作者
嘿嘿,不好意思,又向你提要求了。以前也提出过。

就是将\b如同\t、\n等特殊处理一下。
回复

使用道具 举报

828#
发表于 2011-5-2 00:01:54 | 只看该作者
报歉,也许我最近脑袋瓜有一点老化了.

我又看不懂了.最近碰到好多次了,没能反应过来.
回复

使用道具 举报

829#
发表于 2011-5-2 00:14:21 | 只看该作者

回复 #832 chenall 的帖子

不好意思,你事多,也记不得这么多。
是这样,我需要\b(左移一位光标,覆盖的是非显示字体)以控制字符显示。
所以需要如同\t、\n等字符在加载unicode字体后的特殊处理,而不是显示那个乱码。


还是算了,c大忽略吧。方法多。

[ 本帖最后由 zxw 于 2011-5-2 03:47 编辑 ]
回复

使用道具 举报

830#
发表于 2011-5-3 18:40:08 | 只看该作者
@chenall:
在加载unicode字体时,汉字的显示长度和实际长度是不同的。
对于一个字符串,我目前是用批处理,按照根据UTF8的规则,循环判断是否汉字来计算的。

如何快速获取显示长度?如无,可否考虑增加这方面的功能?

[ 本帖最后由 zxw 于 2011-5-3 18:48 编辑 ]
回复

使用道具 举报

831#
发表于 2011-5-4 10:12:08 | 只看该作者
目前无解,UNICODE显示的字体是完全由UNIFONT控制的.

即使是GRUB4DOS内部也没有办法处理.

你可以考虑自己写一个小程序,首先获取当前光标位置,显示完后再读取一下光标位置,两个位置之间的距离就是总长度了.

C语言的话,获取fontx/fonty变量的值就行了.
比如未显示之前读一次存为fontx1,fonty1
显示之后读一次存为fontx2,fonty2
如果fonty2不等于fonty1则已经跳行了.
fontx2-fontx1就是显示的长度.

另外如果不想写外部命令,直接用批处理也是可以获取fontx/fonty的值的.

根据GRUB4DOS.H的定义.
#define fontx ((*(int **)0x8304)[26])
#define fonty ((*(int **)0x8304)[27])

所以fontx的值获取方法如下
set /a fontx=26<<2+*0x8304
set /a fontx1=*%fontx%&0xffffffff
fonty类似,
再给你一个测试的批处理.
set /a fontx=26<<2+*0x8304
echo -n 1234567890 && read %fontx%
会得到0xa即10个字符.
注:如果没有加-n则读到的是0,因为回车后就是在下一行的起始位置了.
回复

使用道具 举报

832#
发表于 2011-5-4 21:36:06 | 只看该作者
<font size="6">建议:GRUB4DOS在加载比较大的IMG镜像文件时(比如加载内存操作系统RAMXP.img)做一个简单的进度条或百分数来显示加载进度,&lt;br /&gt;因为加载过程有时会有1-3分钟左右,如果这台电脑只是自己用,自己会耐心等待,如果是多个人共同使用,很多人在加载镜像的过程中等得不耐烦,就直接按RESET重启动了,有的人还以为是电脑死机了。就是这条命令:map --mem /ramos.img (hd0)最好是能提升GRUB在DOS下的镜像文件加载速度</font>

多谢版主sratlf的提示,换了新版本的一试,果然OK。

[ 本帖最后由 2011masm 于 2011-5-6 12:39 编辑 ]
回复

使用道具 举报

833#
发表于 2011-5-4 22:01:37 | 只看该作者

回复 #836 2011masm 的帖子

新版grub4dos早就实现了
回复

使用道具 举报

834#
发表于 2011-5-6 11:47:49 | 只看该作者
借一個好位置,提交了支持載入 ReactOS freeldr.sys 的補丁:
http://code.google.com/p/grub4dos-chenall/issues/detail?id=24
回复

使用道具 举报

835#
发表于 2011-5-6 14:11:49 | 只看该作者
直接打上补丁,并上传了,没有其它改变,未测试。
回复

使用道具 举报

836#
发表于 2011-5-7 14:25:00 | 只看该作者
我又來了。這回是支持加載 DELL DRMK DELLBIO.BIN 的補丁:
http://code.google.com/p/grub4dos-chenall/issues/detail?id=25

HMA_start 中有正確設定 %ebp 為 0x7c00 了,已測試 EDR-DOS/FreeDOS/MS-DOS 7.1/ROM-DOS 沒發現問題。
回复

使用道具 举报

837#
发表于 2011-5-7 19:51:49 | 只看该作者
OK,直接打上补丁了。
最近GOOGLE帐号登不上,改天再把你的帐号加进去,以后你也可以帮忙维护。
^_^
回复

使用道具 举报

838#
发表于 2011-5-8 00:10:00 | 只看该作者

回复 #835 chenall 的帖子

谢谢热心回复,这几天出差。马上试用。
回复

使用道具 举报

839#
发表于 2011-5-8 13:53:54 | 只看该作者
原帖由 chenall 于 2011-5-4 10:12 发表
另外如果不想写外部命令,直接用批处理也是可以获取fontx/fonty的值的.

根据GRUB4DOS.H的定义.
#define fontx ((*(int **)0x8304)[26])
#define fonty ((*(int **)0x8304)[27])

所以fontx的值获取方法如下
set /a fontx=26<<2+*0x8304
set /a fontx1=*%fontx%&0xffffffff
fonty类似,
再给你一个测试的批处理.
set /a fontx=26<<2+*0x8304
echo -n 1234567890 && read %fontx%
会得到0xa即10个字符.
注:如果没有加-n则读到的是0,因为回车后就是在下一行的起始位置了.

c大,测试不成功。fontx的值没有变化。
回复

使用道具 举报

840#
发表于 2011-5-8 14:54:14 | 只看该作者
正常的fontx的值只是一个内存地址,是固定的.

你需要再读取一下这个内存地址的值就行了.

我上面只是为了测试直接使用read %fontx%读,你可以用
set /a x1=*%fontx%&0xff
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1 )

闽公网安备 35020302032614号

GMT+8, 2024-11-24 05:38

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表