非--mem形式 map iso镜像后读取文件失败的问题

不点

感觉 grub4dos 不太可能出现此类问题。只要你在 grub4dos 之下能够访问虚拟的光盘 (0xff) 中的所有扇区，那 grub4dos 的任务就圆满完成了。这很容易验证: 只需 把 (0xff) 的最后一个扇区 cat 出来:

cat --hex (0xff)xxxxx+1

如果内容正确，就表示没问题。注意，光盘的扇区大小是 2048 字节，不要把扇区号弄错。如果按 512 字节的小扇区，计算得到的最后一个扇区号肯定比较大。而应该按照 2048 字节的大扇区计算，最后一个扇区的扇区号应该比较小。

从描述的故障现象来看，好像是 winvblock 的某个限制造成的，请进一步确认。

不点

我来试着分析一下。

zhaohj 说：

文件大小=0x3706800，按每扇区512字节计算=0x1b834扇区数；按每扇区2048字节=0x6e0d扇区数
cat --hex (0xff)0x6e0c+1
显示结果正常。

文件大小不是 4K 的整数倍。注意，4K = 0x1000。因此，拷贝到内存之后，可能向上浮动，补全到 4K 对齐。因此，在内存中，大小按 0x1b838 个 512 小扇区计算，即 0x3707000 字节。

实际上最后多出了 4 个 512 字节小扇区，也就等于多出一个 2048 字节的大扇区。多出的这个扇区，当然是无效的扇区，即，不使用的扇区。它的内容全是 00 ，那是正常的，没问题。

以上各位的测试，没有发现 grub4dos 有任何错误（或者说没有发现 bug）。

那么，错误就在别的软件上了。例如，winvblock 有 bug。

猜测，当 ISO 处于硬盘不同位置时，winvblock 或者 firadisk 有 bug，导致不能正确访问 ISO 里的文件。bug 很可能随着起始扇区的数值的不同而有不同的表现。比如说，如果在硬盘上 ISO 的起始扇区号是 4 的整数倍，也就是 2048 字节对齐，则计算大扇区很容易。如果 ISO 在硬盘上的起始扇区号不是 4 的整数倍，那么软件在访问大扇区的时候，以某种方式发生了错误，即 bug。这只是一种猜测，究竟什么地方搞错了，那很难说。但我们总归可以确定，那是 winvblock 这类驱动程序的 bug。这种 bug 究竟是怎么表现的，具体的技术原因是什么，现在并不十分清楚。但 bug 属于它，却是比较清楚的，因为 grub4dos 没有问题，已经证明过了。如果从 grub4dos 内部访问 ISO 中的任何文件，都没问题，那就证明了 grub4dos 没问题。而且这是严格的证明。既然是证明，那就可以排除 grub4dos 的问题了。那么，就一定是别的问题了，例如 Windows 本身的 API 的问题，或者是 winvblock 的驱动程序的问题。如果我们相信 Windows API 不会有问题，那么就可以确定是 winvblock 的问题了。

[ 本帖最后由 不点 于 2012-2-21 18:49 编辑 ]

不点

别忘了，winvblock 是开源的，原则上讲，你甚至可以把代码中的 bug 找出来。

不点

@pseudo

如果你能确认是 grub4dos 找不到 iso 里面的文件，那么确实如你所说，可能是 grub4dos 的 bug。这很容易证明，以上几位为何不证明一下呢？

当然，也可能是 ultraiso 的 bug。这是有可能的，我记得 ultraiso 曾经有过别的 bug，它并未锤炼得很完善。

总之，究竟是谁的 bug，这太容易确定了。如果是 ultraiso 的 bug，那么，它制作的 iso 刻录到 cdrom 上，也无法被 windows、dos、linux 识别。或者挂在 qemu 之类的虚拟机上，无法被 windows、dos、linux 识别。

不点

@幸运的草

说的很含糊，没明白。什么叫做  “LBA 值是最大的”，能不能说的精确一些？文件本身没有 LBA 概念，文件可能占用很多扇区，每个扇区都有一个 LBA。所以，文件不只有一个 LBA。你说文件的 LBA 值最大，这就不能让人明白了。另外，什么叫 “ 最大 ”？这个也含糊。是最大的整数 0xFFFFFFFF 呢？还是最大达到整个 iso 的尾部？

