SVBus 取代 FiraDisk, WinVblock

不点

这是 2018 年 6 月 就已经出现了的，我今天才注意到。SVBus 的作用与 Firadisk 和 Winvblock 一样，都是 grub4dos 虚拟盘在 Windows 下的驱动程序（同样也是开源的）。不同点在于，SVBus 解决了若干个问题，使得从 Win2000 至 Win10（无论 32 位还是 64 位）的操作系统都支持了。 这也是我们以前期待已久的。

http://reboot.pro/topic/21787-svbus-virtual-scsi-host-adapter-for-grub4dos/
https://sourceforge.net/projects/svbus/

大家可以首先测试 SVBus 是否支持 4G 以上的高位内存（已知 firadisk 支持，但 Winvblock 不支持）。

---

顺便向 yaya 报告一个问题（我觉得是 bug 吧）。上周我有机会下载使用 0.4.6a 最新版，结果发现，configfile (...)/.../menu.lst 之后，当 menu.lst 执行的时候，当前 root 设备不是 menu.lst 所在的设备。我们以前的逻辑是，当 menu.lst 执行的时候，当前 root 设备和 boot 设备都自动设定成 menu.lst 所在的设备。这么久了，竟然没人向 yaya 报告这个 bug。如果 yaya 决定不让 configfile 命令更改 root 和 boot 设备，那么，今后用户自己在执行 configfile 命令之前，就应该先执行一条 root 命令，明确地把当前设备设定为即将执行的 menu.lst 文件所在的设备。

不点

2011yaya2007777 发表于 2018-11-11 10:15
configfile 这个函数没有修改过。我使用grub4dos-0.4.5c-2017-03-31测试，也是同样的。
也就是说，configf ...

哦，那就不知道是哪年改变的了。算了，既然没人报告这问题，说明这问题没什么影响。

以后用户不能依赖 menu.lst 执行时的 root 设备和 boot 设备的情况了。

不点

pcfan120 发表于 2018-11-11 08:18
支持大神测试，好像使用Winvblock不支持待机。。

我粗略阅读了 SVBus 的文档，发现 SVBus 也是很明确地不支持 hibernation （休眠）。

大家积极测试一下，看看 SVBus 是否支持 4G 以上高位内存。

我希望 SVBus 能够综合 Firadisk 和 Winvblock 的优点。

SVBus 的开发者目前也正在积极开发，大家最好趁此机会多多测试，免得以后在他已经失去兴趣的时候，再想找他解决问题，那就太晚了。

不点

读了开发者 schtrom 的帖子，隐隐约约感觉 schtrom 是以 winvblock 为参考来进行开发的。因此，我觉得很可能在 32 位 Windows 上不支持 4G 以上高位内存（就像 Winvblock 一样）。schtrom 提到他（曾经）使用 20G 的内存来作为内存盘。因此我猜，至少在 64 位 Windows 下，这个 SVBus 是支持高位内存的。

假如真的是这样，那么，在 XP 和 Win7-32 位 的情况下，仍然需要使用 firadisk。在较新的 64 位 Windows 电脑上，可以使用 SVBus。

不点

chiannet 发表于 2018-11-11 13:23
用DISM给USBOSv3 32位8 PE、64位8.1 RAMOS、64位10PE集成SVBUS_V1.1_20181109，启动均失败

32位8 PE，无 ...

请详细研究 readme 文件。里面谈到如何禁止驱动签名。

这个驱动是未经签名的。

不点

chiannet 发表于 2018-11-11 13:23
用DISM给USBOSv3 32位8 PE、64位8.1 RAMOS、64位10PE集成SVBUS_V1.1_20181109，启动均失败

32位8 PE，无 ...

我猜测一下 32 位失败的原因。

前面我已经猜测了，这个驱动可能类似于 winvblock，因此，在 32 位的情况，无法访问超过 4G 的内存。你有可能把 grub4dos 虚拟盘放在了 4G 以上的内存块上，因此出问题了。你可以试试把内存盘加载在 4G 以内，看看情况如何。

不点

chiannet 发表于 2018-11-12 06:13
是的，这个8pe是破解过的,可以“支持“访问4GB以上内存的。早就知道此类破解会失败于某些驱动程序:例如显卡 ...

