支持含有碎片的文件仿真

不点

Chenall 的colinux 环境可以编译外部命令。编译方法在源代码的开头注释中有说明。

不点

在文本时代，有规范，有标准。文本模式 3 就是所有的主板都支持的一个模式。它是 80x25 的彩色文本模式。

但是到了 vbe 3.0 ，图形模式已经取消强制性的分辨率了。就是说，没有任何一个分辨率是 bios 必须实现的。因此，你不能指望 640x480 的模式能够在所有的机器上畅通无阻。

不过，也许你周围大多数电脑都支持 640x480 的分辨率。你自己决定吧。你想要什么样的分辨率，graphicsmode 命令的参数可以让你选用。至于说具体的电脑支持不支持你想达到的分辨率，那可不是 graphicsmode 命令所能管得了的。

不点

很少有人纠结于采用多大的分辨率。菜单设计合理一些，通常可以用于任意的分辨率。每一行按最大 80 个英文字符来处理，遇到高分辨率的情况，无非是右边有很多空白，看起来不够整洁罢了，不影响用户的使用。

至于说竖向的行数，好像不需要关心，因为 grub4dos 的菜单系统会自动适应的。

补充说明一点：640x480 不是 80x25 个英文字符，而是 80x30 个英文字符。也就是说，比普通的文本模式多了 5 行。无论多大的分辨率，只要 bios 支持，那么 grub4dos 的菜单系统都能自适应。

不点

你好像需要看看教程，关于 graphicsmode 命令的解释。

你可以试试

graphicsmode   -1   600:700   100:1000   24:32

这样控制的分辨率可能就接近你的要求了。

不点

mdyblog 发表于 2015-5-24 07:12
改成
graphicsmode   -1   600:700   100:1000    8:32
是不是 适应性稍强点， 很老很老的VGA只有8位色 ...

不可以这么修改。

grub4dos 的 vbe 模式，只支持 24 位和 32 位的色深，不支持 低色深。

不点

mdyblog 发表于 2015-5-24 20:44
那碰着老的VGA（256色）

graphicsmode   -1   600:700   100:1000   24:32

你得知道，这是 vbe，不是 vga。老的 vga 模式已经不支持了（这些电脑只能使用 0.4.4 的旧版本）。而且，十分老旧的电脑早已经坏掉了，生存的几率是百万分之一，没人报告这种情况，我们就当作不存在好了。

上述命令执行失败时，不能进入 vbe 模式，会出现一条 error 信息。

如果 bios 不支持横向 600 至 700 个像素，或者竖向不支持 100 至 1000 个像素，则这条命令照样会失败。

不点

试试 dd 命令把它复制到内存或者硬盘，看看情况怎样？

另外，是否因为 fu.img 的开头正好符合 gz 格式或 lzma 格式，而被误判为压缩格式，尝试自动解压，所以出错？

不点

Fu.IMG 开头是 1F 8B ，这正好是 gzip 标志，所以出错。

你把 fu.img 开头清零，再试试。

不点

是由于主板 BIOS 不能访问较大的扇区号造成的。 不可能解决这个问题。

建议你养成习惯，总是把 grldr、menu.lst，以及 IMG 和 ISO 映像文件都放在靠近磁盘开头的分区里面。

不点

haobinnan 发表于 2015-7-6 16:57
不一定，在此主板，运行dos程序是可以显示所有扇区的；

DOS 程序可以显示所有扇区，不等于 BIOS 可以访问到所有扇区。

DOS 程序可以不使用 BIOS，比如 diskgen，GHOST 等。

不点

haobinnan 发表于 2015-7-6 19:10
DiskGenius是通过Bios中断读写硬盘；

你是怎么知道的？能否透露一下。

不点

2011yaya2007777 发表于 2015-7-10 08:03
分区表比较奇特。

硬盘分区清单

从提供的数据文件，看不出分区表的结构。可以在 grub4dos 下用 find 或 geometry 命令查看有多少个分区。这只能让报告者自己测试了。

还可以 cat --hex (hd0,4)+1 和 cat --hex (hd0,5)+1

