无忧启动论坛

标题: C大，GRUB4DOS的map功能能不能添加缓存？ [打印本页]

作者: hotdll 时间: 2011-11-14 21:57
标题: C大，GRUB4DOS的map功能能不能添加缓存？
我查了下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 时间: 2011-11-17 09:26
顶上去，让不点和C大看到

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

作者: 不点 时间: 2011-11-17 09:39
grub4dos 对于设备本来就有内部缓存，不过缓存较小，只有 63 个扇区（31.5K）。

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

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

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

作者: 不点 时间: 2011-11-17 09:42
标题: 回复幸运的草

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

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

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

作者: sht123960585 时间: 2011-11-17 09:43
稀饭大哥，一头扎到GRUB4DOS里去了，顶你，鉴于本人水平有限，要不然都想跟你一直并肩作战了

作者: hotdll 时间: 2011-11-17 09:47
标题: 回复 #4 不点的帖子
不点大师辛苦了。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 编辑 ]

作者: 不点 时间: 2011-11-17 09:59
不使用 int13，还能使用什么？grub4dos 又没有设备驱动。如果要使用设备驱动，那你就得使用 GRUB2 和 BURG 了。

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

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

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

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

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

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

作者: hotdll 时间: 2011-11-17 10:09
标题: 回复 #8 不点的帖子
我还在弄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 时间: 2011-11-17 10:15
总而言之（言而总之），人们希望把GRUB2或BURG的设备驱动移植到grub4dos，以达到“鱼与熊掌两者兼得”的目的。
我们期望吧！

作者: 不点 时间: 2011-11-17 10:16
看不明白你想要说啥。

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

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

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

作者: 不点 时间: 2011-11-17 10:20

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

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

作者: chenall 时间: 2011-11-17 10:55
标题: 回复 #12 不点的帖子
目前直接map (fd0) (hd0)
这时因为没有MBR所以不可以使用(hd0,0)来访问只能用(hd0)/

可以自动添加一个MBR吗?

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

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

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

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

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

作者: 快雪时晴 时间: 2011-11-17 11:20
标题: 回复 #8 不点的帖子
喜欢看不点论道~~~~

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

作者: 幸运的草 时间: 2011-11-17 11:22
标题: 回复 #5 不点的帖子
目前fbinstools已经支持UD区文件编码列表utf-8格式，但是，如果ud区的文件名如果为中文，则由于fbinst不支持，则会出现读取文件错误或找不到文件。而此时如果为英文文件名，则正常。

作者: chenall 时间: 2011-11-17 11:31
标题: 回复 #16 幸运的草的帖子
应该没有这个问题吧,记得很早就支持了的.

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

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

作者: 不点 时间: 2011-11-17 11:32

喜欢看不点论道~~~~

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

哲学之道，既很平常，又很深奥。比如说，我们好不容易开发出了 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 时间: 2011-11-17 11:35
标题: 回复 #9 hotdll 的帖子
map (0)/a.iso (0xff)
map --mem (0xff)/b.iso (0xfa)
中间是不是还要有map --hook啊，你是不是省略了？

作者: 幸运的草 时间: 2011-11-17 11:40
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时没有速度的问题。
这样说，是想“鱼与熊掌兼得”。真的不能吗？

作者: 不点 时间: 2011-11-17 11:41
他肯定 hook 过了，否则不能执行第二个 map（他已经成功执行了第二个map）。

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

作者: jianliulin 时间: 2011-11-17 12:05

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

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

作者: 不点 时间: 2011-11-17 12:08

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

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

作者: hotdll 时间: 2011-11-17 12:14
标题: 回复 #18 不点的帖子
不点大师过奖了。。
我目前还是个G4D的使用者。
里开发还有很长的一段路。
最近在加班读汇编。。忘记完了。

作者: Plantsoot 时间: 2011-11-17 12:30
关于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 时间: 2011-11-17 12:58
标题: 回复 #23 不点的帖子
我突然想起来，很久以前，在老爷机上，用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 编辑 ]

作者: 幸运的草 时间: 2011-11-17 13:52
回复 #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时调用出错。即不识别。

作者: 不点 时间: 2011-11-17 14:30
标题: 回复 #26 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 没有问题，我们这里的问题就不复存在了。

作者: wannaknow 时间: 2011-11-17 14:50
标题: 回复 #28 不点的帖子
唉，根源还是当初规定，一次int 13h调用(CHS)不能要求读写跨磁道的连续扇区，一切以简化bios编写为目标。

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

作者: wannaknow 时间: 2011-11-17 15:01
标题: 回复 #28 不点的帖子
问题不仅如此，即使改进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 编辑 ]

作者: 不点 时间: 2011-11-17 15:23
诚然啊！

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

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

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

作者: Plantsoot 时间: 2011-11-17 16:08
标题: 回复 #27 幸运的草的帖子
兼容UTF-8的代码已经写完，目前够用。格式化成UTF-8的代码没写，用fbinsttool1.605解决，暂时不考虑动fbinst的原始代码，当然，加上很简单。

