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

不点

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

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

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

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

不点

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

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

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

不点

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

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

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

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

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



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

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

不点

看不明白你想要说啥。

难道你在 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，都可以达到同样的“鱼与熊掌两者兼得”的目的。

不点

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

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

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


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

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

不点

喜欢看不点论道~~~~

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

哲学之道，既很平常，又很深奥。比如说，我们好不容易开发出了 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 编辑 ]

不点

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

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

不点

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

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

不点

嗯，你的洞察力够强。

确实有这样的可能性。

当系统需要读取 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 没有问题，我们这里的问题就不复存在了。

不点

诚然啊！

不过现在我脑子中似乎就有了这样一个概念：既然主板 BIOS 不让传统的软盘支持 LBA， 那么，让 U 盘启动为软盘，这一行为，实际上成了 “不智之举”。

应该生办法不让 U 盘被主板识别为软盘，否则，LBA 支持就可能被屏蔽掉了。这样，凭空产生了无穷无尽的麻烦。

比较而言，还是生办法让 U 盘被识别为硬盘比较好（支持 LBA 的可能性很大）。当 U 盘识别为硬盘 hd0 时，在 grub4dos 中，大不了就是一个磁盘交换（hd0 与 hd1）就可以把真实硬盘放在 hd0 的位置了。对于 grub4dos 来说，这是 “轻车熟路”，一点也不麻烦。

不点

让 fb 识别为 HDD，估计也是 “有门” 的。

注意研究 fb 盘与那些被识别为 HDD 的有什么差别。先猜测 BIOS 会找到什么差别来区分两者，然后再验证这个猜测。

所以我觉得有必要开发 fb 的替代软件，克服 fb 的一些问题。