如果都能成功 cat 出来，那就说明 BIOS 确实支持访问超过 128G 的扇区号。

如果不能 cat 出来，那就是 BIOS 不支持。

主分区已经是 100G （接近 128G）了，所以，位于扩展分区(的逻辑驱动器)上的文件，就有可能无法访问。

在 100G 之后，只有 28G 的空间是在 128G 以内的。如果 grldr 位于这 28G 以内，倒是也能访问得到它。但是如果 grldr 位于这 28G 之后，那就可能无法访问了。

GRLDR 位于主分区是没问题的，因为总是在 100G 以内。但位于 D：盘就要看是靠前还是靠后了。如果靠前（在 D： 盘的前 28G 以内），那就没问题，否则，就不行。如果 grldr 在 E：盘上，则肯定不行，因为肯定超过了 128G 的 BIOS 访问能力了。

这个问题很普通，也很常见。这并非很奇怪的问题。用我们现有的知识可以解释这个现象。只是问题出现了以后，报告者感到很惊异。报告者可能觉得 grub4dos 不该犯错误。其实这不是 grub4dos 的错，而是受到 BIOS 的制约所必然犯下的错，其根本原因是 BIOS 的错。

另外，报告者用某个 DOS 下的程序可以访问全部扇区，来说明 BIOS 支持访问全部扇区，这个逻辑是不成立的。DOS 下的软件可以用自己自带的驱动来访问硬盘，而不是使用 BIOS。

判断 BIOS 是否支持访问大扇区号的最简单的方法就是在 grub4dos 下用 cat 命令来测试（如上所述）。这个测试很简单，在菜单界面，按 c 键进入命令行，就可以测试了。一点也不麻烦。建议大家掌握这个方法。

不点

不知 yaya 有没有计划编写出硬盘驱动？只需要把第一硬盘驱动起来就行。

grub2 里面有硬盘驱动的代码，可以看看能否借鉴。

我需要这个硬盘驱动来解决 kexec -l grub.exe 产生死机的问题。我已经解决了导致死机的两大关键障碍，还剩下最后一个问题没有解决，那就是当用 int13 访问硬盘时死机。如果不使用 int13 而使用自己的驱动来访问硬盘，则可以正常操作，不再死机了。

所以我希望有一个硬盘驱动，替换掉 ROM BIOS 的硬盘驱动。

不点

2011yaya2007777 发表于 2015-7-30 18:00
grub4dos 增加硬盘驱动是相当有意义的事情。不过依我的能力，现在还做不来。
我以前看过 grub2 的 usb 驱 ...

我今天下载了 GRUB2 的最新源代码，竟然有 89M 之大（是用 git 下载的源代码），有发展到 100M 的趋势！

我也觉得，要看懂它，是一件不容易的事。不过如果有时间的话，我会尝试研究一下。

我粗略看了它的 disk driver，都是 C 语言写的，如果能够移植过来，也会十分庞大，不适合放在常规内存顶部，而必须放在扩展内存里面。

这样的话，就需要首先更改 grub4dos 的内存布局，把 grub4dos 自身隐藏在扩展内存顶部（以前曾讨论过）。

这会很累人的。所以这个工作暂且搁置起来。

还有一条路线就是设法移植一个精简的硬盘驱动。BareMetalOS 里面的硬盘驱动就只有若干个字节，当然它可能只能应付少部分硬盘。

第三条路线就是不再移植了，而着重解决 Linux 硬盘驱动与 BIOS 硬盘驱动冲突的问题。

如果这个问题彻底解决了，那么 Linux 就可以扮演一个引导器的角色了。

我就先沿着第三条路走，准备挖掘 Linux 的硬盘驱动造成 BIOS 硬盘访问失败的技术根源。

不点

mdyblog 发表于 2015-11-15 09:49
请问 360救急盘的这个 syslinux.cfg 怎么转为 grub4dos菜单？
文件位置：（hd0,0)/360Disk/syslinux.cfg
...

1、能不能一步一步显示屏幕信息，而不是只有 “重启” 两个字？

2、试过 0.4.5c 和 0.4.6a 吗？