map 有 “ 带 --mem ” 和 “ 不带 --mem ” 之分。如果带上 --mem 正常了，从 grub4dos 内部可以访问 iso 里的文件了，这说明，文件格式确实没问题。而如果此时不带 --mem 就无法用 grub4dos 来访问 iso 里面的文件，那就属于 grub4dos 的 bug。当然，需要事先排除 USB 出现故障的可能性。我们知道，USB 的 BIOS 有很多毛病。应该用普通的硬盘来试验。既然是格式问题，那与介质无关，普通的硬盘照样可以重现问题。所以应该用硬盘来试验，这样比较可靠。其实硬盘也不保证 100% 可靠。因为 BIOS 有 137G 极限，如果 iso 的位置处于超过 137G 的界限之外，那么即使在硬盘上，也照样会有问题。

希望各位逐一澄清这些问题。

[ 本帖最后由 不点 于 2012-2-22 09:08 编辑 ]

不点

我终于有点明白了，你们都是在 U 盘上做。

USB BIOS 出现各类故障，太常见了。如果 iso 碰巧处于 BIOS 能够访问到的区域，那么访问你 iso 里面的文件不成问题。如果 iso 碰巧跨越极限，则有一部分 iso 的扇区是可以访问的（即处于极限之内的部分），另一部分 iso 的扇区是无法访问的（即处于极限之外的部分）。

题外话：

各位尽量都把错别字改正一下，毕竟这里有外国人通过 google 翻译来阅读帖子。

楼主或者版主最好把整个线索的标题改一下。“一个非常古怪的问题”不是一个好的标题，不利于大家将来搜索这个帖子。

[ 本帖最后由 不点 于 2012-2-22 09:25 编辑 ]

不点

你好糊涂啊！抱歉，这不是责怪你的意思。

虚拟机的 BIOS 怎能等价于真实机的 BIOS？

不点

你的意思是说，用某软件修改 ISO 之后，不行了。

怀疑这个软件有 bug。

另外，你没有确认，带 --mem 是否也是失败的。如果带 --mem 失败，那就是 iso 格式被破坏所导致的了。也或者是 grub4dos 的 bug：它不能认识修改后的正确的格式，但这种可能性很小。而软件修改 iso 造成错误，这种可能性较大。

这里说的问题，与楼主所遇到的问题，可能属于两个不同的问题，不是同一个问题。

不点

诸位的探索，让我有这样一种印象：

grub4dos 没有问题。那个修改 ISO 的软件也没有问题。有问题的是 Windows 的 ISO 驱动程序（可能是 winvblock 之类的），它不能处理这种情况。

这还不能证明是 Windows 的 API 出了问题。要证明 Windows API 出问题，必须刻录光盘（或者把 ISO 挂在 qemu 之类的虚拟机的光驱上也是一样的）来验证 Windows 可否读出相关的文件。


当 ISO 文件长度不是 4K 的倍数的时候，可能出现这种问题。到目前为止的讨论表明，这是驱动程序的 bug。我认为 Windows API 很难出现这类问题。因此，我还是觉得这是 winvblock 的 bug。

由于 map --mem 自动把映像文件按 4K 对齐，因此，在带 --mem 的情形，bug 未表现出来。

这下子快要彻底弄清楚了。修改后的文件，可能破坏了原来的 “ 4K 对齐 ” 的文件长度，导致一系列问题的发生。

这 bug 是属于驱动程序的 bug（即，winvblock/firadisk 的 bug） 或者 Windows API 的 bug（这个可能性不大），这一点再次得到验证。诱因是当某个软件修改 ISO 之后，没有把 ISO 的长度按照 4K 对齐。因此，这也就有了 workaround：制作 iso 之后，保证 iso 的长度是 4K 的倍数，这个问题也就不复存在了。

不点

刚才没看到 55 楼以后的讨论。55 楼，确认没弄错吗？你把 ISO 提供给大家，让大家都测试，看看结果是否一样。

只要 grub4dos 在实模式能够访问文件，那就表明 grub4dos 没问题，同时也说明修改 ISO 的工具也没问题。

至于说其他问题，那就只能猜测了。

不点

55 楼按照 4K 对齐，此时，不带 --mem 成功。已经符合前面的结论了。

至于说带上 --mem 反而失败，这可能是另外一个完全不同性质的问题：有可能是 Windows 在某个阶段破坏了内存。它有可能不遵守 int 15 内存规范，属于 Windows 的 bug，或者某个驱动程序的 bug。内存遭到破坏，那么，内存中的 ISO 就可能正好遭到了破坏。

不点

好的，不带 --mem 的问题，算是解决了。正如前面所说，把 iso 文件增大到 4K 对齐就 OK。

