C大，GRUB4DOS的map功能能不能添加缓存？

hotdll

我查了下grub4dos的资料，直接map的是时候，使用的是INT 13H 直接将操作参数映射到被映射文件。

如果bios识别设备U盘设备或者其他设备为USB-FDD 或者USB-ZIP设备的话，BIOS 的INT 13H 就会按照fd驱动及速度去访问该设备。

所以map的时候，哪速度肯定只有30K以下。甚至更慢。

如果在内存中开辟一块空间，比如2M，以直接以文件的方式读取被映射文件的前2M块到该缓存。然后将映射地址指向该内存。。。

这样直接map 就可以不用int 13h中断。甚至可以要求文件不连续。

那速度真是杠杠的。

[ 本帖最后由 hotdll 于 2011-11-14 22:03 编辑 ]

hotdll

顶上去，让不点和C大看到

幸运的草

楼主的意愿是好的，但很可能不会引起重视，我发的那个帖子目的也就是引起开发者及使用者的注意及重视，以解决这个问题，但难！
     个人认为目前最应该解决的两个问题就是：1：zip盘map慢的问题。2、fbinst不支持UD区文件列表编码为utf-8的问题。

不点

grub4dos 对于设备本来就有内部缓存，不过缓存较小，只有 63 个扇区（31.5K）。

任何设备，不管是不是被 map 了的设备，都有这个缓存。缓存是 1 个磁道（通常就是 63 扇区）。

这个缓存的功能是原来的 GNU GRUB 就有的，不是后来添加的。

这一点缓存足够用了。你又不需要把 grub4dos 当作一个主要的操作系统来使唤，你只不过把 grub4dos 当作一个 “过路客”，还真不需要频繁使用某个磁盘区域，因此你也不需要使用大的缓存。就算个别情况下需要大的缓存，那也是没有的啊！呵呵！从哪里偷来点内存？毕竟 grub4dos 已经把内存都消耗得很严重了。

不点

fbinst不支持UD区文件列表编码为utf-8的问题。

你是说 fbinst 不能够创建 UTF8 编码的汉字文件名？那可以让 chenall 看看，解决这个问题。

至于说 grub4dos，那应该已经支持 ud 区的 utf8 文件名了。

sht123960585

稀饭大哥，一头扎到GRUB4DOS里去了，顶你，鉴于本人水平有限，要不然都想跟你一直并肩作战了

hotdll

不点大师辛苦了。5点钟我看您还在上传g4d新版本呢。估计熬通宵了。
burg没有map部分的源代码。
我不清楚burg是如何直接map的。
打个比方：
U盘被识别为ZIP的情况下：
a.iso 中包含b.iso  b.iso 600M
map (0)/a.iso (0xff)
map --mem (0xff)/b.iso (0xfa)
这个等待时间足以让人疯掉。

换成burg
map --set (fd0)/a.iso (cd127)
map --mem (map255)/b.iso (cd126)
这个时间很短，至少是g4d的十分之一甚至是百分之一。

我查了资料，应该就是map直接使用ｉｎｔ１３Ｈ 的原因。

[ 本帖最后由 hotdll 于 2011-11-17 10:10 编辑 ]

不点

不使用 int13，还能使用什么？grub4dos 又没有设备驱动。如果要使用设备驱动，那你就得使用 GRUB2 和 BURG 了。

鱼与熊掌不可兼得。每个技术都有每个技术的用途。不同的技术，所取得的结果也是不同的。各自都有自己的优点。各自都在发展。

世界上没有 “万能” 的东西（已经是哲学范畴了，抱歉）。

当然，不同的技术也可能融合，可能互相取长补短（这又是哲学，抱歉）。

但在某个限定的时间范围内，你很难达到所需要的那种 “完美”（即，“鱼与熊掌不可兼得”，这还是哲学，抱歉）。



EDIT: 才发现原来你想要的东西与 “缓存” 这个概念“风马牛不相及”。

[ 本帖最后由 不点 于 2011-11-17 10:07 编辑 ]