3、试过早期的 grub4dos 版本吗？没准早期的可以成功，而后来的版本可能引入新的 bug。

4、你用的是原版未改动的 grub4dos 呢，还是经过你改造之后的 grub4dos？（开源软件，任何人都有可能改造它）。

以上是处理问题的一般步骤，目的是尽量缩小范围，快速确定问题的根源。

不点

ee1 发表于 2015-11-17 17:07
老机器 ide硬盘
从0.44升级到    grub4dos-0.4.6a-2015-11-10  最新版了
最新版map vhd 效果比 ...

ee1 兄，你报告的 error 60 似乎是说你的映像文件不连续啊。这可是个常见的问题，教程应该讲得很详细。你把你的映像文件进行磁盘碎片整理，整理成一大块连续的文件，就可以了。好好看看教程，希望今后不要有人再提出这类初级问题了。

不点

ee1 发表于 2015-11-18 09:00
收到。
最新版支持不连续的文件，以前的0.46a 也是不能启动的，我只是想问下和ide 硬盘有无关联？

GRUB4DOS 没有硬盘驱动，全都是使用 BIOS 来访问硬盘。

而 BIOS 根本不知道硬盘是什么类型：不知道究竟是 USB 设备还是 别的设备，不知道究竟是 IDE 还是 SCSI，不知道究竟是 SATA 还是 PATA。

因此 grub4dos 从来不涉及硬盘类型的问题。它只根据硬盘的 BIOS 号码 （0x80 之类的）来访问硬盘。

不点

mdyblog 发表于 2015-12-29 14:20
报告一个奇怪的现象。
（0000:8280  4字节（即双字） 启动驱动器号(boot_drive) ）

那是为了方便菜单的编写。当菜单获得控制权时，它所在的盘就是当前盘，它所在的分区，就是当前 root 分区。同时也把当前盘模拟成启动盘，把当前分区模拟成启动分区。

不点

mdyblog 发表于 2015-12-29 16:57
改启动设备， 真的没道理。
感觉好心办坏事。
   就像，感冒了， 结果医生把丁丁给切了。

理解不动，不接受，那你就改它呗。事是死的，人是活的。

过去我也曾发表过自己对某些做法的不满。我也曾按照自己的思路更改过不少东西。

那判断的标准是什么？完全就是自己的标准。自己说了算。自己说它对，它就是对；自己说它错，它就是错。

世上没有什么正确与错误。只看每个人自己的认识而已。

世界那么大，人口那么多，怎可能众口一词？

哪个当领导的，没有几个反对者？怎么做才能让所有的人都满意？很难很难。

grub4dos 是由 chenall 负责的，后来 chenall 又让 yaya 来共同维护。Roy 也参与维护了一阵子。其他也有很多人在帮助。

我很少参与，我不再管事了。只要你能以充分的理由让 chenall 他们同意你的意见，你就可以实施你的修改方案了。

万一 chenall 他们不同意，你还可以建立自己的项目，自己来管理。

世界的自由度还是蛮大的。


grub4dos 这个项目，说实在话，我一开始就没打算开启它。我给 gnu grub 开发者提交补丁，不被采纳，而且连回信都没有，我这才开始正式着手做。

现在想想，那是缘分不到，没啥稀奇的。gnu grub 当时也正处于即将转向 grub2 的节骨眼上，所以他们可能对于继续改进和完善旧的 grub 版本没有兴趣了。还有一个原因可能是我写的代码，不符合 gnu grub 对排版格式的严格要求，再加上其它一些我猜不透的原因，人家拒绝了。一句话来概括，没缘分。

