增强 GRUB4DOS 菜单编辑功能，支持动画，支持精简字库，支持图形菜单

jianliulin · 发表于 2015-8-17 08:10:35

不点发表于 2015-8-17 02:32
大家都谈了看法。我也说说我的观点。观点就是观点，不要拘泥于观点，不要太注重某个人的观点。开发者应该以 ...

如果移植成功了，是否意味着grub4dos离uefi启动就不远了。

不点 · 发表于 2015-8-17 08:55:43

如果只是由我来做这些工作，肯定与 EFI 无关。我所提到的上述工作，就够我做一辈子了。

假如也有其他人参与，那就有可能增加 EFI 的支持。

2011yaya2007777 · 发表于 2015-8-17 13:49:44

我很愿意协助不点做此项开发.

yifeimfd · 发表于 2015-8-17 14:15:21

一楼附件引导时停在加载内置菜单处就不动了。下载的是15年8月14日版。下载8月7日版使用就没有问题。

不点 · 发表于 2015-8-17 15:28:53

本帖最后由不点于 2015-8-17 18:54 编辑

2011yaya2007777 发表于 2015-8-17 13:49
我很愿意协助不点做此项开发.

太好了，如此一来，进度就会加快一倍。

我已经在做的工作是把硬盘、键盘驱动引进来，让 grub4dos 的内核不再需要反复调用 int13 和 int16。

如果快的话，下个月就可能投入 alpha 测试。

yaya 可以根据自己的特长，选择某个领域的工作来做。

初步计划：准备为 grub4dos 的内核至少保留 256M 的内存空间，这样不至于很快用光。256M 是 grub4dos 内核的最小内存占用。不支持很低档的旧机器。
机器总内存应该至少有 1G。低档机器只能使用现在的版本。建议有 8G 以上的内存，以便加载很大的 IMG、VHD。

另外，我们仍以现在的版本为主要发行版本。新的版本主要只用于新的机器。新版本有可能缺少兼容性（需要长期锤炼以后才能作为主要版本），因此，我们仍然以目前的版本为主。

进程管理和内存管理是关键，目前我还没有自己的思路，唯一的思路就是从 grub2 以及别的操作系统移植相关的功能。

我对中断描述符表还算有点了解。将来实现的系统调用，应该可以兼容 Linux。就是说，在支持运行 16 位 DOS 程序的同时，也支持运行 32 位（甚至也支持 64 位）的 Linux 程序。

2011yaya2007777 · 发表于 2015-8-17 18:22:47

一楼附件引导时停在加载内置菜单处就不动了。

把菜单贴上来.

2011yaya2007777 · 发表于 2015-8-17 18:40:45

需要澄清一个概念。
字库本来就是外置的。无论是从菜单使用命令 font /unifont.hex.gz 显式加载，还是从菜单末尾以小字库的方式隐式加载。
小字库方式缩小了外置字库的体积，但是没有减少字库在内存的体积。
比如，小字库加载 2 个字：0x41 和 0x5940。以 32*32 点阵字符为例，内核把 0x41 存放在 0x41*0x80 处，把 0x5940 存放在 0x5940*0x80 处。似乎 2 字节应当占用 0x80*2 字节，实际结果却不是。
看来需要建立 1 种小字库存储模式，将 0x41 放在 0*0x80 处，将 0x5940 放在 1*0x80 处，等等。这并不难实现。

不点 · 发表于 2015-8-17 18:59:46

2011yaya2007777 发表于 2015-8-17 18:40
需要澄清一个概念。
字库本来就是外置的。无论是从菜单使用命令 font /unifont.hex.gz 显式加载，还是从 ...

目前的 32M 内核内存，不够使用。需要加大内核内存才行。

如果不增加内核内存占用，你可以暂时只支持 32×32 的字库，把 chenall 的 insmod 模块移动到别的地方。

或者干脆把保留内存增加到 64M 或 128M，这样会给第三方应用的开发者带来某些不兼容现象。

总之，你自己决断吧。

yifeimfd · 发表于 2015-8-17 21:00:56