hotdll

我还在弄grub4dos的编译平台。还没来得去学习g4d  map --mem的代码。
将上面那个例子这样：
U盘被识别为ZIP的情况下：
a.iso 中包含b.iso  b.iso 600M
map (0)/a.iso (0xff)
map --mem (0xff)/b.iso (0xfa)
这个时间足以让人疯掉

改成这样：
map --mem (0)/a.iso (0xff)
map --mem  (0xff)/b.iso (0xfa)
这个时间就是想当的快了。
难道map --mem也是调用的int13H吗？
我记得您说过map是，map --mem好像不是。

zhaohj

总而言之（言而总之），人们希望把GRUB2或BURG的设备驱动移植到grub4dos，以达到“鱼与熊掌两者兼得”的目的。
我们期望吧！

不点

看不明白你想要说啥。

难道你在 map --mem (0)/a.iso (0xff) 这一步，速度也很快吗？如果很快，那证明用 int13 读取软盘 (0) 的速度也是没问题的。

而当 int13 够快的情况下，接下来的 map --mem (0xff)/b.iso (0xfa) 的慢，应该是一个 bug 了。

你应该报告详情，以便解决这个 bug。

不点

原帖由 zhaohj 于 2011-11-17 10:15 发表
总而言之（言而总之），人们希望把GRUB2或BURG的设备驱动移植到grub4dos，以达到“鱼与熊掌两者兼得”的目的。
我们期望吧！

总而言之（言而总之），无论把GRUB2或BURG的设备驱动移植到grub4dos，还是把 grub4dos 的功能移植到 GRUB2 或 BURG，都可以达到同样的“鱼与熊掌两者兼得”的目的。

chenall

目前直接map (fd0) (hd0)
这时因为没有MBR所以不可以使用(hd0,0)来访问只能用(hd0)/

可以自动添加一个MBR吗?

不点

它在真实的设备上，怎么能添加 MBR？可以写入一个分区表到第一扇区，不过，那样就破坏了 FAT 的引导扇区的尾部附近的 64 个字节。

如果 fd0 本身就是一个含有 MBR 的、已经分区好了的格式，那样就没问题了，直接用 (fd0,0) 就可以访问了。

关键是 fd0 本身就应该是一个含有 MBR 的格式。以前制作的三重 MBR 的软盘格式，都是这样的格式，既可以当做软盘，又可以当做硬盘。


忽然理解你大概想让 int13 仿真程序自动实现这一点。这是有可能做到的，但也有一定的危险，容易出差错。编程的时候，需要很仔细，考虑周到才行。目前我觉得不值得这么做。

[ 本帖最后由 不点 于 2011-11-17 11:21 编辑 ]

快雪时晴

喜欢看不点论道~~~~

hotdll有望成为G4D的开发骨干，有想法又有能力实践

幸运的草

目前fbinstools已经支持UD区文件编码列表utf-8格式，但是，如果ud区的文件名如果为中文，则由于fbinst不支持，则会出现读取文件错误或找不到文件。而此时如果为英文文件名，则正常。

chenall

应该没有这个问题吧,记得很早就支持了的.

出错的话,应该是自己使用的问题.

UTF8编码的中文文件,你的访问方式也应该是UTF8,即使用UTF8的菜单或批处理.否则失败是肯定的.

不点

喜欢看不点论道~~~~

感谢。霍金的 《大设计》非常好，我看了以后，觉得里面讲的全是哲学。我觉得那是 《大哲学》。但霍金自己却说 “哲学已死”，实乃调侃。建议对物理有兴趣者研读一下 《大设计》。世界之道都在里面包含着呢。

哲学之道，既很平常，又很深奥。比如说，我们好不容易开发出了 VBE 的图形界面。这本来也是好事。但用另外一种不同的眼光，却可能变成坏事：因为那是重复开发。GRUB2 中早已完成了的图形以及多国语言支持功能，我们又重复做了一遍，这便是一个毛病。世界不是完美的，有毛病是正常的，没毛病才是不对的。