刚开始的时候，是只在 grub.exe 格式上进行改进完善。所以它叫做 grub for dos。后来逐渐深入到 grub 的内核里面，哎哟！发现了一大堆不如意的东西，砍啊，杀呀，被我清理掉好多。今天看到的 grub4dos，是经过了很大手术的（除了我以外，其他几位维护者也在内核中动了手术），是对原来的 grub legacy 的巨大翻修的结果。我不敢说，我的每一项改动都是合理的。世上没有合理性，只有缘分。缘分是那样的，它就是那样的。由谁去改它？改成什么样？众人是否喜欢和接受？林林总总，这统统都是缘分。有缘分能做成一件事，没缘分做不成一件事。正确的东西，不一定能成为现实，因为连正确性都是相对的。一个正确的人遇到一个错误的人，究竟谁才是真正正确的？是不是要打一架，谁打胜了，谁就是正确的？我相信，就连这句话，都存在不同的看法。有人认为对，有人认为错。还可能有人认为不对也不错。也可能有人认为这问题没有意义，无从谈起对和错，因为前提中正确的人和错误的人，就没有个绝对的标准可以确定。

一个团队，一个论坛，一个社会，还要讲求合作。不能光讲技术，不讲合作。没有技术是不行的。光有技术也是不行的。光讲合作也不行，有时候就需要有竞争、有分歧，在竞争和分歧中促发展。我在自己的人生旅途中，并不擅长与人打交道，我喜欢理科，不喜欢文科。理科是直来直去，答案比较简单。文科很复杂，涉及的知识面太广。所以每当遇到与人打交道的事，我就本能地躲避，或抵触。这样我就越来越与人疏远，形成自闭、内向的性格特征。所以也就不懂合作的道理，也就不会合作。由于理科较好，所以自信、偏激，总认为自己的判断是对的。老师的多次表扬，也助涨了自己的自信和自傲，习惯于以自我为中心，不能听进反对的意见。这在 grub4dos 早期的论坛上，大家可能都看得很清楚。后来我有了不少改进，但骨子里固有的顽疾，也不可能彻底消除，人就是个不完美的动物。我回顾早期，我是只讲技术，不讲合作。其实也就不懂合作，没有意识到世界上还有 “合作”这回事。后来能够意识到世上有合作这回事，并且逐渐知道了，这合作比技术还重要。climbing 就直言不讳地批评我伤害了 bean，我当时并不认识这一点，但后来还是逐渐采信了 climbing 的说法。人与人之间，需要合作。人与人之间肯定会有不同的认识和分歧。如果总是以自我为中心，那就会在发生分歧时总把别人判为错误的。那本质上就是不懂合作，因而也就无法真正做到尊重别人。当发生分歧时，如何处理，这太重要了。处理不好的话，就会把项目搞砸了，把团结搞砸了，把技术也搞砸了。人不可以缺乏自信，但也不可以过分自信。过分自信，容易形成自我中心，容易排斥团队中的其他成员，严重时，也容易产生自傲。

算了，不再多说。喜欢听的人，或许不在乎说多了。不喜欢听的人，可能会厌烦，可能觉得这是在显摆、卖弄或教训人。就此打住，不再废话。

不点

wuwuzz 发表于 2015-12-30 11:46
这段话不太严谨。

BIOS当然知道硬盘是什么类型，知道是 USB 设备还是 别的什么设备。

没错，就是这个意思。

BIOS 提供的信息可能很多，但我们不一定能够调用这些 bios 功能。

因为有些机器不遵守 bios 的调用规范，所以我们不敢调用那些功能。我们只限定那些安全的功能调用。譬如说只限定 int13/ah=02、03、42h、43h 和另外几个功能调用（即 AH=41h、AX=4B01h 等），其他功能都不敢随便调用。有报告说 int13/ah=48h 产生死机。int13/ah=00 也产生过死机。int13/ah=08 返回的磁盘参数是不可靠的（就是“错误的”），所以这个功能调用是没用的。

不点

第一个图片显示的是一个明显的低级错误：文件名错误，少了开头的斜杠，应该为

map --mem /a.bat  (rd)

不点

chenall 发表于 2015-12-31 11:40
我找到原因了,是由于新版本的调整导致的.

我看了下,考虑重新调整一下PSP的结构以方便使用.

非常好。

是我不熟悉批处理，理解不到位，所以没能考虑到新格式对批处理的影响。

不点

mdyblog 发表于 2016-4-12 09:27
谢谢!
如图, 这个会把600M 耗到尾.后面程序没有内存可用了.

