无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站广告联系 微信:wuyouceo QQ:184822951
查看: 126656|回复: 501

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

    [复制链接]
发表于 2015-7-10 10:12:58 | 显示全部楼层
我提醒一下 yaya,在 http://reboot.pro 上,有人在想办法支持 “从右到左” 写的文字,如阿拉伯语、希伯来语等。

这些语言的特点是,语言字符是从右向左写的,但 UTF8 格式的记事本文件中,依旧是按字节地址增大的顺序来写的。windows 的记事本能够自动按逆序显示这些语言字符。然而 grub4dos 不能自动按逆序来显示这些语言字符。

需要说明的是,这些语言字符本身是逆序的,但其中夹杂的英文单词、ASCII 字符、文件路径,都是正常的顺序,不是逆序的。

假如我们的 grub4dos 要在内核中支持这样的语言文字,需要修改 put_char 之类的函数,让其能够判断出逆序的字符串,并自动用逆序来显示这个字符串。

目前 Steve6375 是在菜单批处理层面做这个工作。其实也够用了。

我的问题是:对于这些逆序的语言,倒计时的秒数在什么地方显示?如果按目前这样处理(在右端显示),则 Steve6375 所做的工作可能就要不适应了(倒计时的秒数会覆盖菜单开头的内容,因为菜单开头是在最右端)。

回复

使用道具 举报

发表于 2015-7-10 12:56:29 | 显示全部楼层
2011yaya2007777 发表于 2015-7-10 11:38
'逆序的语言'是左对齐?还是右对齐?
一个变通方法是:菜单开头是在最右端向左移动 2 列。即菜单项允许 ...

当然是右边对齐了。就像我们港台的电影字幕那样,从右边向左。

其实你不用管了,我想,假如 Steve6375 发现了这个问题,他会生办法解决的。说不定解决的办法就和你说的一样。

另外,菜单自动编号,是 chenall 实现的功能。这在逆序的语言环境下也有问题,因为编号是在最左边,而最左边则相当于菜单行的尾部,很难看。
回复

使用道具 举报

发表于 2015-8-17 02:32:19 | 显示全部楼层
大家都谈了看法。我也说说我的观点。观点就是观点,不要拘泥于观点,不要太注重某个人的观点。开发者应该以自己的判断作为主要参考点。

字体字模占用的空间较大,动辄几十 M,上百M,都是很常见的。什么宋体、楷体、隶属、草书,多了去了。如果都装到内存,占用空间太庞大。所以,我同意楼上所说,用外部命令来实现新的字体。




最近我在研究 grub2,想移植它里面的一些驱动。硬盘驱动和键盘驱动已经有点眉目了,有可能成功移植过来。

如果硬盘驱动移植成功,那么 USB 驱动也应该一样可以移植成功。只是我个人的重点偏向于硬盘和键盘,而不是 usb 驱动。所以,我不去做 usb 的移植工作。

需要说明的是,移植以后,目的是让 grub4dos 摆脱 1M 实模式内存的限制,让 grub4dos 隐藏在扩展内存顶部。如此一来,驱动程序的空间就很大了,以后就不怕“常规内存不够用”的问题了。

目前的 grub4dos,其键盘和硬盘都是调用 BIOS,这使得 grub4dos 无法干净利索地隐藏在扩展内存顶部。如果我们不再调用 bios 了(因而不再占用低端常规内存了;只是 int13 处理程序占用几个 KB 的顶端常规内存),那就可以彻底地隐藏在扩展内存顶部了。

隐藏在扩展内存顶部之后,可以编写很大的 int13 处理程序,供 DOS 以及旧版的 Windows 使用。甚至还可以有足够的空间来编写(或移植) int21 的代码,让 grub4dos 直接能够运行 16 位的 DOS 程序。

这个工作完成以后,当然会与现在的 grub4dos 存在一些不兼容。普通用户可能感觉不到不兼容现象,但是,由于程序结构的变化,第三方开发者会感觉到不兼容现象。




目前的 grub4dos 有什么缺点?

很明显,内存管理、进程管理都有缺点,而且是最致命的缺点。有这样的缺点存在,它会给 grub4dos 的进一步开发造成阻力,产生瓶颈。我希望能够移植一个好的进程管理和内存管理系统,可以从 grub2 上移植,也可以从 Linux、Minix、BSD、kolibri 等系统上移植过来。