本帖最后由 yifeimfd 于 2015-8-17 21:06 编辑

2011yaya2007777 发表于 2015-8-17 18:22
把菜单贴上来.

# This is a sample menu.lst file. You should make some changes to it.
# The old install method of booting via the stage-files has been removed.
# Please install GRLDR boot strap code to MBR with the bootlace.com
# utility under DOS/Win9x or Linux.

find --set-root /grub/grubflag
graphicsmode -1 600:800
#font /grub/font/GB2312.gz
#黑体
font /grub/font/ht.gz
#仿宋
#font /grub/font/fs.gz

splashimage /grub/background/think.bmp

#foreground ffff00
#color black/cyan yellow/cyan

timeout 10
parttype 0x07

title 启动windows
parttype 0x12
find --set-root /Windows/win.ini
chainloader +1

title 启动联想一键恢复
parttype 0x12
chainloader +1

title 新二合一PE(ISO)
map --mem /grub/FIRADISK.IMG (fd0)
map --mem /grub/boot/PE5.1/WinPE_5.1_32&64_4.26.iso (0xff)
map --hook
chainloader (0xff)

title 启动绝对PE(ISO)
map --mem /grub/boot/AbsolutePE.iso (0xff)
map --hook
chainloader (0xff)

title 二合一PE(ISO)
map --mem /grub/FIRADISK.IMG (fd0)
map --mem /grub/boot/WIN7PE.ISO (0xff)
map --hook
chainloader (0xff)

title 启动memtest86+(ISO)
map --mem /grub/memtest86+-5.01.iso (0xff)
map --hook
chainloader (0xff)

title 重启
savedefault --wait=2
reboot

title 关机
savedefault --wait=2
halt

同样这个配置文件，下载8月7日版的工作正常，换一楼附件8月14日版的就不正常，屏幕卡在“GRUB4DOS 0.4.6a 2015-08-14, root is (0x80,0) processing the preset-menu ...”，U盘启动。

谢谢您抽空回复~

刚刚换为硬盘启动有一样问题，

yifeimfd · 发表于 2015-8-17 21:18:19

另外，刚刚还测试了使用三楼提供的菜单，只是改了图片和字体文件配置项（这两个应该没问题，因为8月7日版可以正常使用），启动的时候故障依旧。

2011yaya2007777 · 发表于 2015-8-18 07:18:19

ht.gz 是什么字库？16*16？请上传。

yifeimfd · 发表于 2015-8-18 09:34:03

本帖最后由 yifeimfd 于 2015-8-18 09:53 编辑

2011yaya2007777 发表于 2015-8-18 07:18
ht.gz 是什么字库？16*16？请上传。

论坛这个帖子中下的黑体字库：
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=256198

黑体.part01.rar~黑体.part04.rar

************************************
刚刚将字体文件换成https://code.google.com/p/grub4d ... name=unifont.hex.gz下载的，故障依旧~

yifeimfd · 发表于 2015-8-18 10:28:03

本帖最后由 yifeimfd 于 2015-8-18 16:21 编辑

甚至测试了将配置中的背景都去掉也是一样。二楼那个菜单在8月7号版本的grldr下完全正常，一旦改为8月14日的就有问题。
E:\os\bootloader\src\grldr_2015_08_14>fciv -sha1 grldr
//
// File Checksum Integrity Verifier version 2.05.
//
459793b658101c9a45d1f2739d579795827e8aa9 grldr

不知道是不是文件有问题，现附上我本地文件的sha1以供核对。

******************************************

一楼8月17日grldr肯定有问题：（以下测试都是在virtualbox中进行的。）
menu.lst只有下面简单3行都遇到同样的问题
title windows
find --set-root /Windows/win.ini
chainloader +1

文件确认是utf-8编码。用winhex删除BOM也一样问题。

为了测试方便，我菜单加载时在命令行下进行的，输入命令后grub命令行即冻结，用CTRL+ALT+DEL可以重启虚拟机。

不点 · 发表于 2015-8-18 18:32:28

本帖最后由不点于 2015-8-18 18:44 编辑

