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

幸运的草

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

幸运的草

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

幸运的草

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时没有速度的问题。
      这样说，是想“鱼与熊掌兼得”。真的不能吗？

幸运的草

回复 #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时调用出错。即不识别。

幸运的草

确实经测试，我的那台机，如果U＋，U＋V2都可以正确识别是HDD还是ZIP格式，同时，用DG把U盘无论格式成FAT32还是NTFS，用BOOTICE写主引导为GRLDR时，也是识别为HDD。只有FB时，HDD格式才会识别为ZIP。
　但好像U盘为NTFS时有最小容量的限制，而且U盘上使用NTFS格式时会损伤U盘，缩短寿命。
所以微软开发了exfat分区格式。不过好像PE支持度不高。

幸运的草

主要是ZIP时map 慢，而HDD时map 并不慢。估计是判断为ZIP时会以软驱的速度去读盘。
但如果想点什么办法，让BIOS识别成HDD，这个问题也就解决了。
能正确识别FB盘为ZIP及HDD的BIOS，把U盘fb 为HDD格式也解决了这个问题，主要是BIOS把FB的盘强行识别为ZIP，这个问题就有点麻烦。

　经测试，当U＋、U＋V2及用BOOTICE写入GRLDR引导代码时，BIOS都会正确识别为HDD。只有FB时才会识别成ZIP，无论是ZIP格式还是HDD格式。
　　不知FB时文件格式与其他的制作方式有什么不同？

幸运的草

本来是跟ZIP模式无关，但由于大部分2.0接口的“老”电脑，并不是从BIOS起就支持2.0驱动，而是在WINDOWS下支持2.0驱动，所以在WINDOWS下读写U盘速度很快，但BIOS中没有集成ZIP的2.0驱动。当BIOS检测到U盘为ZIP时,G4D会根据BIOS的检测去调相应的模块，由于没有2.0驱动，只能以30K左右的速度去读U盘,慢得很，这时就与BIOS有关了。
  而你的新机是真正的支持2.0，也就是在BIOS中集成了2.0的驱动模块，所以就很快了。但并不是所有的新机都是如此，有的新机也没有集成2.0驱动，所以也并不快。

[ 本帖最后由 幸运的草 于 2011-11-18 08:18 编辑 ]