再比如说，由于我的身体快要玩完了，这才引出 bean 以及 chenall。这身体差竟然变成了好事。Roy 经常活动于 DOS 联盟，而 DOS 联盟在今年竟然无法访问了，于是 Roy 就跑到时空论坛以及无忧论坛了，还成为 grub4dos 的维护者，这一点对于 grub4dos 来说那可是好事。

chenall 很费劲地为 grub4dos 进行工作，我想，有不少人暗自欢喜，其中大概也有 pseudo。为什么呢？因为 chenall 的工作正是 pseudo 想要的（声明：是我个人这么认为的，属于严重的个人主观臆断）。如果 chenall 不曾做那些工作的话，估计 pseudo 就要被迫费劲做这些工作了。

等等等等，整个世界都是浑然一体的体系，万事万物，互相之间都有牵连。

hotdll有望成为G4D的开发骨干，有想法又有能力实践

是的。hotdll 很强。

你也很不错。其实，能够跑到这里的来人，应该都很强。

[ 本帖最后由 不点 于 2011-11-17 12:53 编辑 ]

wannaknow

map (0)/a.iso (0xff)
map --mem (0xff)/b.iso (0xfa)
中间是不是还要有map --hook啊，你是不是省略了？

幸运的草

G4D目前来说其实是很不错的。但有一个对用户来说很头疼的问题。那就是当zip时非--mem map时那速度真叫人难以忍受。如果可能的话，我们可以把U盘做成HDD格式，以避免这个问题。但是，有的机会把HDD格式的盘也认成ZIP，加载一个内核为30M左右的ISO，得等14分钟左右才能启动完毕。这种速度真是挑战人的忍耐极限。

为此我等菜鸟进行过测试、讨论，也采取了变通的变法解决这一问题。论坛上HOTDLL的两个关于PE的处理，将加载PE的速度提高到了40秒以内。但这种办法不是根本性的。
      HOTDLL的意思可能表达不准确，也是为了解决ZIP盘MAP慢的问题。
    或者，那位英才能解决这个问题？无论是少驱动还是什么？这个问题解决了，那G4D才真叫完美。

至于讲到了BURG，也并不是说他就完美，如果完美，那早就转过去了。与G4D相比，它也有很多不兼容。但它有两个优点：1.map时不需文件连续存放。2：zip盘map时没有速度的问题。
      这样说，是想“鱼与熊掌兼得”。真的不能吗？

不点

他肯定 hook 过了，否则不能执行第二个 map（他已经成功执行了第二个map）。

[ 本帖最后由 不点 于 2011-11-17 11:43 编辑 ]

jianliulin

原帖由 幸运的草 于 2011-11-17 09:38 发表
楼主的意愿是好的，但很可能不会引起重视，我发的那个帖子目的也就是引起开发者及使用者的注意及重视，以解决这个问题，但难！
     个人认为目前最应该解决的两个问题就是：1：zip盘map慢的问题。2、fbinst不 ...

fbinst 不存在支持不支持utf-8 的问题，fbinst是按照字节对比的， 放什么进去就读什么出来，或者说fbinst天生就已经支持utf-8

不点

这样说，是想“鱼与熊掌兼得”。真的不能吗？

时机不对。你得耐心等待一个时机。当时机未到的时候，那是不可能的。但当时机来临的时候，那就是可能的了。chenall，bean，我，roy，yaya，足迹，zw2312914，karyonix，wannaknow 等等，数不清的人，都在做自己力所能及的工作，一刻也没闲着。其实，大家都在为着一个目标而努力，至于说努力的结果，那就不可强求了。该是什么样的结果，就是什么样的结果。

hotdll

不点大师过奖了。。
我目前还是个G4D的使用者。
里开发还有很长的一段路。
最近在加班读汇编。。忘记完了。

Plantsoot

