无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站广告联系 微信:wuyouceo QQ:184822951
查看: 5991|回复: 26

关于 GRUB4DOS 用户使用内存管理

[复制链接]
发表于 2017-1-14 18:37:00 | 显示全部楼层 |阅读模式
本帖最后由 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:13 来自手机 | 显示全部楼层
又是第一个,哈哈
回复

使用道具 举报

发表于 2017-1-15 11:14:57 | 显示全部楼层
2007-01-15什么鬼
回复

使用道具 举报

发表于 2017-1-15 18:56:57 来自手机 | 显示全部楼层
又更新了?
回复

使用道具 举报

 楼主| 发表于 2017-1-15 20:42:47 | 显示全部楼层
修正了一个缺陷
回复

使用道具 举报

 楼主| 发表于 2017-1-22 09:37:53 | 显示全部楼层
根据 issues 132 反馈,优先分配高位块内存的策略欠佳。
以前大部分内存不超过4GB,所以优先高低内存块看不出问题。现在超过4GB内存块的越来越多,使用旧的批处理模块,有可能产生问题。
比如使用移动、比较、填充32位指令就不适合超过4GB的内存。

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

点评

如果有必要的话,你可以撤销我的补丁。 新版需要配合 map --mem-max=0x800000 才能够控制使用不超过 4G 的内存地址。这条命令应该单独执行,执行一次即可,后续的 map --mem 命令都将使用这一控制参数。 暴露  详情 回复 发表于 2017-1-22 17:11
回复

使用道具 举报

发表于 2017-1-22 09:54:01 来自手机 | 显示全部楼层
加油,你们下载了的,没有测试结果汇报吗?
回复

使用道具 举报

发表于 2017-1-22 17:11:02 | 显示全部楼层
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 以上内存块。 不过这样也麻烦,会把用户弄得更糊涂。

回复

使用道具 举报

 楼主| 发表于 2017-1-22 19:28:13 | 显示全部楼层
好吧,我再考虑考虑.
回复

使用道具 举报

发表于 2017-1-22 21:20:22 | 显示全部楼层
有两个方面的情况,我觉得有必要陈述一下,以便 yaya 可以综合考虑,权衡利弊,作出判断。

我想强调的第一点是:

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

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

我要强调的第二点是:

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

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

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




回复

使用道具 举报

 楼主| 发表于 2017-1-23 08:14:19 | 显示全部楼层
本帖最后由 2011yaya2007777 于 2017-1-23 08:45 编辑

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

点评

好的,继续分析这个问题,谈谈我的思路,供 yaya 参考。 以前在默认时,也一直是允许使用 4G 以上的内存的。以前只不过是用 --top 参数来控制从高端搜索内存块罢了——即 “按从高到低的顺序来搜索可用内存块”。  详情 回复 发表于 2017-1-23 12:15
回复

使用道具 举报

发表于 2017-1-23 12:15:37 | 显示全部楼层
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:56 | 显示全部楼层
本帖最后由 不点 于 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 的默认值。

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

回复

使用道具 举报

 楼主| 发表于 2017-1-24 07:53:08 | 显示全部楼层
本帖最后由 2011yaya2007777 于 2017-1-24 08:43 编辑

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

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

使用道具 举报

发表于 2017-1-24 14:21:50 | 显示全部楼层
花了几个小时,总算调整完成了。我自己还没有试验,请大家测试,看看会不会有什么“未曾料想”的异常情况。

调整后,--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 代表“启用高位内存”之意。请测试。

回复

使用道具 举报

发表于 2017-1-25 21:05:54 | 显示全部楼层
感谢不点大师和yaya大师的辛勤付出,
有了你们的努力,才有了好用的软件
衷心地感谢!

点评

谢谢。您下载试用了吗?上面这个最新的编译测试版,能正常工作吗? 新版有可能是迄今为止最好的版本,当然,如果出现失误的话,也可能无法正常运行。 有条件的朋友可以试试。  详情 回复 发表于 2017-1-25 22:18
回复

使用道具 举报

发表于 2017-1-25 22:18:05 | 显示全部楼层
wln 发表于 2017-1-25 21:05
感谢不点大师和yaya大师的辛勤付出,
有了你们的努力,才有了好用的软件
衷心地感谢!

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

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

有条件的朋友可以试试。

点评

不知道怎么测试啊  详情 回复 发表于 2017-1-27 10:07
回复

使用道具 举报

发表于 2017-1-27 10:07:43 | 显示全部楼层
不点 发表于 2017-1-25 22:18
谢谢。您下载试用了吗?上面这个最新的编译测试版,能正常工作吗?

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