到目前为止，还没有一个人去证实，到底在 32 位情况下，svbus 是否支持 4G 以上内存。

检验的方法很简单，用 grub4dos 加载在高位内存和低位内存，看看哪个成功。

不点

用新版 0.4.6a 测试更好。0.4.5 无法保证加载在高位或低位。

对于 0.4.6a，map 的参数 --top 开启高位内存支持，带上它，就优先加载在高位内存；不带它，则只可能加载在低位内存。而 0.4.5 不是这样的。

svbus 的具体使用方法，本人没有研究。请先研究 svbus 的使用方法。

不点

yamingw 发表于 2018-11-11 23:10
dism /add-driver /driver:svbus.inf /image:l:\ /forceunsigned
测试问题：比firadisk启动慢，占用内存大 ...

能否说详细点？

是32位还是64位系统？加载在高位还是低位？

不点

yamingw 发表于 2018-11-13 21:09
64位，win10，8G内存，3G VHD，Firadisk可用1.6G，svbus可用1.4G，高位加载

8G - 3G = 5G，你怎么只剩 1.6G 了？剩下的 3.4G 是低位内存吗？感觉你还是没说清楚。或者是你在啥地方弄错了。

这种技术本质上一样，不会相差太远。

比如说，占用内存大，则很可能是添加了缓存空间。

再比如说启动慢，则可能是启动时往缓存里面拷贝造成的。

不点

happysong21 发表于 2018-11-15 16:24
再报告一些测试结果：

Win2012 R2 Update3, X64的，安装驱动时直接蓝屏

各位，蓝屏问题，不一定是驱动本身造成的。我认为，驱动本身，不可能造成蓝屏。因为开发者已经测试过各种 Windows 环境了。也就是说，他自己的驱动，是顺利通过的，否则，他不会发布出来，尤其是不会明确说支持 win2000 至 Win10 全系列。既然他说了，那他本人就测试过了。

蓝屏属于 Windows 与 grub4dos 的冲突。最典型的，就是 WindowsXP 的某个显卡驱动有 bug，导致蓝屏。解决办法是用

map  --e820cycles=0

如果不行，可以调整数值为 1，2，3，……等等。这条命令放在 map --hook 或 --rehook 之前。换成 win7 的显卡驱动，则不需要上述 e820cycles 的变态解决办法。有人报告说，把 win7 显卡驱动提取出来给 XP 用，就不需要上述 e820cycles 的 workaround。这证明是 Windows 显卡的 bug，或者你说成是与 grub4dos 的冲突也可。也就是说，严格来讲，本质上是 XP 显卡驱动的 bug，与 grub4dos 无关。

以上只是举例说明，蓝屏的责任，不在 grub4dos，也不在 svbus，而是某个 Windows 秘密或 bug 造成的。

谢谢你测试 32 位 Win10 加载在高位内存，并报告成功。

但这有两种可能性：

一、 Win10 的 32 位本身已经支持高位内存。

二、 Win10 的 32 位不支持高位内存，但 svbus 支持，这划归 svbus 的功劳。

如果有人能排除 (一) 的情况，那就坐实了，即，svbus 确实是不依赖 Windows 自身的功能而能支持高位内存。

如果没人能排除(一)的情况，那就需要再用 XP 来测试了 或 Win7 32位 来测试了。否则无法坐实 svbus 支持高位内存这一结论。

不点

happysong21 发表于 2018-11-15 16:24
再报告一些测试结果：

Win2012 R2 Update3, X64的，安装驱动时直接蓝屏

刚注意到你测试了 Win8 32位蓝屏。

但缺少信息，无法判定。

加载在高位还是低位？

如果高低位都蓝屏，那属于 Windows 的 bug，或者说是与 grub4dos 的冲突，正如前面解释过的。

如果高位蓝屏，低位不蓝屏，则证明了，svbus 不支持高位内存，这跟 winvblock 是一样的，不如 firadisk，因为 firadisk 是内建支持高位内存，与 Windows 本身是否支持高位内存无关。grub4dos 也是内建支持高位内存，否则无法把 img 加载在高位内存。

不点

happysong21 发表于 2018-11-19 16:38
再次测试了Win7x86的系统，可以正常在高位内存使用SVBus，感觉确实是集合了Winvblock与Firadisk的优点！

...

辛苦了！谢谢告知这个重要的结果！

