无忧启动论坛

标题: 关于 GRUB4DOS 用户使用内存管理 [打印本页]

作者: 2011yaya2007777 时间: 2017-1-14 18:37
标题: 关于 GRUB4DOS 用户使用内存管理
本帖最后由 2011yaya2007777 于 2017-2-9 09:07 编辑

本次更新，完善了用户使用内存的管理。可以分配内存、释放内存以及重新整理内存（碎片整理）。
增加参数：

最低可使用内存设置为 0x10100 扇区，即 0x2020000 字节，即 32MB+128KB。因为底部内存已经被 GRUB4DOS 程序本身使用。
前一段有帖子说，按常规分配内存位置太低，与程序内部使用交错，必须使用 --top 参数。真正的原因应当是，以前设置的最低可使用内存是 1MB，在这之上，程序本身与用户共同使用内存，难免区域交错。
请大家测试。

2017-02-09
自我感觉已经基本完善。在0PE运行正常。兼容性好，不需要修改批处理。请广泛测试，近期将正式上传官网。

grub4dos-0.4.6a-2017-02-09.7z.rar

289.14 KB, 下载次数: 15, 下载积分: 无忧币 -2

作者: 窄口牛 时间: 2017-1-14 18:48
又是第一个，哈哈

作者: 古今一梦 时间: 2017-1-15 11:14
2007-01-15什么鬼

作者: 窄口牛 时间: 2017-1-15 18:56
又更新了？

作者: 2011yaya2007777 时间: 2017-1-15 20:42
修正了一个缺陷

作者: 2011yaya2007777 时间: 2017-1-22 09:37
根据 issues 132 反馈，优先分配高位块内存的策略欠佳。
以前大部分内存不超过4GB，所以优先高低内存块看不出问题。现在超过4GB内存块的越来越多，使用旧的批处理模块，有可能产生问题。
比如使用移动、比较、填充32位指令就不适合超过4GB的内存。

另外，什么时候使用 --mem=xxx 指定映射内存基地址？此时使用尺寸不按实际需求，而要一直分配到内存块结尾？

作者: 窄口牛 时间: 2017-1-22 09:54
加油，你们下载了的，没有测试结果汇报吗？

作者: 不点 时间: 2017-1-22 17:11

2011yaya2007777 发表于 2017-1-22 09:37
根据 issues 132 反馈，优先分配高位块内存的策略欠佳。
以前大部分内存不超过4GB，所以优先高低内存块看 ...

如果有必要的话，你可以撤销我的补丁。

新版需要配合 map --mem-max=0x800000 才能够控制使用不超过 4G 的内存地址。这条命令应该单独执行，执行一次即可，后续的 map --mem 命令都将使用这一控制参数。

暴露出的问题，不是 grub4dos 的问题。本质上是具体的那些软件不支持 4G 以上内存的问题。

以下两种方案，你觉得哪个合适就用哪个：

1、彻底恢复为以前的设置，保持兼容性。
2、彻底调整过来，总是从高端搜索内存块，但把默认值调整为与 map --mem-max=0x800000 等价，这样就不会使用位于 4G 以上的内存块。不过，当用户需要使用 4G 以上内存块时，还得再执行一条 map --mem-max=0，这是恢复为 64 位的内存访问，可以访问 4G 以上内存块。不过这样也麻烦，会把用户弄得更糊涂。

作者: 2011yaya2007777 时间: 2017-1-22 19:28
好吧,我再考虑考虑.

作者: 不点 时间: 2017-1-22 21:20
有两个方面的情况，我觉得有必要陈述一下，以便 yaya 可以综合考虑，权衡利弊，作出判断。

我想强调的第一点是：

从高端向低端搜索内存块是合理的。低端内存块很容易造成冲突。冲突大致有以下几个方面：

1、与 grub4dos 的内核代码冲突。即，与 32M 低端内存冲突。
2、与 grub4dos 的外部程序冲突。外部程序的进程空间在 32M 以上，长度是动态的，不确定。
3、低端内存块使用频率太高，很多程序都使用这个低端的内存碎片，造成拥挤，而拥挤本身就容易发生冲突。

我要强调的第二点是：

即便是以前的版本（从低端搜索内存块），也有可能使用到 4G 以上的内存块。不要忽视了这一点。