又考虑了一下，觉得不要急于把整个 grub4dos 都隐藏在扩展内存顶部。可以分步骤、逐步实现。

先把 int13 代码隐藏于扩展内存顶端。主体的 grub4dos 内核仍旧在低端运行。待到以后时机成熟时，再把主体内核移动到扩展内存顶端。

目前来说，内存管理是关键。其次是进程管理。

内存管理并不难，但它是个细致活。昨天看了 grub2 的内存管理代码的注释说明，了解到 grub2 的内存管理类似于 DOS 的内存管理，是用链接表来实现内存链的。而 grub4dos 目前是用数组来管理。

我仔细考虑了两天，觉得还是数组管理更合适一些。链接表的头部占用 16 字节（或 32 字节），这不利于分配那些（例如按照扇区对齐的）内存。而数组就不存在头部，所分配到的内存是干净的，因此更有利于分配按照扇区或页面对齐的内存。那些头部的 16 字节（或 32 字节）其实是个浪费，而且更糟糕的是，它影响了所分配的内存的 “对齐性”。因此，得到的结论是，内存分配适合于用数组，不适合于用链接表。

举例来说，假如要分配 4K 内存，并且按照 4K 对齐。假定空闲空间的初始状态就是 4K 对齐的。如果用链接表，那么内存块的头部占用 16 字节，因此需要 8K 的空间才能满足 4K 对齐的要求。头部的 16 字节严重干扰了实际分配到的内存块的对齐性。

关于进程管理，觉得照样应该以简单为主要参考点。用户进程使用用户内存。内核和内核模块使用内核内存。

目前的用户进程管理模式可以继续沿用。内核的保留空间应该加大。折中一下，觉得保留 128M 给内核以及内核模块，差不多也就够用了。

内核模块的逻辑结构是由 chenall 设计的。chenall 负责有关的事宜（保证它能正常运转）。

所以，唯一需要解决的问题，便是编写 kmalloc 和 kfree 函数了。

我初步设计，0～32M 保持目前的使用状况不变。32 ～ 64M 的 32M 空间用于字体字模。64～128M 的 64M 空间用于内核的 kmalloc 分配内存。kmalloc 分配内存时，应该从顶端向下分配（就好像是堆栈那样）。因此这 64M 中的高端部分是 kmalloc 内存，而低端部分也可以被 insmod 或别的内核代码（或内核数据）占据，只要保证高端和低端不发生重叠便可。

另外想补充说明的是，既然 yaya 已经开始整理菜单界面，那么，继续支持 gfxmenu 已经没有意义了。所以新版本可以撤销对 gfxmenu 的支持。要知道，gfxmenu 占据了很大的内存开销，4M 和 6M 处各有 1M 都被保留给 gfxmenu。如果去除 gfxmenu 支持，则可以腾出宝贵的 2M 空间，供别的内核数据结构使用。

2011yaya2007777 · 发表于 2015-8-18 21:24:45

本帖最后由 2011yaya2007777 于 2015-8-19 07:10 编辑

赞成不点的意见，数组管理内存更合适一些。是不是将来使用内存，无论存续期长段，都要申请内存占用空间？
我觉得 unifont.hex 支持到 48*48，也就是占用 18Mb，应该够了。若支持到 64*64，则需要占用 32Mb。
下次发布时，注释掉 gfxmenu 。

一楼附件引导时停在加载内置菜单处就不动了

1#已经更新。

yifeimfd · 发表于 2015-8-18 22:17:58

2011yaya2007777 发表于 2015-8-18 21:24
赞成不点的意见，数组管理内存更合适一些。是不是将来使用内存，无论存续期长段，都要申请内存占用空间？
...

8月18日更新已经正常了，谢谢！

不点 · 发表于 2015-8-19 07:13:27

是不是将来使用内存，无论存续期长短，都要申请内存占用空间？

正相反，我不建议频繁使用 kmalloc 和 kfree。如果一个程序段只需要临时用用一片内存，用完之后马上又 free 掉，那么，我觉得这种情况就不应该使用 kmalloc 和 kfree，而应该使用所谓的“公共临时变量区”。