请继续测试，看看 SVBus 是否支持 “纯扇区序列” 的、非 --mem 的虚拟盘。

就是说，不使用 --mem，在硬盘上直接映射虚拟盘，而且虚拟盘是 (hdX,Y)MMMMMM+NNNNNN 的纯扇区序列格式，不是像 (hdX,Y)/.../.../File.IMG 那样带有文件名的格式。看看 SVBus 是否支持这样的纯扇区序列的 map。

不点

happysong21 发表于 2018-11-20 13:45
惭愧，不知道怎么映射。
下面是我现在的映射菜单项：
###########################################

先把 win7x86.vhd 整理碎片。整理后，它没有碎片，是连续的一整块空间。可以用微软的 contig.exe 来整理。

进入 grub4dos 以后，可以检验它是否连续。检验的命令是

blocklist /win7x86.vhd

它会输出类似下面的信息：

(hdX,Y)MMMMMM+NNNNNN

这就是连续的一整块。而如果像下面这样，就有碎块了：

(hdX,Y)MMMMMM+NNNNNN,PPPPPP+QQQQQQ

两个碎块之间，是用逗号分隔的。

你整理好碎块之后，用 (hdX,Y)MMMMMM+NNNNNN 来代替 win7x86.vhd，就行了：

###########################################
title  /Win7x86.vhd  blocklist without --mem
map  (hdX,Y)MMMMMM+NNNNNN  (hd0)
map (hd0) (hd1)
map --hook
rootnoverify (hd0,0)
chainloader /bootmgr
###########################################

不点

happysong21 发表于 2018-11-20 13:45
惭愧，不知道怎么映射。
下面是我现在的映射菜单项：
###########################################

顺便说，你的菜单有个不大不小的错误。最后的 chainloader 是有讲究的。

虽然你 chainloader (hd0,0)/bootmgr 的目标是正确的，但是，当前盘是不正确的。

各位知道，当前盘是由 root、rootnoverify、find --set-root 等命令来确定的。

您的当前盘是由 find --set-root --ignore-floppies --ignore-cd /Win7x86.vhd 来确定的。也就是说，您的当前盘是 win7x86.vhd 所在的真实盘，而不是虚拟盘。

然而你的 bootmgr 是在虚拟盘上。

你应该把 bootmgr 所在的虚拟盘 (hd0,0) 设定为当前盘：

root (hd0,0)

或

rootnoverify (hd0,0)

然后再执行

chainloader /bootmgr

就没问题了。

如果当前盘的设定不正确，那么，在有些情况下，会产生 boot 失败。

不点

happysong21 发表于 2018-11-20 16:02
多谢不点指教了！
再报告一下之前的问题：
用 blocklist /win7x86.vhd 检查之后，发现我的Win7x86.vhd ...

谢谢。这就是说，SVBus 支持纯扇区序列的映射。

这一点很重要，这样我们就可以映射某个分区了。

比如说，由于某种原因，我们 U 盘必须只有开头的一个 FAT 分区，其它的分区（NTFS）必须隐藏起来（其实是删除相应的分区表项）。这样，我们可以自动映射剩余空间为虚拟盘。进入 Windows 后，SVBus 能够支持虚拟盘。这样，我们的这个 U 盘就可以做到 “万能启动”（当然，没那么绝对），而同时也能支持（隐藏的） NTFS 分区来存放大文件。

---

我感觉这个 SVBus 与 grub4dos 的 “接合” 更流畅一些。它好像不需要记录什么信息——grub4dos 提供的是扇区序列，它就用扇区序列，不使用那些 grub4dos 并未提供的信息。我猜，它是在 Windows 下自动搜索各个设备，确定 grub4dos 虚拟盘的扇区序列所在的具体设备，从而驱动虚拟盘的。这个驱动的智能化程度更高，适应性更强，我感觉它与 grub4dos 也更 “接地气” 一些吧。

不点

顺便说一声另一个发现：SVBus与以前的winvblock一样，不加载入内存方式的映射修改系统盘内容后，映射源文件的最后修改时间是没有变化的——保持原来的时间。

我比较赞同这种处理方式，即，以扇区序列的方式来处理。这种处理，只修改文件的内容，不修改文件的其它信息（包括时间）。