举例来说，假定低端有 4 个 500M 的内存块，高端有个 1G 的内存块。用户 IMG 是 600M，则肯定加载到高端了。就是说，即便用户不曾使用 --top 参数，也有可能把 IMG 加载在 4G 以上的内存块上，除非用户使用 --mem-max 参数来控制内存块的范围。

所以，那些不支持 4G 以上高端内存的系统或软件，根本就是 bug，它根本就不可能顺利运行。只要用户的内存布局是碎片化的，那么总会碰上问题。即便暂时没人报告 bug，那也是理论上存在 bug，终究是个 “大坑”，或 “定时炸弹”。总之，“没被用户报告 bug 的”，不等于是 “没问题的”。

作者: 2011yaya2007777 时间: 2017-1-23 08:14
本帖最后由 2011yaya2007777 于 2017-1-23 08:45 编辑

不点说的有道理。是否可以这样理解：默认允许使用4G以上内存（当然是存在的话），默认从高内存块分配。
用户使用--mem-max 来限制使用4G以上内存。同时参数 --top 废除。

作者: 不点 时间: 2017-1-23 12:15

2011yaya2007777 发表于 2017-1-23 08:14
不点说的有道理。是否可以这样理解：默认允许使用4G以上内存（当然是存在的话），默认从高内存块分配。
用 ...

好的，继续分析这个问题，谈谈我的思路，供 yaya 参考。

以前在默认时，也一直是允许使用 4G 以上的内存的。以前只不过是用 --top 参数来控制从高端搜索内存块罢了——即 “按从高到低的顺序来搜索可用内存块”。我的那个补丁已经让默认时就使用 --top 的动作了。就是说，无论有没有 --top，都是这样操作的。我认为这样操作是没有坏处的；唯一的 “坏处” 就是，让那些有 bug 的软件（即，那些不支持高端内存的软件）暴露出问题，从而不能运转了。这是 “坏处” 吗？恐怕在不同的侧重点、不同的视角下，结论也不同。因此，我认为，这已经纯粹是哲学问题了。如果侧重点是兼容那些 buggy 的软件，那就恢复为原先的代码。前面说了，其实即使你想兼容，也兼容不了。那些 buggy 的软件，即使在旧的代码下，仍旧有很大的可能会使用到 4G 以上的内存块，因此照样是失败。彻底解决的办法，那就是不去兼容他们。

另一方面，--top 参数也没必要删除，毕竟它存在过，也有人用它。我的补丁就是，让默认采用 --top 的操作，而 --top 也是合法的参数，使用它不会报错。但打了我的补丁的新版已经是不需要使用 --top 了，即，无论有没有 --top，都是执行原先的 --top 的动作。

作者: 不点 时间: 2017-1-23 20:55
本帖最后由不点于 2017-1-23 22:34 编辑

今天洗澡时，不经意间有个想法，觉得有戏。但由于岁数大了爱忘事，于是中断了洗澡，过来发帖。

还好，思路仍是畅通的，趁着老年痴呆症还没表现出来，赶紧打字。

目前的情况是已经把搜索的顺序调整为“自上而下”了，这个是正确的做法，这一点，也基本算是没有疑问了。

然而，由于默认时是允许使用 4G 之上的高位内存块的，所以才让那些 buggy 的软件变成无法正常运行了。

嘿嘿，还真有 “两全其美” 的策略。

关键就在于，要把 --mem-max=0x800000 也设置成默认的，这样就照顾到那些 buggy 的软件了。

可能有人要说：“既然默认时不支持 4G 以上的内存块，那么，那些需要使用高位内存的用户们不就惨了吗？他们的菜单是不是就得被迫修改了？”

注意，问题的精华之处就在这里了，盯紧，别眨眼。

记得不？经过上次调整以后，--top 就成了摆设，有它没它都一样。然而我们可以把它捡起来，挪作他用。

我们修改 --top 的含义。它原来的含义是“自上而下”搜索，并无其他含义。

现在把它的含义重新定义为：“开启 4G 以上的高位内存块支持”。

哇！如此一来，是不是所有的“经络”都打通了？全都理顺了！

重新定义 --top 的含义，究竟行不行？我们仔细分析一下。

我们从用户使用它的角度来分析。

先前用户在什么情况下需要用 --top 参数？其实，大量的用户恰恰是误解了 --top 的含义，不知道 --top 是“自上而下”搜索之意，而误以为 --top 就是“开启高位内存支持”的。

