无忧启动论坛

标题: 关于读取lzma压缩文件 [打印本页]

作者: jianliulin    时间: 2014-8-21 15:13
标题: 关于读取lzma压缩文件
好像记得以前说lzma压缩的文件,必须以lzma作为后缀名,刚才我测试了lzma压缩的bmp 和lzma压缩的批处理,都了没有用lzma为后缀名也运行正确,请问现在是不是去掉了“必须以lzma为后缀名”这个限制??
作者: 不点    时间: 2014-8-21 15:44
是的,与 gz 类似,不再用后缀来区分,而是用文件头部的特征来区分。


作者: chenall    时间: 2014-8-21 17:59
不点 发表于 2014-8-21 15:44
是的,与 gz 类似,不再用后缀来区分,而是用文件头部的特征来区分。

借个地问个问题.

请问一下不点关于rawread
rawread原型
rawread (unsigned long drive, unsigned long long sector, unsigned long byte_offset, unsigned long long byte_len, unsigned long long buf, unsigned long write)

但是我试了一下,发现只能读,写入显示成功,但发现没有真正写入,这是怎么原因?
作者: 不点    时间: 2014-8-21 18:21
读写都是用 BIOS,对吧?你当然知道这点。

那就是说,BIOS 支持读,却不支持写。

没让死机,就算对得起你了。

早在 2005 年左右,我已经发现 DELL 的某个机型存在这个问题。它读取扇区没问题,但它的 EBIOS int13/ah=43h 却不能写入扇区,而是扔掉要写的扇区,但中断调用的返回值是成功。它的 CHS 模式却能够支持写入。也就是说,它的写入功能最多只能支持磁盘开头的 8G 内容。




作者: chenall    时间: 2014-8-21 18:35
不点 发表于 2014-8-21 18:21
读写都是用 BIOS,对吧?你当然知道这点。

那就是说,BIOS 支持读,却不支持写。

用rawwrite可以写入,只不过rawwrite只能按扇区写入.不方便,

看了一下两个都是一样的调用biosdisk,

所以才想到rawread,对于这些不是很理解.

我暂时使用grub_open("(hd0)x+Y")这样的形式,再用grub_write写入正常.只是会麻烦些.
作者: jianliulin    时间: 2014-8-21 19:16
我也借此问问,请问chenall有没有考虑让grub4dos支持32点阵字库??
作者: chenall    时间: 2014-8-21 23:16
不点 发表于 2014-8-21 18:21
读写都是用 BIOS,对吧?你当然知道这点。

那就是说,BIOS 支持读,却不支持写。

好像是虚拟机的问题,现在又正常了,,
作者: chenall    时间: 2014-8-21 23:17
jianliulin 发表于 2014-8-21 19:16
我也借此问问,请问chenall有没有考虑让grub4dos支持32点阵字库??

这个,暂时没有打算,要支持应该不难,只是内存占用的问题不好处理.
作者: jianliulin    时间: 2014-8-22 08:11
如果是由于内存紧张的原因,可否同时支持两种字库,菜单界面用32点阵,命令行用16点阵,菜单部分只需支持一百几十个字库应该就够了。
作者: 不点    时间: 2014-8-22 13:28
本帖最后由 不点 于 2014-8-22 14:17 编辑
jianliulin 发表于 2014-8-22 08:11
如果是由于内存紧张的原因,可否同时支持两种字库,菜单界面用32点阵,命令行用16点阵,菜单部分只需支持一百几十个字库应该就够了。


看到 chenall 答复了别的问题,却没答复这个。我来试着答复,谈谈我的观点。至于说对与不对,我不敢保证。


就算只支持一个字,也需要编写出 65536 个字的显示程序,这个工作量一点都没减少。

内存空间更是没办法减少。如果你想节约内存,那就得让磁盘暂且作为内存的缓冲,也就是说,实现虚拟内存。而实现这个,更是开辟了一大块的工作,远比支持 32x32 点阵的显示要复杂。

如果按照你的说法,既然屏幕上总共只能显示 1000 个字,那么只要 1000 个字的内存就够了。为什么还要在内存中保留 65536 个字的空间呢?那不是浪费吗?

任何事情都是权衡。浪费点内存,却能保证程序设计的简单、容易,运行效率也高。

不浪费内存,会让程序设计变得复杂,运行效率也变差。

实现某项功能,也是权衡的结果。有人需求,才有人去编写。而对于某些功能,究竟要花费多大力气去编写,这也是权衡。比如说,开发者多,有 20 多个人同时来维护 grub4dos 的开发,各种编程能手都有,那么,开发某个东西就是相对容易的了。

最终发现:缺少的是开发者、贡献者啊!

yaya 原来也是一个提要求者(当时我好像没能满足 yaya 的要求,甚至对 yaya 所提的要求,我连适当的关注都没有),后来 yaya 参与了开发,成为了开发者。甚至连 chenall 原先也是一个用户,后来克服畏惧心理,才勇敢地走到了前台。

从某种程度上说,chenall 和 yaya 都是被迫参与开发的。事物都是普遍联系的,再打个比方,grub4dos 的现有用户都是被迫使用 grub4dos 的,因为没有别的软件可以完全取代 grub4dos。再扯远一点,grub4dos 也是被迫独立出来的,因为当时的 gnu grub 开发团队不接受 grub4dos 的补丁。






欢迎光临 无忧启动论坛 (http://bbs.wuyou.net/) Powered by Discuz! X3.3