不知道怎么测试啊

点评

谢谢。抱歉我没说清楚:正常使用,即是测试。如果不出现问题,那就是测试成功;如果表现出某个以前不曾发生过的新问题,那就是测试失败。  详情 回复 发表于 2017-1-27 17:59
回复

使用道具 举报

发表于 2017-1-27 17:59:51 | 显示全部楼层
asqw101451 发表于 2017-1-27 10:07
不知道怎么测试啊

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

点评

不点大师客气了,我下载是正常使用的  详情 回复 发表于 2017-1-29 15:31
回复

使用道具 举报

发表于 2017-1-29 15:31:18 来自手机 | 显示全部楼层
不点 发表于 2017-1-27 17:59
谢谢。抱歉我没说清楚:正常使用,即是测试。如果不出现问题,那就是测试成功;如果表现出某个以前不曾发 ...

不点大师客气了,我下载是正常使用的
image.jpg
回复

使用道具 举报

发表于 2017-2-1 11:41:22 | 显示全部楼层
这个功能很好,为何不再更新0.4.5c?

点评

我随便发表一点观感。 一、grub4dos 的项目空间以前很不稳定,chenall 接管以后,空间比较稳定。chenall 为此付出了金钱和心血。但 chenall 忙啊,越来越少来这里处理问题了。以前好多开发维护者都不来了,比如 b  详情 回复 发表于 2017-2-1 21:15
回复

使用道具 举报

发表于 2017-2-1 21:15:48 | 显示全部楼层
gmy 发表于 2017-2-1 11:41
这个功能很好,为何不再更新0.4.5c?

我随便发表一点观感。

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

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

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

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

回复

使用道具 举报

 楼主| 发表于 2017-2-2 08:12:19 | 显示全部楼层
再请教不点:
关于“--mem=N”,N 为正数的情况。
这种情况指定了内存映射的基地址。当使用 rehook 指令时,这个指定的内存映射基地址被更改了。
这似乎不妥。

点评

是的,那样的情况不适合与 map --rehook 一起使用。grub4dos 就像 linux 那样,给用户的自由度太高,难免会因考虑不周而出问题。我刚在知乎上看 windows 和 linux 的区别,有所启发。grub4dos 既想学习 windows 的傻  详情 回复 发表于 2017-2-2 10:44
回复

使用道具 举报

发表于 2017-2-2 10:44:15 | 显示全部楼层
本帖最后由 不点 于 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” 这样一件事情,揭开了它的面纱,露出了它的真容,确定了它的存在,不再模棱两可,不再仅仅停留在怀疑阶段。另一个额外的收获(比刚才所说“最大”的收获还要大),那就是,得到了人生的锤炼,认识的提高,了解了自己人性的弱点,知道了自己的狭隘,并开始去克服;这对于我现实生活质量的提高,至关重要;这是从事这个项目以来对我带来的实实在在的好处,十分宝贵,将影响我一生,甚至这影响会扩大到我的家人,让他们也受益。
回复

使用道具 举报

 楼主| 发表于 2017-2-3 11:46:53 | 显示全部楼层
补丁已经上传官网.
回复

使用道具 举报

 楼主| 发表于 2017-2-9 10:16:45 | 显示全部楼层
grub4dos-0.4.6a-2017-02-04.7z版本似乎仍然有问题。                                               
比如在4G以下内存有4个碎片,分别是 N0,N1,N2,N3。                                               
以前是首项分配N0碎片。现在是首项分配N3碎片。                                               
错误出现在 int15/AX=e801。它似乎应当返回N0最低可用内存使用情况,现在却返回了N3可用内存的情况。

点评

长期没有接触,不太了解情况了。说说我的看法。 int15 各个子功能,应该不会受到 e820 碎块影响才对。 当用户调用 int15/e801 时,grub4dos 的 int15 接管了控制。grub4dos 应该怎么处理呢?应该这样:首先用  详情 回复 发表于 2017-2-9 10:55
回复

使用道具 举报

发表于 2017-2-9 10:55:17 | 显示全部楼层
本帖最后由 不点 于 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 问题” 应该不是个问题。【再补充】其实谈不上微软使用什么规范。微软甚至可以破坏规范。所以,谁也说不清真理是什么,以及真理在哪里,大概只有 “走着瞧着”、“边走边看”、“摸着石头过河”。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1 )

闽公网安备 35020302032614号

GMT+8, 2024-3-29 14:52

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表