下面看看能否解决 --mem 失败的问题。这应该是属于不同性质的问题了。或许这里真的能够发现 grub4dos 的仿真代码的 bug。

先由各位下载测试之后再说。

不点

好了，我再说说自己的猜测。

百草的 0pe，PE.WIM 的 LBA 值最高，它处于内存的最高处，接近内存顶端的边界。这就使得它更有可能被 Windows 的程序破坏掉。因此，--mem 启动 PE 而失败的可能性增加了。

当在尾部续上一些无用的字节以后，Windows 所破坏的，就是无用的部分了，而不是破坏 PE.WIM 文件。此时就成功启动了。

而你把 GRLDR 弄到最末尾，这使得 PE.WIM 安全了，因此，--mem 成功。

但是不带 --mem 失败了，这可能是因为修改后的 ISO 文件并非 4K 对齐的原因了，前面已经多次提到这个问题。

大家看看这个解释满意不？

不点

原因找到了以后，你的解决方法似乎还不算合理。

既然尾部容易遭到 Windows 的破坏，那么，这是用户的事情。用户制作 ISO 时，尾部应该增加适量的无用扇区。究竟增加多少，由用户来决定。这个问题不应该由 grub4dos 来解决。只要我们在文档中把这个情况说清楚，用户比我们还要聪明。用户知道应该增加多少。

况且，不同的 Windows 环境，根据所运行的软件的多少以及软件种类的不同，它所破坏掉的内存数目也应该是不同的。我们不可能一劳永逸解决所有的问题。试想？你怎么知道 Windows 破坏多少内存？目前说不定已经破坏了许许多多的内存，只不过有些地方没有影响到启动过程，未被发现而已。那些没有用到的文件，其中很可能也有一些已经被破坏了呢！比如说，零零散散地，有些地方只破坏了几个字节，而有些地方破坏一大块内存。这种情况是有可能发生的。

这个问题既然已经证明不是 grub4dos 的 bug，而且也基本算是找到了原因，甚至也有了 workaround，那么，剩下的工作就没有了，不需要做了。

需要说明的是，在 DOS 和 Linux 的情形，不可能出问题（Linux 是开源的，出了问题容易定位）。因此，也没必要为 Windows 而浪费 grub4dos 的代码，以及浪费内存。

另外，当不带 --mem 时，由于是在磁盘上就地仿真，我们根本无法增加扇区。所以，这必须由用户自己把 ISO 增补到 4K 的整数倍。

不点

Windows 究竟破坏内存没有，这一点也是可以精确证明的。

只要在 Windows 下，用 hex 工具软件把虚拟光盘的最后几个扇区显示出来，就知道它是不是被破坏了。

不点

filemax 是 long long 的，即 64 位。我们一般的文件都没有这么大，内存也没这么大，因此实际上这么大的文件根本无法装载成功。所以，越界的问题，还不怎么担忧。

sector_count 与 bios_drive_map.sector_count 是两个不同的变量，计算是没有差错的。

第一次是向上按 0x200（扇区边界） 对齐，接着第二次又按照 0x1000 （4K边界）对齐。其结果也就相当于一个 4K 的边界对齐罢了。前面的扇区对齐似乎有点多余，但那是没错的。至于说去掉扇区对齐是否可以的问题，那可以进一步研究。如果发现去掉之后完全正确，那样也可以去掉。我现在很懒了，精力不济。请 chenall 和你们来研究吧。

扇区对齐是我当初写的代码。后来 karyonix 增加了 4K 对齐的代码。这是不同的人写的不同代码揉在一块了。chenall 和你们可以看看这里能否优化一下。

不点

破坏掉的，正好是 2K。

这一点很值得疑惑。

而且破坏的数据正好是用 Unreadable .... （我猜测后面还有一个单词是 Data，在贴图中没显示出来）的可读字符填充 16 字节，不断重复同样的信息，直到把 2K 全部填满。

由于 grub4dos 会自动增加 ISO 的长度到 4K 对齐（虚拟后位于内存中的 ISO 应该是 0x3707000 字节），因此，我认为破坏掉的，不是 2K，而是 4K。请验证。

这就是说，这些内存并未真正使用，而是被某个软件 “ 初始化 ” 了，或者说，简单 “ 抹掉 ” 了。

那么这是谁干的呢？究竟是 Windows 干的呢，还是 winvblock/firadisk 干的？这需要进一步确认。猜测是 winvblock/firadisk 自己干的。