map --mem=XXX 的意思，本来就是把 XXX 之后的内存（直到这个内存块结尾处）都作为这个内存盘的扇区数据空间。

不点

这要看你的用途了。只有你自己清楚该怎么做。

这个内存盘究竟是要在 grub4dos 范围内使用呢？还是要在 DOS、Windows 中使用？

如果是前者，你不需要虚拟盘（即无需挂上 int13），你只需要调整好 rd 的起始地址和长度即可。

如果是后者，你必须使用虚拟盘（挂上 int13）。目前的 grub4dos 不支持从一个内存块中间截取某一段内存当作内存盘，只能把某个内存块的尾部一整块都当作内存盘。就是说，你的特殊要求，做不到。

不点

mdyblog 发表于 2016-4-13 18:38
请问 mem64是25好还是74.2个地方不一样.
头文件:
#define mem64 ((int (*)(int, unsigned  ...

从 asm.S 结尾的代码可以知道，25 已经废除了，改用 74。

头文件可能没有调整过来。你向 chenall 报告 bug。

不点

rehook 有可能有 bug，可能没有处理 --top

rehook 会重新进行 map --mem 的操作。有可能在此时都重新 map 到低端了。

chenall 可看看 rehook 的问题，修复这个 bug（如果有的话）。


mem64 是我开发的。可能有 bug。我初步怀疑，它可能适用于 AMD，不适用于 intel。

待我有时间试试看。

唉，真泄气。mem64 根本就不工作。我自己看了，也没找出问题。我打算让 karyonix 帮忙修复 bug，或者干脆重写。

不点

mdyblog 发表于 2017-8-25 00:20
反馈个内存问题：NTLDR/2003抱怨低位内存不足

常规内存 0x9D800 = 630K，不算低。

可是你已经把 0x80000 以上的内存占用了！否则，Windows NT 不会报错。

0x9D800 - 0x80000 = 118K

grub4dos 的 int13 处理程序不可能占用 100K 多 K 的空间。

推测：你一定使用了别的磁盘仿真软件，或者其它类似的软件，占用了常规内存顶部的大量空间，从而与 Windows 的实模式启动程序发生了冲突。

还有一种可能性，你如果是从 PXE 来启动电脑，你的 PXE BIOS 有可能占用 100 多 K 的空间，从而与 Windows 的实模式启动程序发生了冲突。

---

背景：

常规内存空间很紧张，很 “值钱”（物以稀为贵）。有 N 多程序都在争用常规内存。

微软的 Windows 要占用低端的 512K 内存。而常规内存总量，最多也只有 640K。

因此，其它软件总共最多也只有 128K 的空间可以利用。

有些 BIOS 本身还要占据一些空间，比如你这个 BIOS 都已经占用了 10K 的空间了！这样的话，其它软件只有 118 K 的空间了。

---

PXE 的 BIOS 会占用 100K 左右的空间。你没提到你是使用 PXE 启动方式，所以，假定你不是从 PXE 启动的。

那么我猜，可能性最大的，就是你自己编写的某个程序（或者你使用了某个 “很吃常规内存” 的软件）占用了很多常规内存空间——占用了大家都在争用的、宝贵的常规内存空间。这是造成冲突的根本原因。

---

为了明确起见，再补充一下。你贴出的 Windows 出错信息证明了问题出在常规内存上，而不是扩展内存上。因此，你不要考虑扩展内存方面的问题了——根本就只是常规内存的问题，与扩展内存 “完全不沾边”。

你贴出的 displaymem 信息，基本上证明了产生问题的根源不在 grub4dos，而在于其它某个消耗常规内存的 “大户”。grub4dos 的 int13 处理程序只会占用很少的空间，0.4.5 之前的版本通常占用 12K。而 0.4.6 究竟占用多少，我不太了解；但我猜，也不会很多，应该在 30K 以内吧？假定就是 30K，那么还剩下 80 多K 被谁占用了？你应该找出那个占用内存的 “大户”，从它身上 “讨回” 一些空间。这种事情，尽量不要在 grub4dos 上动脑筋，因为 grub4dos 的开发者会尽量节约空间的，不会浪费很多空间。

不点