好的，不管用户究竟是误解了还是没误解；假如用户想要支持 4G 以上的高位内存块，他都会在他的菜单中添加 --top 参数。

我们现在“偷梁换柱”、“暗渡陈仓”，彻底调整过来以后发现，用户原先的菜单不用任何改动，依然有效！

为了明确起见，下面列表对比一下调整前后的变化。

	调整前	调整后
搜索方向	默认时，从低到高；加上 --top 参数以后，从高到低	只能从高到低，不能从低到高
高位内存	总是支持，除非用 --mem-max=0x800000 才能保证不使用高位内存	默认时不支持高位内存，需要添加 --top 参数才开启高位内存支持
--top	含义是按“从高到低”的顺序搜索可用内存块	含义是“允许使用高位内存”

目前思路又稍稍改进了一点，打算通过类似于 is64bit 的方式来修改 --top 的代码，不必修改 --mem-max 的默认值。

明天我按照这个思路制作一个补丁。今天累了，就先歇歇吧。

作者: 2011yaya2007777 时间: 2017-1-24 07:53
本帖最后由 2011yaya2007777 于 2017-1-24 08:43 编辑

不点太敬业了，令人敬佩！
现在这样处理非常好。既可以合理完善，又可以保持兼容。
昨天我也想到使用 --top 来开启4G内存支持。现在我们的思路完全统一了。
使用 --top 是一次有效，而使用--mem-max后不复位的话则是长期有效。
--mem-max参数一般用户也不怎么使用。不鼓励用户使用--mem-min 及 --mem-max参数。

有你坐镇指挥就踏实了，其他事情我来处理。

作者: 不点 时间: 2017-1-24 14:21
花了几个小时，总算调整完成了。我自己还没有试验，请大家测试，看看会不会有什么“未曾料想”的异常情况。

调整后，--top 就像 is64bit 那样，用来控制是否采用 4G 之上的高位内存。is64bit 是全局变量，但 --top 属于局部变量，只在 map 命令行有效，而且只是对本次 map 生效，不影响其他 map 命令。如果需要把 img 映射在高位内存区，必须在 map 命令行中添加 --top 参数。如果 map 命令行没有 --top 参数，则与此 map 命令相应的 IMG 不会被加载在高位内存区。

与 --rehook 有关的代码也进行了调整。另外还强化了某些代码的健壮性，比如，处理了 map->BaseAddr + map->Length 相加之后可能溢出的情况。溢出之后，相加的结果有可能为 0。如果某 BIOS 有 bug（或者故意制造 bug），那么溢出后，相加的结果甚至可能会是大于 0 的。这些情况都考虑了，应该很健壮了。

如果 yaya 最终决定采用的话，ChangeLog 可以写：--top meaning changed to "allowing memory blocks above address of 4GB".

@yaya

我是帮 bean、chenall 和你，不要搞错啦。在 bean、chenall 接管这个项目以后，我曾经承诺过，我一定尽力提供帮助。现在对你也是一样的。我如果能够做到“不食言”，那我就觉得很自豪了。你们个个都是强手，完成了很多出色的工作，那些工作我都难以胜任。现在你们是“主”，我是“客”；grub4dos 如何发展？grub4dos 发展得好不好？我都不管了，我都不负责了；责任已经转嫁到你们头上了。我不认为有谁能够指挥你们，都是你们各位自己在指挥自己。公平来讲，我当初负责这个项目的时候，也是自己指挥自己。通过最近一年的艰难思考和认识，我终于发现，这世界是没有救世主的。一切的一切，都得靠自己的努力去达成。不能依靠某个巨头。当初我作为 grub4dos 的维护者，其实质也就是在“拯救自己”、为自己的利益而“奔命”罢了。开源是对终端用户有利的事业。“谁是我们的敌人，谁是我们的朋友”，这个“大是大非”的问题，是从事一切工作的首要问题。你们从事开源软件的开发，建设自己的美好家园，那也是符合我的利益的。现在我力不从心了，但如果我能尽到自己的微薄之力、能够给你们提供某些帮助，从而让我能够刷一刷“存在感”，我也就感到满意了（否则，假如“不存在”的话，那对谁都是一件很可怕的事情；我反正不敢去想）。

