无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站广告联系 微信:wuyouceo QQ:184822951
楼主: zhaohj
打印 上一主题 下一主题

GRUB4DOS更新建议、bug反馈专帖

    [复制链接]
2191#
发表于 2011-12-31 18:11:32 | 只看该作者
背景图片bmp是用什么软件压缩为lzma格式?
我用7zip选择压缩方法lzma然后改名(*.lzma与*.bmp都一样),启动时菜单会变乱码。试过用其它不是bmp图像的文件改为背景图片文件名启动,菜单中文也会变成乱码,如果不存在背景图片文件,正常显示中文,只是背景为黑色。

[ 本帖最后由 joy7501 于 2011-12-31 18:13 编辑 ]
回复

使用道具 举报

2192#
发表于 2011-12-31 19:12:06 | 只看该作者

回复 #2195 joy7501 的帖子

用7zip选择压缩方法gzip即可。
回复

使用道具 举报

2193#
发表于 2011-12-31 19:26:17 | 只看该作者

回复 #2196 2011phzhc 的帖子

gz压缩的可以改扩展名为BMP或GZ扩展名;LZMA压缩的,必须是LZMA扩展名,否则加载失败!
回复

使用道具 举报

2194#
发表于 2011-12-31 20:49:56 | 只看该作者

回复 #2195 joy7501 的帖子

在网上找了一下,直接用7z压缩是不行的。可以到7zip官网去下载lzma扩展工具包,里面有个lzma.exe命令行压缩工具,可以用来压缩为lzma格式,lzma是linux上常用的压缩格式。
lzma.ex的用法:
压缩: lzma e 源文件 目的文件
解压: lzma d 源文件 目的文件

例将blue.bmp压缩为bg.lzma,在命令行下输入:lzma e blue.bmp bg.lzma
将bg.lzma解压为blue.bmp,在命令行下输入:lzma d bg.lzma blue.bmp

lzma的压缩率比gzip要高

[ 本帖最后由 joy7501 于 2011-12-31 21:16 编辑 ]

lzma.7z

39.89 KB, 下载次数: 35, 下载积分: 无忧币 -2

回复

使用道具 举报

2195#
发表于 2011-12-31 22:48:52 | 只看该作者

回复 #2194 chenall 的帖子

确实疏忽了,UD中的没更新,只更新到了可见区,对不起了!
回复

使用道具 举报

2196#
发表于 2011-12-31 22:52:01 | 只看该作者
有没有对JPEG/PNG等比较熟悉的?可以开发一个GRUB4DOS的外部命令用于加载JPEG/PNG的图片。

我个人精力有限,还没有时间去研究这些。

接口部份已经有了,只需要把图片数据解压后放到指定位置就可以了。
回复

使用道具 举报

2197#
发表于 2011-12-31 22:52:35 | 只看该作者

回复 #2199 hhh333 的帖子

呵呵,事情一多,难免会有疏忽,我也经常犯错。。
回复

使用道具 举报

2198#
发表于 2012-1-1 08:24:18 | 只看该作者

回复 #2195 joy7501 的帖子

fbt本身就带有。选工具项。
回复

使用道具 举报

2199#
发表于 2012-1-1 15:33:13 | 只看该作者

回复 #2200 chenall 的帖子

我认为菜单背景图等界面设置的东西均可以用外部命令,grldr只关注启动有关的事及为外部命令提供接口。
回复

使用道具 举报

2200#
发表于 2012-1-1 18:03:52 | 只看该作者

回复 #2203 hhh333 的帖子

嗯,目前就是这样子的,内核尽量使用提供一些接口,其它的操作交给外部命令去实现。
回复

使用道具 举报

2201#
发表于 2012-1-1 20:21:01 | 只看该作者

回复 #2204 chenall 的帖子

最新0.46a好象不能用前2kb来做CD引导文件了,怎么办?
回复

使用道具 举报

2202#
发表于 2012-1-1 20:24:11 | 只看该作者

回复 #2205 hhh333 的帖子

到这里报告关于0.4.6a的问题。。

http://bbs.znpc.net/viewthread.php?tid=6176&extra=page%3D1