比如说，我们事先开辟一个固定的 8M 空间，这个空间，任何程序都可以写入。使用这个空间，无需申请。既然无需申请，也就无需释放。我估计很多使用 kmalloc 和 kfree 的情况，都可以改成使用“公共临时变量区”。

对 kmalloc 和 kfree 的使用次数，肯定是越少越好。能避免就应该尽量避免使用它们。如果使用了 kmalloc 而忘了使用 kfree，还可导致内存占用过多的问题，糟糕的是，这可能是个隐蔽的问题，不容易及时发现。

我觉得 unifont.hex 支持到 48*48，也就是占用 12Mb，足够了。

你觉得 32M 的内核空间，够不够用？是否需要加大内核保留内存量？我觉得如果考虑到将来的扩展，比如（有可能用 insmod 等方式）添加 usb 支持模块、网络支持模块、文件系统支持模块、键盘鼠标支持模块、显卡、声卡、硬盘的支持，等等，还是需要加大内核保留空间的。

所以我想，这一次就直接将内核保留空间加大到 128M，这就有足够的空间可以同时开辟“公共临时变量区”和 kmalloc 内存分配区，方便程序员的使用。程序员爱用哪种内存使用方式，就用哪种；很自由，很解放。

UC11779470 · 发表于 2015-8-19 10:31:12

chenall 发表于 2015-7-9 21:43
太赞了,支持一下先...

为什么还没有更新到官网？

yifeimfd · 发表于 2015-8-19 10:35:35

UC11779470 发表于 2015-8-19 10:31
为什么还没有更新到官网？

估计还在bug排查。

不点 · 发表于 2015-8-19 14:19:44

我把有关 ahci 硬盘和键盘测试的版本上载到时空论坛 grub4dos 区了。有兴趣者可下载测试。

时空论坛网址是： http://bbs.znpc.net/

2011yaya2007777 · 发表于 2015-8-20 13:36:13

本帖最后由 2011yaya2007777 于 2015-8-21 10:51 编辑

从硬盘启动,依旧.

不点 · 发表于 2015-8-20 20:36:58

2011yaya2007777 发表于 2015-8-20 13:36
从硬盘启动,依旧.

测试文件已更新，请再测试。

alex20092009 · 发表于 2015-8-22 17:33:31

请问color normal=0xff9933 highlight=0xff3300 helptext=0xff00ff heading=0x66ff00 border=0x006699, 是否有数字和颜色对照表,

李泽勇 · 发表于 2015-8-22 18:12:41

谢谢楼主，学习了。

2011yaya2007777 · 发表于 2015-8-22 18:34:34

请问color normal=0xff9933 highlight=0xff3300 helptext=0xff00ff heading=0x66ff00 border=0x006699, 是否有数字和颜色对照表,

echo -rrggbb

ali88home · 发表于 2015-8-24 17:51:01

大大最新版本已经制作好了，俺下载测试20150821版本情形，ok，谢谢！

2011yaya2007777 · 发表于 2015-9-2 08:12:51

昨天上传的版本，官网没有自动编译发布，不知何故。

2011yaya2007777 · 发表于 2015-9-7 17:55:01

我上传到 https://github.com/yaya2007/grub4dos 的补丁，不能同步上传到 https://github.com/chenall/grub4dos/tree/0.4.6a
所以官网没有自动编译发布。请 chenall 帮忙处理一下。

bfgxp · 发表于 2015-9-14 10:03:54

为何我在测试时，每个汉字都只显示了一半呢，除了16*16的正常，其他都只显示一半？

bfgxp · 发表于 2015-9-14 10:09:59

补充，15.8.20可以正常显示，之后的所有版本都试了，汉字都只显示了一半。
我是用的FbinstTool v1.607.2015.0718设置的字体测试。

		自动登录	找回密码
密码			注册

[发布] 增强 GRUB4DOS 菜单编辑功能，支持动画，支持精简字库，支持图形菜单

点评

评分

点评

点评

点评

点评

点评