mdyblog 发表于 2017-8-25 21:47
1) 就是纯 U盘启动， 没有PXE
2）就是纯grub4dos环境， 没有其他磁盘仿真软件
3)  仅仅换个grldr到20 ...

你的报告严肃、认真，很详细。可能是因为你是开发者吧，能抓住要害，而与一般的报告不同。那么，我的答复，也得格外负责才行，否则对不起你的报告。

首先，你忽略了（或混淆了）两个问题：常规内存和扩展内存。

这两部分应该单独报告，不可以揉在一块。

常规内存中的问题，前面已经解释清楚了，不再重复。

特别提醒一下，你没有提到你是如何使用 grub4dos 的。有可能是你自己使用过程、步骤“不合理”、“不正确”等，而引起的问题。譬如说，你的使用过程或步骤“异常”，超出 grub4dos 开发者的想象，超出了 grub4dos 的适用范围，使用了 grub4dos 文档中不曾提到的那些用法或步骤（比如你自己想当然的、误以为 grub4dos 应该具有某个功能但实际上并不具有，而你去使用那样的功能，自然会出问题）。你得明白，grub4dos 开发者的支持范围是啥（那就是开发者认可的那些文档中提到的用法）。超出支持范围的使用，那就是不支持的。超出范围的报告，也是不支持的。

以下假定你没有任何超限的、超范围的使用，全都是 grub4dos 文档中规定的使用方法。如果你不能满足这一点，那就不要往下看了。你需要用 grub4dos 文档规定的使用方法来重新进行试验和提交报告（有可能完全没问题了，因而也就无需报告了），那样，我才认为，报告是合理的、问题是认可的、bug 是承认的。否则，报告不被认可，问题不认为存在，bug 也不承认有。在进行 bug 报告时，不可以有任何超范围的使用，连一丝一毫都不行。（特别声明：我现在不是开发者，我不代表开发者、维护者，我只代表我自己；所有的见解、想法，都是我自己的，我不代表别的任何人。今后都是如此，希望不需要每次都声明，太累。）

请在符合上述要求的情况下，继续阅读。否则，停下来，不要继续。

---

下面根据你的描述，我来试图解决你所提到的扩展内存中所表现出来的问题。

你可能不了解，新版 grub4dos 对于虚拟内存盘所使用的内存块的搜索方向，进行了比较大的改造。旧版是从低到高，新版是从高到低。就是说，旧版会使用“能够放得下内存盘的最低端的内存块”，而新版会使用“能够放得下内存盘的最高端的内存块”。--top 参数的意义也与旧版不同，这里不讨论（因为你的问题没有涉及到它，因而不需要讨论 --top 在新旧版中的差别）。

你发现了，旧版使用了位于最低端的这个内存块

1. Usable RAM: Base: 0x100000, Length: 0x1FF00000

复制代码

而新版使用了位于最高端的这个内存块：

1. Usable RAM: Base: 0xD6FFF000, Length: 0x1000

复制代码

这是正确的。这不是 bug，这不是异常，这是设计成这样的。

由于新版 --top 的意义不同于旧版，因此，如果新版未指定 --top 参数，那就不会使用位于 4G 以上的这个“高位内存块”：

1. Usable RAM: Base: 0x100000000, Length: 0x11FE00000

复制代码

好的，已经解释了，新版 grub4dos 没有任何问题。那么有问题的是啥呢？有问题的，是你的 Windows，也或者是你的 BIOS。

你的 BIOS 指示我们，说这些内存块都是 Usable RAM。换句话说，随便用哪一块，都是允许的。旧版挑选最低的那一块，新版挑选最高端的那一块。这能是 grub4dos 的错吗？肯定不是啊！那么错在哪里呢？动动脑子，猜猜就知道啊，必然是下面两者之一有错（或者两者都有错）：

可能性一。BIOS 把一个不该是 Usable RAM 的内存块标记为 Usable RAM，让 grub4dos 使用它来放置内存盘，导致 Windows 无法启动。