关于fbinst对UTF-8文件列表的支持，我把fbinst plus更新了，用新版fbinst plus 和 fbinsttool1.605 应该可以解决UTF-8的问题了。
因为是第三方扩展fbinst，我没改动fbinst原始的命令，或者说不具备修改fbinst原始代码的资格。使用UTF-8文件列表，可以用fbinsttool格式化U盘和导入文件，使用fbinst plus的plus的命令导出文件等等。

希望下面的帖子有点用处。


【Fbinst Plus V1.1 Beta - 2011-11-15】Fbinst增强版(支持UTF-8格式文件列表)

[ 本帖最后由 Plantsoot 于 2011-11-17 12:31 编辑 ]

wannaknow

我突然想起来，很久以前，在老爷机上，用word打开软盘上的文件，能卡10分钟。
但是要是先拷贝，再打开就快多了。

map --mem (0)/a.iso (0xff)
map --mem  (0xff)/b.iso (0xfa)
第二步很快是因为做了优化，直接原地重新map。但第一步应该比较慢


map (0)/a.iso (0xff)
map --mem (0xff)/b.iso (0xfa)
第二步成了蜗牛了。。。比从(0)读a.iso要慢

是不是因为第一步的map导致的对齐的问题？

[ 本帖最后由 wannaknow 于 2011-11-17 12:59 编辑 ]

幸运的草

回复 #17 chenall 的帖子
回复 #22 jianliulin 的帖子

如果是这样的话，那可能是调用工具不支持缘故。我只知道调用工具是调用fbinst.exe。测试工具为udload.exe,fbinst plus .目前支持utf-8的新fbinst plus由百草正在开发。。
代表PE作品为0pe1.30、1.31散开放UD区。杏雨梨云A版。当编码为ansi时，UD内中文文件名调用正常，但为utf-8时调用出错。即不识别。

不点

嗯，你的洞察力够强。

确实有这样的可能性。

当系统需要读取 b.iso 的时候，系统本身认为 b.iso 是在一个光盘上，这个光盘的号码是 0xff。

系统为 0xff 进行缓存。

但 0xff 是虚拟的，它的真实介质是普通的软盘（即 U 盘）。

所以，当系统需要读取 0xff 的一个磁道时（15 个大扇区，折合成普通的 512 字节小扇区，共有 60 个扇区），int13 的仿真程序需要去读取软盘介质。

当软盘支持 LBA 的时候，也就可以一次读取多个扇区了。每次可以读取 60 个扇区，这样，问题也不大。

但当软盘不支持 LBA 的时候，似乎为了简单起见，int13 仿真程序只使用 CHS 模式每次读一个扇区。这样，60 个扇区就需要 60 次读取的动作，那就慢如蜗牛了。由于 int13 程序没有缓存空间可用，所以，读取的速度也受到影响。

改进 int13 程序是可能的，但改进以后，有可能加大代码的体积，使得 int13 的代码超过 12K 的极限值，从而与其他软件造成冲突。

目前这个问题不太适合去解决，放任它吧。

最好的解决办法，就是要求 BIOS 全面支持 LBA 模式（对于软盘 fd0），也全面支持 USB 高速访问。只要 BIOS 没有问题，我们这里的问题就不复存在了。

wannaknow

唉，根源还是当初规定，一次int 13h调用(CHS)不能要求读写跨磁道的连续扇区，一切以简化bios编写为目标。

结果最后所有人都嫌麻烦，才提出LBA的概念。

wannaknow

问题不仅如此，即使改进int 13h钩子，也会有性能损失。
对于虚拟的(0xff)来说，它是支持lba的大扇区光盘，不存在任何“对齐”的问题，每次读取都是以2048k为单位的。
可是，事实上，它可能是由1024/255/63的盘虚拟的。
只要bios不支持lba，再怎么改进，一次真实读取也不能跨过63这个“沟”
因此，会有大约3/63次读被“砍”成要读两次。

最糟的情况是18sectors per track，然后a.iso还是从奇数扇区开始的（又想了想，不对，a.iso的位置影响不大）。

[ 本帖最后由 wannaknow 于 2011-11-17 15:15 编辑 ]