无忧启动论坛

标题: 关于读取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.c3.wuyou.net/)