可能性二。Windows 不能适应某个内存块。换句话说，它“挑剔”，它拒绝某个内存块。你可以认为这是 Windows 的 bug，或者你认为这是 Windows 的 “要求”也行，反正不管怎么称呼它，实质都一样，都是 “Windows 不明不白地拒绝使用某个内存块”。既然 Windows 是必须启动的，那这就是无条件要执行的命令，必须适应它，不适应就得死。其实你已经找到办法了（这是你作为一个开发者，具有不同于一般人的那种便利吧；一般人不一定能找到这个办法），你已经知道如何在新版下让它顺利通过了。你已经适应了，它难不住你！

从哲学上讲，这种情况以前也碰到过。那就是你以前可能很熟悉的 --e820cycles 参数。有些变态的主板（或变态的显卡驱动程序）必须要有这个变态的 --e820cycles 参数才行！否则就死给你看！！变态的主板或驱动程序，能挡得住 grub4dos 的前进？能让 grub4dos 退回到不曾具有 --e820cycles 参数的老版本、旧时代，而永远不前进？挡不住吧？

似曾相识吧？今天你遇到的是类似的情况了。你所遇到的这个变态的情况，也不应该挡住 grub4dos 的前进。换句话说，grub4dos 不该退回到 “从低到高搜索可用内存块”的旧时代。

以上就是我全部的答复。我力求答复得全面、细致（不知做到没有），希望我的答复能够易于理解、让人看懂。

不厌其烦地再次声明：以上言论只代表我个人。永远都是这样，我不代表其他任何人（希望以后不需要类似的声明了，太累）。

不点

mdyblog 发表于 2017-8-26 07:33
谢谢详细的回答！！！

没有特别的用法。 都是规范的用法。连 --top都不用(兼容的原因)。

我个人不推荐你采用这样的办法。这会带来你意想不到的问题，有陷阱，你躲不过。

我建议你采取下面两种办法之一：

1、完全采用旧版，永不更新。

2、采用新版，你自己亲自修改代码，让搜索到第一个内存块（最低的内存块）就结束搜索。而不是像你现在那样，简单地、整盘地替换为旧版的 map_func——这样做陷阱很多，会遇到其他很多隐蔽的麻烦，让你自己以后找不到问题的根源。就是说，可以局部地修改 map_func，不要全盘采用旧版的 map_func，因为有陷阱，有不兼容的暗礁，将来撞上，不划算。


不过需要补充说明的是，从高到低搜索所带来的好处，你也得不到了。就是说，假如某个机器碰巧只适应于 “从高到低”搜索，那么你的程序就要失败了。只是简单提醒一下，因为你是开发者，你自己也应该会很明白的。

不点

2011yaya2007777 发表于 2017-8-26 08:23
你手动指定内存块到
Usable RAM: Base: 0x20200000, Length: 0x1FE00000

从报告来看，我猜，问题的根源有可能是因为这个长度为 0x1000 的内存块（即 Usable RAM: Base: 0xD6FFF000, Length: 0x1000）不适合用作内存盘。这有可能是 BIOS 的 bug（不是故意的），也有可能是厂商在 BIOS 中故意制造的陷阱（攻击性的）。

yaya 可以考虑增加一个 map 参数（比如 min-block-size），控制搜索时所使用的最小内存块的长度（单位是 512 字节块）。对等地，也可以增加另一个 map 参数（比如 max-block-size），控制搜索时所使用的最大内存块的长度（单位是 512 字节块）。

有了这样的限定参数，那么用户自己就可以很方便地躲过那些 BIOS 的 bug （或厂商恶意制造的陷阱）了。


补充：用 block-size 这个词汇，容易误导（让人理解错误）。可以改为 range-size、block-length 或别的词汇。


再补充：

继续猜测。问题的真正根源，有可能是“某个内存块被用光”造成的。注意到这个长度为 0x1000 的内存块刚好被这个内存盘用光。grub4dos 的 int15 处理程序让这个内存块的“剩余可用内存量”等于 0，这可能让 Windows “糊涂”了，或“不适应”了。接下来我准备试着修复一下 int15 代码，让它不产生“长度为 0 的内存块”，这样或许问题就解决了。请等待我的（试验性的）修复。