我对这些工作都不熟悉,所以,如果都由我一人来做,那可能需要很多年(需要学习相关知识才行,因此快不了)。所以,我私自意淫:假如 bean、chenall、Roy、yaya、karyonix 等一大批人都来一起干这事,那恐怕就比较顺利了。

回复

使用道具 举报

发表于 2015-8-17 08:55:43 | 显示全部楼层
如果只是由我来做这些工作,肯定与 EFI 无关。我所提到的上述工作,就够我做一辈子了。

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

回复

使用道具 举报

发表于 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 程序。

评分

参与人数 1无忧币 +5 收起 理由
879792799 + 5 都是大神啊!厉害

查看全部评分

回复

使用道具 举报

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

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

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

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

总之,你自己决断吧。

回复

使用道具 举报

发表于 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 空间,供别的内核数据结构使用。

回复

使用道具 举报

发表于 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 内存分配区,方便程序员的使用。程序员爱用哪种内存使用方式,就用哪种;很自由,很解放。

回复

使用道具 举报

发表于 2015-8-19 14:19:44 | 显示全部楼层
我把有关 ahci 硬盘和键盘测试的版本上载到时空论坛 grub4dos 区了。有兴趣者可下载测试。

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

回复

使用道具 举报

发表于 2015-8-20 20:36:58 | 显示全部楼层

测试文件已更新,请再测试。
回复

使用道具 举报

发表于 2016-2-16 20:03:51 | 显示全部楼层
2011yaya2007777 发表于 2016-2-16 19:24
现在做不到。
请按图像选择视频模式,或者按视频模式选择图像。

也可以让用户制作一个超级大的图片,来适应不同的分辨率。

grub4dos 只是采用图片左上角的部分来填充屏幕,多余的部分被丢弃。
回复

使用道具 举报

发表于 2016-2-16 21:27:51 | 显示全部楼层
2011yaya2007777 发表于 2016-2-16 20:32
确实可以。但是图像可能不太理想了。

100#的视频好像是16:9的。拉伸的图像并不理想,要是试一试动画, ...

用户应该适应 grub4dos 对图片的处理方式,他应该制作一个图片,其左上角含有重要信息,右下角只是用来填充屏幕的。如果用户按照这个思路去制作图片,就不会有问题了。
回复

使用道具 举报

发表于 2016-3-16 17:36:21 | 显示全部楼层
mdyblog 发表于 2016-3-16 16:45
ahci 硬盘 的G4D在哪儿?

这个工作没多大意义,放弃了。

ahci 驱动是基于 grub2 的代码,然而痛苦地发现,只要 ahci 接管控制,ROM BIOS 的硬盘代码就失效了。就是说一旦 achi 代码开始运作,再想回到 “能够使用 bios 来访问硬盘” 的状态,已经不可能了;此时 BIOS 硬盘调用将会死机(或长时间无响应,然后返回失败,无法访问硬盘扇区)。后来从 intel 的 ahci 规范中了解到,这是故意设计成这样的,即,一旦 BIOS 之外的 achi 代码取得控制权,就禁止 BIOS 硬盘访问,必须重启电脑才能让 ROM BIOS 恢复硬盘访问能力。

这说明,ahci 与 bios 是冲突的,并且这冲突是 intel 的规范所规定的。既然这样,那么引入 ahci 到 grub4dos 之中,就没有太大的意义了。

回复

使用道具 举报

发表于 2016-3-16 18:22:15 | 显示全部楼层
mdyblog 发表于 2016-3-16 17:47
这个 不是致命的吧。
BIOS可以回调 AHCI.
就是 ahci接管后, 重建一个 BIOS调用入口, 指向 AHCI 回调  ...

很抱歉,读不懂你写的中文。

顺便说,我已经离开开发的岗位了,现在相当于在疗养了。开发的事,就不要找我了。

回复

使用道具 举报

发表于 2016-3-25 12:29:08 | 显示全部楼层
2011yaya2007777 发表于 2016-3-25 08:55
菜单字符可以使用不同字型。
  例如:"七" 使用不同字型,将 .hex 文件中的 unicode 码 “4e03” 修改 ...

80h,是非法的 UTF-8 字符。