今天下午 hdlist 的功能已经完成，准备加到plus版中，就OK了。

注意：杏雨梨云的udload 改用 plus版中的 output来导出文件就可以了。

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

作者: hotdll 时间: 2011-11-17 17:10

原帖由不点于 2011-11-17 15:23 发表
诚然啊！

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

应该生办法不让 U 盘被主板识别为软盘，否则 ...

不点的解释正式我想要描述的。也让我明白了不少底层知识。

有一个办法，就是能不能让UD区变成NTFS格式或者其他格式。

因为研究发现。只要U盘的格式不是FAT格式，BIOS就是想把他当软盘，它也没那个本事。

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

作者: hotdll 时间: 2011-11-17 17:24
标题: 回复 #34 幸运的草的帖子
我记得软盘不能被格式化称fat32。软盘一般是fat12或者fat16 ,统称fat

作者: 2011qf020124 时间: 2011-11-17 20:04
标题: 回复 #28 不点的帖子
虽然我学习研究G4D的时间不长，但看到大家这么热情的讨论，也想来谈谈自己对G4D里MAP命令快慢的理解！！

1. 无论是直接map还是 map --mem,实现方式都是拦截int13中断，处理代码就放在640K的顶部！

2. 使用map --mem时，把映像加载到内存，然后在int13内部去访问内存，内存仿真盘int13的接口和普通物理磁盘的接口形式是一致的！！

3.直接map 时，本质是进行了int13的递归调用，即仿真盘的int13在其内部又去调用了真实磁盘的int13，这个递归的出口就是真实磁盘的int13调用！！

4.两种map都会使用到真实磁盘的int13，只是时机不同，所以依我看，g4d map的快慢，很大一部分原因取决于真实磁盘int13功能的速度，而这部分代码，是由主板bios提供的！除非g4d使用外部驱动，但使用外部驱动，可能会带来兼容性问题！

以上属于个人理解，有不对的地方请指正！！！

作者: 幸运的草 时间: 2011-11-17 20:35
标题: 回复 #36 2011qf020124 的帖子
主要是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时文件格式与其他的制作方式有什么不同？

作者: pseudo 时间: 2011-11-17 20:45
现在机器普遍很好，速度不成大问题。好像不大必要为此做大动作。

有许多应对办法。例如借助burg、memdisk等。
纯g4d也可以对付。例如0pe的“半解开”部署方式，或直接U+（不创建分区）部署方式，对usb-zip与usb-hdd理论上速度没啥区别，都不会慢。

作者: 不点 时间: 2011-11-17 20:57
让 fb 识别为 HDD，估计也是 “有门” 的。

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

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

作者: hotdll 时间: 2011-11-17 21:44
标题: 回复 #39 不点的帖子
严重同意。。。。
其实我现在觉得NTFS格式的U盘理论上通用性更好一些。
或者是FB的格式从FAT变成FAT32

作者: Plantsoot 时间: 2011-11-17 22:38
标题: 回复 #40 hotdll 的帖子
ud区有自己的格式，不是FAT也不是FAT32。

作者: hotdll 时间: 2011-11-17 22:52
标题: 回复 #41 Plantsoot 的帖子
但是BIOS并不这么认为。

作者: hotdll 时间: 2011-11-17 22:54

原帖由不点于 2011-11-17 09:39 发表
grub4dos 对于设备本来就有内部缓存，不过缓存较小，只有 63 个扇区（31.5K）。

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

这个缓存的功能是原来的 GN ...

我刚刚突然想起不点大师说的这句话。

识别为USB-ZIP的时候，读盘速度就是30K左右。

因为加载3.4M的镜像大概需要2分钟时间，也就是120秒左右。算来就是30K/S的样子。

作者: rockrock99 时间: 2011-11-18 00:14
标题: 回复 #39 不点的帖子
我也严重同意，因为我从来不搞UD，FB对我来说是浮云，还是加强G4D实际

另外插一句，速度跟USB-ZIP模式无关，我已经用联想的T4900V主板证实了：新旧两个BIOS，模式都是强制成USB-ZIP，但新BIOS就很明显改善了速度

作者: 幸运的草 时间: 2011-11-18 08:16
标题: 回复 #44 rockrock99 的帖子
本来是跟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 编辑 ]

作者: hotdll 时间: 2011-11-18 08:55
标题: 回复 #44 rockrock99 的帖子
你从来不搞UD不能否定FB，FB对大部分人来说并不是浮云。

USB-ZIP你强制了不算。至于速度有没有关系，论坛早有定论。。。不是你说无关就无关的。

你强制的USB-ZIP还是USB-HDD，没有任何的讨论意义。

作者: 快雪时晴 时间: 2011-11-18 10:25
关注中，看看有没有谁继续做出突破性的东西来...

欢迎光临无忧启动论坛 (http://bbs.wuyou.net/)