无忧启动论坛

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

关于读取lzma压缩文件

[复制链接]
跳转到指定楼层
1#
发表于 2014-8-21 15:13:30 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
好像记得以前说lzma压缩的文件,必须以lzma作为后缀名,刚才我测试了lzma压缩的bmp 和lzma压缩的批处理,都了没有用lzma为后缀名也运行正确,请问现在是不是去掉了“必须以lzma为后缀名”这个限制??
推荐
发表于 2014-8-22 13:28:40 | 只看该作者
本帖最后由 不点 于 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 的补丁。

回复

使用道具 举报

2#
发表于 2014-8-21 15:44:50 | 只看该作者
是的,与 gz 类似,不再用后缀来区分,而是用文件头部的特征来区分。

点评

借个地问个问题. 请问一下不点关于rawread rawread原型 rawread (unsigned long drive, unsigned long long sector, unsigned long byte_offset, unsigned long long byte_len, unsigned long long buf, unsig  详情 回复 发表于 2014-8-21 17:59
回复

使用道具 举报

3#
发表于 2014-8-21 17:59:35 | 只看该作者
不点 发表于 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)

但是我试了一下,发现只能读,写入显示成功,但发现没有真正写入,这是怎么原因?
回复

使用道具 举报

4#
发表于 2014-8-21 18:21:30 | 只看该作者
读写都是用 BIOS,对吧?你当然知道这点。

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

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

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



点评

好像是虚拟机的问题,现在又正常了,,  详情 回复 发表于 2014-8-21 23:16
用rawwrite可以写入,只不过rawwrite只能按扇区写入.不方便, 看了一下两个都是一样的调用biosdisk, 所以才想到rawread,对于这些不是很理解. 我暂时使用grub_open("(hd0)x+Y")这样的形式,再用grub_write写入  详情 回复 发表于 2014-8-21 18:35
回复

使用道具 举报

5#
发表于 2014-8-21 18:35:53 | 只看该作者
不点 发表于 2014-8-21 18:21
读写都是用 BIOS,对吧?你当然知道这点。

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

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

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

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

我暂时使用grub_open("(hd0)x+Y")这样的形式,再用grub_write写入正常.只是会麻烦些.
回复

使用道具 举报

6#
 楼主| 发表于 2014-8-21 19:16:25 来自手机 | 只看该作者
我也借此问问,请问chenall有没有考虑让grub4dos支持32点阵字库??

点评

这个,暂时没有打算,要支持应该不难,只是内存占用的问题不好处理.  详情 回复 发表于 2014-8-21 23:17
回复

使用道具 举报

7#
发表于 2014-8-21 23:16:13 | 只看该作者
不点 发表于 2014-8-21 18:21
读写都是用 BIOS,对吧?你当然知道这点。

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

好像是虚拟机的问题,现在又正常了,,
回复

使用道具 举报

8#
发表于 2014-8-21 23:17:23 | 只看该作者
jianliulin 发表于 2014-8-21 19:16
我也借此问问,请问chenall有没有考虑让grub4dos支持32点阵字库??

这个,暂时没有打算,要支持应该不难,只是内存占用的问题不好处理.
回复

使用道具 举报

9#
 楼主| 发表于 2014-8-22 08:11:40 | 只看该作者
如果是由于内存紧张的原因,可否同时支持两种字库,菜单界面用32点阵,命令行用16点阵,菜单部分只需支持一百几十个字库应该就够了。

点评

看到 chenall 答复了别的问题,却没答复这个。我来试着答复,谈谈我的观点。至于说对与不对,我不敢保证。 就算只支持一个字,也需要编写出 65536 个字的显示程序,这个工作量一点都没减少。 内存空间更是没  详情 回复 发表于 2014-8-22 13:28
回复

使用道具 举报

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

本版积分规则

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

闽公网安备 35020302032614号

GMT+8, 2024-9-22 07:22

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

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