unicode 码 0080h 如果要转成 UTF-8 码,会变成两个字节,而不是单个字节 80h。

回复

使用道具 举报

发表于 2023-1-29 13:58:39 | 显示全部楼层
sunsea 发表于 2023-1-29 12:08
g4d用的lzma必须要求记录文件原始大小。好像当年采用lzma时说的一个意义就是文件大小在开头,很方便。zst ...
话说uefi下应该不存在实模式下内存限制导致尽可能砍代码的问题吧?

看到 sunsea 版主提到这个问题,我得解释一下。在解释之前,首先说明,下面这个解释并不重要,因为无论怎么解释,其结果都是要 “砍代码”,只不过 “砍代码” 的原因,不是由实模式造成的,而是因 grub1 缺乏内存分配机制造成的。

legacy bios 下,原始的 grub legacy 确实是受到实模式内存的限制。但 grub4dos 后来把代码从 0M 向上平移,挪动到 3M 的位置。也就是说,此后,本质上是可以使用任意多的内存的。但问题是,grub legacy 缺乏内存分配机制,没有内存分配函数,所以,grub4dos 的各个开发者都是用自己的方式来(任意)使用固定地址的内存,然后公布自己使用了哪些内存地址,以便让别的开发者了解,这样来减少发生冲突的可能性。这就是为什么在 grub4dos 中存在很多内部变量,它们有着固定地址。一个典型的固定地址内存的例子是,多国语言文字的点阵字模,占用好多 MB 的空间,使用的就是固定地址。别的变量空间就不可以与这里的点阵字模空间发生重叠。

就是说,本质上不是实模式的限制造成的,而是缺乏内存分配机制(各个开发者都在使用固定地址的内存碎片),导致 grub4dos 中的主体代码空间被挤压,不敢随便扩大(因为主体代码增长以后,会与其他固定地址的内存碎片发生冲突)。


点评

感谢解释!那只能说这个问题算个历史包袱了吧,不过好处应该是g4d应该现在以修bug为主了不轻易加功能了,变化不大,所以也能接受……不知道g4e有没有计划清理下这种容易互相冲突的内存使用……要不然给后面又继续造  详情 回复 发表于 2023-1-29 15:27
回复

使用道具 举报

发表于 2023-1-29 15:03:34 | 显示全部楼层
不知该不该插话。我曾经提交 grub4dos 的代码(当时还没有准备建立 grub4dos 项目),人家连一封回信都没有。bean 的代码能被采纳,我感觉已经可以满意了。后来又被剥离出来,也算是可以理解的吧。

大家都是自由的。软件的官方管理者有着管理的自由,他想怎么做,就怎么做。其他开发者有着自己建立新分支的自由,同样也是想怎么做就怎么做。大家是平等的。谁也管不着谁。
回复

使用道具 举报

发表于 2023-1-29 17:54:06 | 显示全部楼层
接着前面的闲话继续说,希望不至于冲淡了讨论的正题。

我倒是觉得,gnu 搞 hurd,应该搞下去。我唯一抱怨的,是他们 hurd 的开发进展速度太慢。我认可他们坚持搞 hurd 的做法。

linux 虽然软件丰富,已成规模,但我还是希望有别的系统来竞争,或者抗衡。我目前还是喜欢多元化。

一个项目的管理者、维护者,有着自己的偏爱。我在与 chenall 一起维护的一段时间里,就曾经拒绝采纳某个补丁。当时是有双重不放心(就是不信任):对补丁(的内容以及技术)不放心,对补丁的作者不放心。因此只能选择拒绝。而对于 grub4dos 各个时期曾经的开发、维护者,我都是完全放心,而且是双重放心:对他们的技术水平放心,对他们参与开发维护的目的放心。

当被拒绝的时候,这很可能已经表明,存在着概念层面上的差异,换句话说,两者不在一个轨道上。这种情况下,被拒绝了其实是好事。要加强自己对于真相的理解和把握。这里面没有什么 “对” 的和 “错” 的之分。要理解对方拒绝的理由,多猜一猜,会有哪些理由。猜到的理由多了,也就更接近真相了,那么,抱怨也就会减少了。
回复

使用道具 举报

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

本版积分规则

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

闽公网安备 35020302032614号

GMT+8, 2024-3-28 17:29

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

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