另外可以先试试yaya发布的版本看看是否有一样的问题,因为有可能因为编译环境 不一样。

[ 本帖最后由 chenall 于 2012-1-1 20:25 编辑 ]
回复

使用道具 举报

2203#
发表于 2012-1-1 23:50:26 | 只看该作者
原帖由 zhaohj 于 2011-12-31 11:36 发表
边框颜色:
color border=**
初始化时的屏显信息我不知你讲的哪些?如果是内部命令或外部命令产生可用 > nul ,来消除屏幕输出。



比如上图,通常作为用户是不需要看到这些信息的,只有调试时才需要看下。试了下加上> nul照样有屏幕输出呀
回复

使用道具 举报

2204#
发表于 2012-1-2 00:53:42 | 只看该作者
使用了如下语句加载字库和640*480分辨率的背景图,当只支持640*480时,背景图显示正常;但当支持800*600分辨率时,就不太正常了:一是右边屏幕会平铺一部分背景图的左边部分,但是屏幕下面背景图覆盖不到的地方,比如提示行等,不会出现色斑将提示信息挡住,更不要说美观了。因此如果背景图小于屏幕分辨率时,能否拉伸背景图填满屏幕?至于大于屏幕分辨率的背景图,也建议缩小以适应屏幕。

graphicsmode -1 640:800 480:600 24:32
font /GRUB/U51.LZMA
splashimage /GRUB/XL_LOTUS.LZMA
回复

使用道具 举报

2205#
发表于 2012-1-2 00:54:31 | 只看该作者

回复 #2207 lafter 的帖子

你的写法有错误吧,不可以有多余的空格,也不要少空格。
">" 前后至少有一个空格。
回复

使用道具 举报

2206#
发表于 2012-1-2 00:56:59 | 只看该作者

回复 #2208 xianglang 的帖子

没有处理图像缩放。所以一般情况下建议挑选合适的背景图片使用适用的分辨率。。

使用BMP格式可以自动检测适合的。XPM,一般建议是640X480.
回复

使用道具 举报

2207#
发表于 2012-1-2 01:28:54 | 只看该作者
原帖由 chenall 于 2012-1-2 00:56 发表 没有处理图像缩放。所以一般情况下建议挑选合适的背景图片使用适用的分辨率。。使用BMP格式可以自动检测适合的。XPM,一般建议是640X480.
上面那个> nul还真没加空格,按DOS的来了.关于背景,可否这样:设定1~N幅,在设定的分辨率范围内依次检测第1~N个背景是否可用.到第一次栏测成功为止停止自动检测。当然,如果此法可行,需要同时使某一变量返回1~N,以使用户在判断采用哪幅背景后能选择相应的菜单.
回复

使用道具 举报

2208#
发表于 2012-1-2 09:24:50 | 只看该作者
我昨夜换了2012-1-1- 的版本,今天开机也是WEE启动不了GRLDR,好在可以启动BOOTIMG,要不就得用U盘启动了——看来我要试新版,还是只能在虚拟机中,而不有用在实机里。
回复

使用道具 举报

2209#
发表于 2012-1-2 13:02:12 | 只看该作者
ls显示文件名还是不能出中文:30号和1号的版本都是这样的。

XX.PNG (5.62 KB, 下载次数: 189)

XX.PNG
回复

使用道具 举报

2210#
发表于 2012-1-2 13:07:15 | 只看该作者

回复 #2213 hhh333 的帖子

你这是光盘的吧,光盘因为不支持UTF-8文件名,所以是不行的。
回复

使用道具 举报

2211#
 楼主| 发表于 2012-1-2 13:08:28 | 只看该作者
新版本是否考虑重新设置一下界面?
1:版本信息(头信息),这个内核中是固定的,可以考虑一个内存变量控制;
2:帮助信息,这个是根据菜单状态动态变化的,目前位置是相对固定的。
我的设想:
    去掉原来的帮助信息,原帮助信息由热键控制,不按热键不弹出信息(再按热键隐藏)
    新的帮助信息(只实时生成菜单的帮助信息),也是一个结构体(struct):help_broad