这就是 grub4dos 的方式。grub4dos 所提供的，就是扇区序列（属于 BIOS 的概念），没有提供其它信息（没有文件的概念）。所以，其它信息就不能改动。

如果驱动程序做得更加完美的话，可以 “锁住”（保护好） 虚拟盘所在的扇区序列，不让其它进程随便写入（破坏掉）这些扇区。

不点

2011yaya2007777 发表于 2018-11-20 18:44
讨论的是 SVBus 的作用。

可是菜单：

作用有 “有形” 和 “无形”。

SVBus，Firadisk，Winvblock 三者的作用相同或相似，都是 “实模式虚拟盘的 Windows 驱动程序”。

只不过，SVBus 的表现形式更加 “自由”，不需要在 grub4dos 中 “显现”，因此属于 “无形”。

也可以理解为，与 grub4dos “无缝对接”。

winvblock 也可以是这样的，所以，我猜，SVBus 的开发者学习了 Winvblock 的做法，彻底做到了智能化，以及 “无形”。


顺便说，在 BIOS 已经被封杀的情况下，SVBus 的开发者竟然还能费劲开发这种软件，我有点不太理解。

所以，趁着他还有热情，大家还可以给他提问题、提要求。万一他哪天不再有热情了，那就没法再要求他啥了。

不点

75344840 发表于 2018-12-7 02:18
winxp 32位  8g内存 bios+mbr。  map --mem，map --mem --top，map (hd0,0)MMMM+NNNN三种方式启动成功。

这个报告切中要害，很能说明问题。再一次确认了，SVBus 支持 4G 以上高位内存（不受 Windows 32 位的影响）。

同时，SVBus 也像 WinVblock 那样，支持直接映射扇区序列。

要是有人能制作出一个 F6 软盘之类的，可能就完美了。

不点

75344840 发表于 2018-12-7 22:51
继续测试，硬件环境不变。这次测试U盘。

将16G的U盘全部扇区清除（全部扇区写入0）。

猜一下。

有可能是 SVBus 不支持 USB，也可能不支持这个牌子的 U 盘。

还有可能是 Windows 不支持这个 U 盘，或者虽然支持，但在早期启动阶段尚不支持。而此时 SVBus 要用 Windows 的 U 盘介质，结果无法访问，因此失败了。

另外，对于那些不含文件系统的 U 盘，Windows 也有可能会拒绝为它提供驱动。因此，这个问题可能不属于 SVBus 的问题。

你试试给 U 盘弄一个很小的分区（比如，10M 或 100M 大小；你的扇区序列不必在这个分区上），目的是让 Windows 能够为它提供驱动。看看这样做之后，SVBus 是否能够获得成功。

不点

jxf268 发表于 2018-12-13 21:04
Dell笔记本内存6G（4+2）map 、map --mem可以，map --mem --top失败。
或许我那电脑高位内存没那么大吧， ...

我猜，SVBus 可能不支持这个型号的 DELL 机。以前有 N 多报告，说 DELL 机制造了各种不兼容。就是说，比另外几个品牌更恶劣、更流氓。我不了解 SVBus 的工作原理，因此我只是瞎猜。

你可以试试 firadisk，看看是否支持高位内存。如果也不支持，那说明问题确实出在 DELL 上。

如果 firadisk 能正常工作，那说明 SVBus 采用的技术，不如 firadisk 的技术那么 “通用”。比如说，假如 firadisk 采用 CPU 指令集技术，则更通用，与电脑的其他硬件无关。而假如 SVBus 采用别的技术（比如 DMA 技术），那就受芯片组的影响了。

如果有时间折腾，那就多试试。没时间的话，那就不管它了。

顺便说，根据你提供的信息，grub4dos 能够成功将 IMG 放在高位内存。而蓝屏重启，则是进入 Windows 之后的事了。那可以说，属于 SVBus 的问题：它要么与 Windows 不兼容，要么与硬件不兼容。