如果是 Windows 干的，即，它总是破坏顶端的 4K 内存，那么，这样也很容易验证。用一个虚拟软盘（其长度用 4K 对齐），就可以验证，是否软盘尾部正好有 4K 被破坏。此时最好不要运行 firadisk/winvblock，否则很难说清楚究竟是谁破坏了内存顶端。可以找找 Windows 下查看物理内存的 hex 工具。事先在 grub4dos 下记录映像文件的位置，然后进入 Windows 后查看内存，看看数据是否遭到破坏。

不点

你这次贴出的是不带 --mem 的情况。上次也是的吧？

不带 --mem，就出现不能读 4K 余数部分的情况。这应该与 Windows 系统无关了。由此可以基本确定，是驱动程序自身的限制，或者算是 bug。

真实磁盘上的数据不可能被破坏，驱动程序不会轻易写入磁盘的，因为那样的话，bug 就大了。驱动程序仅仅把 4K 的余数部分，用这种方式屏蔽掉了。也就是说，当用户试图访问这些扇区时，它简单给出 unreadablesector 的内容，如此而已。

换句话说，驱动程序不支持 “ 非 4K 对齐 ” 的扇区。

你这个试验，不能证明 --mem 的情况。也就是说，内存中的 ISO 是否遭到破坏了，目前还不得而知。

不点

嗨，你这是（有点）浪费呀。本来就知道 无--mem 的情况是必须 4K 对齐的，前面多次猜到了。这是已知的情况，你只不过证实了而已。当然，你证实它，也有功劳，不能抹杀。

我个人觉得最需要证实的，是 --mem 情况下遭到的破坏，究竟是怎样的？现在甚至连 “ 破坏者是谁 ” 都不能确定（是windows呢？还是winvblock/firadisk 驱动程序？）。

不点

发现什么问题了？

也许你的 ISO 结尾处本来就有很多 00 字节呢？

不对比的话，根本不能说明问题。

ISO 文件长度被识别成多少，那是驱动程序的事。文件长度很可能记录在 ISO 文件开头的一些敏感数据区。驱动程序很容易知道真正的 ISO 文件系统的长度。

所以，长度问题，不用考虑。

现在我们只关心，究竟有多少内存被破坏了。

不点

所以猜测内存被破坏了呀。有这些现象的存在，才有猜测的根据呀。

猜测 + 证明，就是科学研究的方法呀。

补齐了以后，有可能在遭到内存破坏的时候，只破坏了补齐的无用部分，保护了 ISO 中有用的部分。

不点

你又一次证明了 无 --mem 时，非4K对齐的失败情况。

而我们实际需要的是，在带有 --mem 的情况下，内存遭到破坏的证据。这个不容易证明了。估计要有很多困难。

不点

刚才在前面和百草霜的讨论中已经解释过了，你翻翻看。

在 83 楼。

[ 本帖最后由 不点 于 2012-2-24 17:40 编辑 ]

不点

目前的证据表明，这类工具没有犯错误。唯一可以算是毛病的是，它们没有把结果 iso 文件自动补全到 4K 对齐。这根本不能算是问题。

不点

这太容易解释了。

你的测试方法破坏了你的测试目的。

当你观察确定电子的位置的时候，你要用光子去碰它，结果，电子的位置确定到了一定的精度，但它的速度就完全测不准了。

你遇到的情况与此类似。

你的测试过程，干扰了测试结果，属于失败的试验。

不点

至此，已经证明了 Windows 下 的内存盘遭到了破坏。

如果你的启动过程没有 map --e820cycles=... 的命令，那就是说，Windows （或它的某个模块）不遵守 int15 规范，破坏了由 int15 保护的内存。

这次不像是 firadisk/winvblock 的错误了，因为我们原先有大量的证据表明，Windows 会破坏内存。那时候，发现它忽略 BIOS 数据区 0x413 处的内存规范，造成了问题。现在的证据则表明，它也忽略 int15 规范，破坏内存。

如果测试过程中有某个步骤使用了 map --e820cycles=... 命令，并且其值不是 -1，那么这就是正常的了，因为我们的 iso 并未得到 int15 的保护，windows 当然可以把它当作空闲内存而写入它了。

不点

0pe 在启动过程中，有没有 map --e820cycles=... 这条命令，很关键。

既然 4K 对齐，不带 --mem 时仍旧有 2K 被破坏，这就是说，这个驱动程序很可能总是破坏 2K 数据，也即一个 2048 字节的大扇区。

而在带有 --mem 的情况，那就要看有没有执行过 map --e820cycles=... 命令了。有和没有，其性质是不一样的，前面已经阐明。