struct hep_broder {
        unsigned char disp_ul;
        unsigned char disp_ur;
        unsigned char disp_ll;
        unsigned char disp_lr;
        unsigned char disp_horiz;
        unsigned char help_box_x;
        unsigned char help_box_w;
        unsigned char help_box_y;
        unsigned char help_box_h;
        unsigned char help_box_b;
        unsigned char help_border_w;
} __attribute__ ((packed));

默认情况下:
help_box_x = menu_box_x;
help_box_w = menu_box_w;
help_box_y = menu_box_y+menu_box_h;
hep_box_b= current_term->max_lines -1;
help_border_w = border_w;
...
回复

使用道具 举报

2212#
发表于 2012-1-2 13:36:32 | 只看该作者

回复 #2215 zhaohj 的帖子

这些在0.4.5的版本不考虑。。。。

你已经有编译环境了,可以自己尝试修改一下。自己尝试去实现,这也是一个很好的学习机会。
回复

使用道具 举报

2213#
发表于 2012-1-2 14:07:33 | 只看该作者

回复 #2213 hhh333 的帖子

你的图片显示的是 GB 码的文件名。这表明,你的光盘的中文文件名不是 UTF8 的,而是 GB 码的。

光盘上的文件名,既然可以弄成 GB 码的,就一定也可以弄成 UTF8 的。找找 mkisofs 的选项,我猜应该有支持 UTF8 文件名的选项的。

[ 本帖最后由 不点 于 2012-1-2 17:10 编辑 ]
回复

使用道具 举报

2214#
发表于 2012-1-2 15:05:50 | 只看该作者
我还没有找到一款制作ISO的工作可以使用UTF-8编码的。。。
回复

使用道具 举报

2215#
发表于 2012-1-2 15:36:40 | 只看该作者

回复 #2218 chenall 的帖子

同感,而且标准iso9660好像还不允许文件名含有空格
回复

使用道具 举报

2216#
发表于 2012-1-2 17:07:04 | 只看该作者
空格先不说,utf8 是肯定可以做到的。

我在 Linux 下创建中文文件名。默认是采用当前环境检测到的 utf8。mkisofs 直接创建的就是 utf8 格式的文件名。

在 Windows 下应该也没问题:mkisofs 有参数

-input-charset CHARSET      Local input charset for file name conversion

-output-charset CHARSET     Output charset for file name conversion

我猜,Windows 下的 mkisofs 也有这些参数。如果不支持这些参数,那么,转到 Linux 做,肯定没问题。

如果支持的话,在 Windows 下,-input-charset 应该是 GB2312 或者 GB18030 之类的。-output-charset 当然应该是 utf-8 了。估计 -input-charset 不用设置,而只需设置 -output-charset utf-8 便可。
回复

使用道具 举报

2217#
发表于 2012-1-2 17:13:30 | 只看该作者

回复 #2220 不点 的帖子

linux有支持,但WINDOWS好像不支持,还是缺少了什么文件。

Unknown charset
Known charsets are:
cp10081
cp10079
cp10029
cp10007
cp10006
cp10000
koi8-r
cp1250
cp874
cp869
cp866
cp865
cp864
cp863
cp862
cp861
cp860
cp857
cp855
cp852
cp850
cp775
cp737
cp437
iso8859-15
iso8859-14
iso8859-9
iso8859-8
iso8859-7
iso8859-6
iso8859-5
iso8859-4
iso8859-3
iso8859-2
iso8859-1
回复

使用道具 举报

2218#
发表于 2012-1-2 17:23:58 | 只看该作者
那就不知道了。弄个最新版的 mkisofs 看看。
回复

使用道具 举报

2219#
发表于 2012-1-3 10:45:14 | 只看该作者
更新了一下hotkey,并添加了一个使用用说明页面。

http://code.google.com/p/grubutils/wiki/Hotkey
回复

使用道具 举报

2220#
发表于 2012-1-3 10:50:27 | 只看该作者

回复 #2223 chenall 的帖子

谢谢C大更新,这样好多了。。。

至少菜单方便很多了
回复

使用道具 举报

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

本版积分规则

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

闽公网安备 35020302032614号

GMT+8, 2024-6-29 04:51

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

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