grub4dos-0.4.6a-2017-01-24.7z.zip

285.03 KB, 下载次数: 33, 下载积分: 无忧币 -2

让 --top 代表“启用高位内存”之意。请测试。

作者: wln 时间: 2017-1-25 21:05
感谢不点大师和yaya大师的辛勤付出，
有了你们的努力，才有了好用的软件
衷心地感谢！

作者: 不点 时间: 2017-1-25 22:18

wln 发表于 2017-1-25 21:05
感谢不点大师和yaya大师的辛勤付出，
有了你们的努力，才有了好用的软件
衷心地感谢！

谢谢。您下载试用了吗？上面这个最新的编译测试版，能正常工作吗？

新版有可能是迄今为止最好的版本，当然，如果出现失误的话，也可能无法正常运行。

有条件的朋友可以试试。

作者: asqw101451 时间: 2017-1-27 10:07

不点发表于 2017-1-25 22:18
谢谢。您下载试用了吗？上面这个最新的编译测试版，能正常工作吗？

新版有可能是迄今为止最好的版本， ...

不知道怎么测试啊

作者: 不点 时间: 2017-1-27 17:59

asqw101451 发表于 2017-1-27 10:07
不知道怎么测试啊

谢谢。抱歉我没说清楚：正常使用，即是测试。如果不出现问题，那就是测试成功；如果表现出某个以前不曾发生过的新问题，那就是测试失败。

作者: asqw101451 时间: 2017-1-29 15:31

不点发表于 2017-1-27 17:59
谢谢。抱歉我没说清楚：正常使用，即是测试。如果不出现问题，那就是测试成功；如果表现出某个以前不曾发 ...

不点大师客气了，我下载是正常使用的

image.jpg (91.92 KB, 下载次数: 141)

作者: gmy 时间: 2017-2-1 11:41
这个功能很好，为何不再更新0.4.5c？

作者: 不点 时间: 2017-2-1 21:15

gmy 发表于 2017-2-1 11:41
这个功能很好，为何不再更新0.4.5c？

我随便发表一点观感。

一、grub4dos 的项目空间以前很不稳定，chenall 接管以后，空间比较稳定。chenall 为此付出了金钱和心血。但 chenall 忙啊，越来越少来这里处理问题了。以前好多开发维护者都不来了，比如 bean、climbing、roy、gandalf 等等。你葛大侠也很少露面。

二、现在 yaya 来的时候还算多，所以，0.4.6 更新也频繁。

三、据我观察，x86 下的开发，越来越冷却了。在以前，开发者们跪着乞求用户前来使用软件和报告 bug。但现在情况有了微妙变化，就连开发者自己都不积极了。很可能情况要颠倒过来了：用户可能需要大声呼喊，开发者也不一定答应一声。甚至用户被迫自己动手，也说不了呢。

时代就是这样在不知不觉、悄无声息地变迁着。睁大眼睛，别睡觉，一旦睡觉，或者小憩一下，当你醒来时，发现世界变了，有可能大吃一惊。

作者: 2011yaya2007777 时间: 2017-2-2 08:12
再请教不点：
关于“--mem=N”，N 为正数的情况。
这种情况指定了内存映射的基地址。当使用 rehook 指令时，这个指定的内存映射基地址被更改了。
这似乎不妥。

作者: 不点 时间: 2017-2-2 10:44
本帖最后由不点于 2017-2-3 11:53 编辑

2011yaya2007777 发表于 2017-2-2 08:12
再请教不点：
关于“--mem=N”，N 为正数的情况。
这种情况指定了内存映射的基地址。当使用 rehook 指令 ...

是的，那样的情况不适合与 map --rehook 一起使用。grub4dos 就像 linux 那样，给用户的自由度太高，难免会因考虑不周而出问题。我刚在知乎上看 windows 和 linux 的区别，有所启发。grub4dos 既想学习 windows 的傻瓜化，给用户提供面面俱到的服务，有时候又像 linux 那样需要用户投入精力去了解内幕。

我的"哲学性" 意见是：能解决就解决，解决不了就放任它。大约对待所有的事情都是这一个办法。当能够找到更好的办法时，就努力完善。若暂时找不到，也可悬挂着。