grub4dos 把 IMG 放在高位内存，是很简单的事情，基本可以说，不可能出问题的。grub4dos 采用的是通用的 CPU 指令集技术，兼容 AMD 和 Intel 全部 CPU（当然 CPU 不能太老，否则 CPU 也可能不支持高位内存）。如果 CPU 是 64 位的，则 grub4dos 肯定支持。印象中，firadisk 也是采用 CPU 指令集技术，来支持高位内存。而 WinVBlock 则肯定不是采用 CPU 指令集技术，因为 WinVBlock 不支持高位内存。WinVBlock 采用的是 Windows 的 API。因此，WinVBlock 是否支持高位内存，完全取决于 Windows 是否支持高位内存。我不了解 SVBus 采用的是什么技术。但如果不是像 grub4dos 那样采用 CPU 技术，则终归是会遇到麻烦的。

不点

3、不弄分区，U盘全部扇区写0。map --mem --top 和 map --mem 都不能启动。在g4d读扇区数据到内存的过程中，自动断电关机。上次都启动成功了的。

内存条是假冒伪劣品？你这个报告，暴露出的问题就严重了。

grub4dos 采用什么办法来把 IMG 放在内存里面？先用 BIOS 读介质上的扇区，然后就是纯 CPU 操作，将读到的扇区从 DOS 实模式常规内存，复制到扩展内存。

有可能是 BIOS 阶段读扇区即发生死机、断电的错误了。

还有可能是，BIOS 阶段成功了，但在用 CPU 指令复制扇区到扩展内存时，由于内存条的故障，而产生硬件中断，进而产生死机、断电的错误。

无论哪种错误，都是很严重的硬件错误（BIOS 也算是硬件吧，因为它是硬件制造商弄出来的，别人改不了它）。

不点

做带有分区表的 img，也很容易。

你不是已经有个 “分区 img” 吗？在它开头增加 63 个扇区，并在增加后的 首扇区填上分区表信息，就成了。

如果你不会填，或懒得填，你可以让 grub4dos 替你做这事。方法大致如下：

首先明确一下，你的 disk.img 是由两部分组成的：开头是 63 个空白扇区（全是 00 字节），紧接着就是你的 partition.img 的内容。

首先，你用 hexedit 之类的工具，为 63 个空白扇区中的第一个空白扇区，填写 55 AA 字节。这两个字节是 MBR 合法标志，是放在首扇区的尾部。 其它的分区表信息，需要用别的方法来填。下面是采用 grub4dos 的方法。

1、你用 contig.exe 或 wincontig.exe 来整理 disk.img 的碎块，让它连续，以便下面用 map 命令。

2、开机进入 grub4dos，用 map 命令把 disk.img 加载为某个虚拟硬盘，比如 (hd9)：

map --sectors-per-track=63 --heads=255 (...)/.../.../disk.img (hd9)

3、让 map 生效：

map --hook

4、现在虚拟硬盘 (hd9) 已经存在了。但它没有分区表。现在就为虚拟硬盘 (hd9) 增加分区表项：

可以用 help partnew 来查看 partnew 命令的语法。注意下面的命令有危险性。如果你弄错了，你会把你真实硬盘的分区表破坏掉。注意操作的盘应该是你的虚拟盘 (hd9)，千万不要是真实盘 (hd0) 或 (hd1) ！

partnew  --active  (hd9,0)  0  (hd9)63+LLLLLL

或

partnew  --active  (hd9,0)  0  63  LLLLLL


以上两条命令是等价的，其中 LLLLLL 代表你原先的 partition.img 的总扇区数（即，总长度，用扇区数为单位来计算）。

命令行中间的的那个 type 是 0，表示自动。如果你知道它是 NTFS，你可以用 7。如果你想用 FAT32，那就用 0x0B 或 0x0C。

完了之后，你用 cat --hex (hd9)+1 看看分区表信息是否已经填上了。如果没有填上，那就是因为 grub4dos 的 map 在默认时保护 MBR，而把写入的信息丢弃了。你重新做一遍，这次为 map 命令添加 --unsafe-boot 选项，这样应该就能成功了。

注意，partnew 命令不会自动添加 MBR 的启动代码（boot record code）。它仅仅只是填写分区表信息。

上述 partnew 命令写入的是虚拟盘 (hd9) 的第一扇区（即 MBR）。也就是写入了 disk.img 的第一扇区。现在你重启电脑，进入 Windows，用 hex 工具查看 disk.img，应该发现，它已经有分区表信息了。

以上使用 grub4dos 的方法，具有危险性。你可以尝试、寻找别的方法，比如挖掘一下 BootICE 或 diskgen，八成也能够填写分区表信息。