哦，补充一下。固定地址的用法，本来就不是重点，它本来就是临时性的目的，可以解读为"已经公开了的未公开功能"，或者解读为 "不该公开的已公开功能"。有点老年痴呆了，可能词不达意。

今天再补充一点。问题出来了、问题发现了，这是好事。说实在话，我一直忽略了这样的问题，不曾想到这个问题的存在。说明 yaya 的逻辑思路清晰，比我严谨，比我更适合搞电脑软件的开发。bean，chenall 好像都是比较专业的，我猜 yaya 可能也有专业背景。那么，有你们这样的人继续开发，我觉得是很理想的。至于说解决的方法，那好像就不用我再多费脑筋了，相信 yaya 会有自己的办法。个人认为，你可以大刀阔斧地干；你认为怎么合适，就怎么做。举例来说，如果你觉得有必要，你可以干脆撤掉 --mem=<正数> 的功能。或者在文档中提及这一问题，提醒用户不要在 --mem=<正数> 存在的情况下使用 rehook。

现在对我自己进行“自我评价”一下。当初我偶然启动了这个项目，几年下来，说实在话，费了不少时间、精力，连身体也受伤了。但这个项目的技术困难，还真没有；就算有，我也接触不到。不就是 BIOS 调用嘛，只要查看调用规范，就搞定了。然而为什么会受伤呢？是处理 bug，就是这个造成的。那 bug 主要是 BIOS 的，是人为制造的，所以难度高得很，摸不着边。今天来回顾的话，我觉得技术上没什么工作要我做；我也做不了。但我不后悔开启这个项目。这个项目让我有很多收获。我最大的收获是了解了“人为制造 bug” 这样一件事情，揭开了它的面纱，露出了它的真容，确定了它的存在，不再模棱两可，不再仅仅停留在怀疑阶段。另一个额外的收获（比刚才所说“最大”的收获还要大），那就是，得到了人生的锤炼，认识的提高，了解了自己人性的弱点，知道了自己的狭隘，并开始去克服；这对于我现实生活质量的提高，至关重要；这是从事这个项目以来对我带来的实实在在的好处，十分宝贵，将影响我一生，甚至这影响会扩大到我的家人，让他们也受益。

作者: 2011yaya2007777 时间: 2017-2-3 11:46
补丁已经上传官网.

作者: 2011yaya2007777 时间: 2017-2-9 10:16
grub4dos-0.4.6a-2017-02-04.7z版本似乎仍然有问题。
比如在4G以下内存有4个碎片，分别是 N0，N1，N2，N3。
以前是首项分配N0碎片。现在是首项分配N3碎片。
错误出现在 int15/AX=e801。它似乎应当返回N0最低可用内存使用情况，现在却返回了N3可用内存的情况。

作者: 不点 时间: 2017-2-9 10:55
本帖最后由不点于 2017-2-9 11:13 编辑

2011yaya2007777 发表于 2017-2-9 10:16
grub4dos-0.4.6a-2017-02-04.7z版本似乎仍然有问题。
比如在4G以下内存有4个碎片，分别是 N0，N1，N ...

长期没有接触，不太了解情况了。说说我的看法。

int15 各个子功能，应该不会受到 e820 碎块影响才对。

当用户调用 int15/e801 时，grub4dos 的 int15 接管了控制。grub4dos 应该怎么处理呢？应该这样：首先用 ROM int15 入口调用一次 e801 功能，然后，修改返回值，从返回值当中，去除 img 占用的部分。

如果不是这样做的，那就是有 bug 了。这部分程序代码主要是我写的，难免会出毛病。你发现了这个问题，说明你已经很辛苦地追踪到这里了，不容易。

期待你把它修复好，理顺，那么 grub4dos 也就越来越健壮了。

补充：ROM 的 e801 代码其本身也有可能是错误的。尤其是当 e820 接口存在的情况下，e801 接口就可能是无效的。当存在 e820 接口时，有建议称，应用程序应该首先使用 e820 接口。但我们很难知道微软遵循什么规范，以及微软是否 “首先使用 e820 接口”。如果微软遵循那样的策略，那么，在 e820 接口存在的情况下，“e801 问题” 应该不是个问题。【再补充】其实谈不上微软使用什么规范。微软甚至可以破坏规范。所以，谁也说不清真理是什么，以及真理在哪里，大概只有 “走着瞧着”、“边走边看”、“摸着石头过河”。

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