无忧启动论坛

标题: 老版本源码的获取 [打印本页]
作者: 红毛樱木    时间: 2016-11-3 21:42
标题: 老版本源码的获取
这个是2013-04-19版本的源码获取地址
svn co -r 340 http://grub4dos-chenall.googlecode.com/svn/trunk grub4dos


记得之前是改成
svn  co  -r  340  https://github.com/chenall/grub4dos grub4dos
这样是可以获取的。
但是现在获取的不对了。。。。
作者: 2012xxxooo123    时间: 2016-11-3 22:08
谢谢 正需要这个东西呢
作者: 不点    时间: 2016-11-3 23:05
老版本，我估计开发者、维护者是不愿意支持的，也没有精力去支持。就连 pseudo 的 0pe 都采用新版本了。

假如你一直采用老版本，那么，你制作的软件还有人敢用吗？我是说，了解这一情况的人还敢用吗？用起来放心吗？

作者: 红毛樱木    时间: 2016-11-4 00:20
不点 发表于 2016-11-3 23:05
老版本，我估计开发者、维护者是不愿意支持的，也没有精力去支持。就连 pseudo 的 0pe 都采用新版本了。

...

就想你一直追着XP不放手一样。总有这么点需求的。
作者: 不点    时间: 2016-11-4 01:41
红毛樱木 发表于 2016-11-4 00:20
就想你一直追着XP不放手一样。总有这么点需求的。

无言以对，我输了。
作者: chenall    时间: 2016-11-4 08:44
github 在国内访问不太顺畅

你可以看一下更新记录，正常情况下以前googlecode上的代码都有转到github上的。

用git来获取
作者: 不点    时间: 2016-11-4 09:21
随着时间一天天过去，新版的稳定性也在经历考验。时间每增加一天，新版的稳定性就更有保障，那么新版存在 bug 的几率就会降低。因为新版基本不会增加什么功能了，每次更新基本都是 bug 修复。

因此我认为，假如某个人可以用旧版而无法成功使用新版，那么，有很大的可能性是他自己的用法出了问题。举例来说，这种情况出现很多次，就是，有人在旧版上不需要 map --e820cycles=... 但在新版却必须使用这个控制参数。当他在新版 grub4dos 下用旧的（不含 map --e820cycles=...）的菜单时，启动 Windows 就可能出现蓝屏。当他不了解这一情况时，他认为新版有 bug。其实不是的，而是 Windows XP 下的某个（好像是 Intel 的吧，记不清了）显卡驱动程序的 bug。

grub4dos 的 bug 是否全部排除干净了？谁也不敢说这个话。因此，grub4dos 有可能仍然存在 bug，并且正好被某个用户撞上，或者说 “逮住”。这就有两条路可选。一条路是紧紧抓住 bug 的尾巴不让它逃脱（需要付出时间和耐力）。另一条路就是不去追究（没有时间和精力，或者没有兴趣），依旧使用某个旧版。至于说两条路要怎样选择，那完全在于每个人的意向了。我认为，趁着 grub4dos 现在还有人维护这个大好时机，应该选择第一条路。假如等到以后的某一天，grub4dos 停止维护了，那时候，你再想报告 bug、排解 bug，那时可能就得不到响应了。

作者: 红毛樱木    时间: 2016-11-4 14:23
本帖最后由 红毛樱木 于 2016-11-4 15:16 编辑

现在可以了。。。
作者: 2011grassll    时间: 2016-11-4 15:01
本帖最后由 2011grassll 于 2016-11-4 15:03 编辑

0.4.5c的2012-10-02版本起,等待timeout时间时,占用cpu很高.如果这个问题解决当然是要用新版的,不过不点大大已经说不可能了
另外,2012-06-19版只有二进制,似乎没法得到源码了?
作者: 红毛樱木    时间: 2016-11-4 15:16
本帖最后由 红毛樱木 于 2016-11-4 15:19 编辑
2011grassll 发表于 2016-11-4 15:01
0.4.5c的2012-10-02版本起,等待timeout时间时,占用cpu很高.如果这个问题解决当然是要用新版的,不过不点大大 ...

svn  co  -r  301  https://github.com/chenall/grub4dos grub4dos


20120619源码.7z (697.47 KB, 下载次数: 7)
作者: 不点    时间: 2016-11-4 15:17
2011grassll 发表于 2016-11-4 15:01
0.4.5c的2012-10-02版本起,等待timeout时间时,占用cpu很高.如果这个问题解决当然是要用新版的,不过不点大大 ...

我考虑了一下，这个问题可以解决。

就是，增加一个控制位，相应地增加一个控制命令，解决这个问题。

这是个已知问题，报告此问题的人不多，所以，也就没有特别给予重视（或者说照顾）。

增加控制命令以后，默认时仍旧保持现在的状况。当执行控制命令时，恢复到旧版的状况。

如果这样处理的话，你觉得行不行？

作者: 2011grassll    时间: 2016-11-4 15:36
不点 发表于 2016-11-4 15:17
我考虑了一下，这个问题可以解决。

就是，增加一个控制位，相应地增加一个控制命令，解决这个问题。

如果能解决那就太好了，也要谢谢各位大大
作者: 2011grassll    时间: 2016-11-4 16:03
红毛樱木 发表于 2016-11-4 15:16
svn  co  -r  301  https://github.com/chenall/grub4dos grub4dos

谢谢.给的压缩包用./configure找不到stage2.c。用svn取的正确，只是在linux下和mingw32下,./configure都在检查objcopy时出错。看来我的工具链有些问题。
作者: 不点    时间: 2016-11-4 17:29
我目前没有编译环境。我就说说究竟应该怎么做吧。具体的修改，让 chenall 或 yaya 去做。

我们在这里有个控制字节：

  1. . = EXT_C(main) + 0x5

  3.         /* control byte: pxe, DUCE, tune
  4.          * bit 0 = 1: disable pxe
  5.          * bit 1 = 1: disable keyboard intervention in boot process
  6.          * bit 2 = 1: disable the "unconditional command-line entrance" feature
  7.          * bit 3 = 1: disable geometry tune
  8.          * bit 4 = 1: disable startup cdrom drive look-up.
  9.          */
  10.         .byte        0
复制代码


这个控制字节在内存中的地址是 0x8205——这一点，chenall 和 yaya 都熟悉，就不解释了。

这个控制字节目前用到了 5 个位（位0 至 位4），还有 3 个位没有使用。我们这次就用位5 来控制吧。

因此，把注释改成这样：

  1. . = EXT_C(main) + 0x5

  3.         /* control byte: pxe, DUCE, tune
  4.          * bit 0 = 1: disable pxe
  5.          * bit 1 = 1: disable keyboard intervention in boot process
  6.          * bit 2 = 1: disable the "unconditional command-line entrance" feature
  7.          * bit 3 = 1: disable geometry tune
  8.          * bit 4 = 1: disable startup cdrom drive look-up.
  9.          * bit 5 = 1: enable HLT instruction for checkkey idle loop.
  10.          */
  11.         .byte        0
复制代码


注释只是让人看的，光是改注释是不起作用的。因此，还要改代码。只需把该文件中的三条注释掉的 hlt 指令恢复出来，并改成 “有条件执行” 即可。

三条被注释的 hlt 指令都是类似于这样：

  1. // hlt
复制代码


把它们都改成

  1. call   conditional_hlt
复制代码


当然要写一个 conditional_hlt 的函数，如下：

  1. conditional_hlt:
  2.         // DS should already be 0, but ...
  3.         pushw        $0
  4.         popw                %ds                // just in case DS changed by buggy BIOS
  5.         testb                $0x20, 0x8205        // Enable HLT?
  6.         jz                1f                        // No. Skip the HLT instruction.
  7.         hlt                                        // Yes. Execute the HLT instruction.
  8. 1:
  9.         ret                                        // on return, DS=0
复制代码


至于说这个函数放在哪里呢？可以考虑放在这里：


  2.         .code16

  4. hard_stop:
  5.         sti
  6.         //hlt         <------ 这条被注释的指令，要改成 “call   conditional_hlt”
  7.         jmp hard_stop
  8. 【此处插入 conditional_hlt 函数的代码】
  9.         .code32
复制代码


注意，一定要放在 .code16 编译指令的下面，不可以放在 .code32 编译指令的下面；因为这是 16 位的实模式代码。

好了，代码就修改完成了。

下面说说用户如何使用。

在上述修改完成后，重新编译，发布新版。用户下载新版后，参照以下说明来使用这一功能。

用户在任何时候，只要把内存地址 0x8205 处的一个字节 "OR" 上 0x20, 就达到了 “启用 HLT 指令” 的目的了，也就等于说是恢复旧版的 “cpu 空闲等待” 的功能了。

具体如何使用，可参考 chenall 的 calc 命令的说明。这里的 “OR” 就是逻辑运算符的一种，另外一种逻辑运算符是 “AND”。可以在百度上找到这些资料。

很抱歉，我此刻记不得 calc 命令的用法了。请 chenall 或其它朋友给出具体的指令。
作者: 2011yaya2007777    时间: 2016-11-4 19:04
等待timeout时间时,占用cpu很高

以前看到过反馈。
timeout使用在什么地方？应当是在启动菜单中吧。
实机启动，执行启动菜单是独一任务，cpu占用高也不会影响什么。
虚拟机启动，cpu占用高则有可能影响实机程序的运行速度。不过3-5秒就忍受不了？
作者: 不点    时间: 2016-11-4 19:17
2011yaya2007777 发表于 2016-11-4 19:04
以前看到过反馈。
timeout使用在什么地方？应当是在启动菜单中吧。
实机启动，执行启动菜单是独一任务 ...


奇葩得很，reboot.pro 上也有人长时间工作在 grub4dos 命令行下（大概也在虚拟机下），他也需要这个功能。好像是说，要在命令行下学习、研究 grub4dos 的命令。没办法，这个补丁还真得打上，反正也不影响我们普通人的正常使用。

作者: 2011yaya2007777    时间: 2016-11-4 19:22
好吧。
不过长时间工作在 grub4dos 命令行下（大概也在虚拟机下），他不可能不停地、重复地、循环地执行timeout命令。
作者: 不点    时间: 2016-11-4 19:33
2011yaya2007777 发表于 2016-11-4 19:22
好吧。
不过长时间工作在 grub4dos 命令行下（大概也在虚拟机下），他不可能不停地、重复地、循环地执行ti ...

等待键盘输入的时候，其实就是在调用 checkkey 或 getkey，而 sti 和 hlt 指令就在 checkkey 和 getkey 当中。
作者: 2011yaya2007777    时间: 2016-11-4 20:00
明白了
作者: 2011yaya2007777    时间: 2016-11-5 11:01
本帖最后由 2011yaya2007777 于 2016-11-5 12:01 编辑

已经编译上传。还请 chenall 帮忙发布一下。

grub4dos-0.4.6a-2016-11-05.7z

283.68 KB, 下载次数: 7, 下载积分: 无忧币 -2

作者: 2011grassll    时间: 2016-11-5 13:50
用yaya的编译包,在虚拟机里试了下，read 0x8205的值是0xff00e000,
在menu.lst中,timeout前加: write 0x8205 0xff00e020,确实不占CPU了
不知道0x8205 0xff00e020是不是所有机器都通用的？
作者: 不点    时间: 2016-11-5 14:28
2011grassll 发表于 2016-11-5 13:50
用yaya的编译包,在虚拟机里试了下，read 0x8205的值是0xff00e000,
在menu.lst中,timeout前加: write 0x820 ...

read和write好像是读写 4字节。建议你学习一下 calc 命令，只写入该写的字节，不要写入不该写的字节。
作者: chenall    时间: 2016-11-9 14:07
目前对github的封锁好像越来越厉害了。。。
作者: 红毛樱木    时间: 2016-11-9 17:09
chenall 发表于 2016-11-9 14:07
目前对github的封锁好像越来越厉害了。。。

时好时坏的状态。
作者: 2011grassll    时间: 2016-11-11 08:46
不点 发表于 2016-11-5 14:28
read和write好像是读写 4字节。建议你学习一下 calc 命令，只写入该写的字节，不要写入不该写的字节。

学习了一下calc,似乎也是4字节,用calc确实更好,现在这么用:
calc *0x8205=*0x8205|0x20
作者: hhh333    时间: 2016-11-11 09:43
想问一下calc *0x8205=*0x8205|0x20是不是在总菜单中用一次以后永远有效？如果这样是不是可以放默认菜单中？
作者: 不点    时间: 2016-11-11 10:04
hhh333 发表于 2016-11-11 09:43
想问一下calc *0x8205=*0x8205|0x20是不是在总菜单中用一次以后永远有效？如果这样是不是可以放默认菜单中 ...

控制字节一旦设定，永久有效，直到用 chainloader 或 kernel 加载另一个 grldr 或 grub.exe 之前。

chainloader 或 kernel 加载 grldr 或 grub.exe 后，控制字节就成为默认值（=0）了。

但 configfile 命令不改变控制字节。使用 configfile 加载新的 menu，那么，控制字节仍保持先前的值，不会被强制修改成默认值。

作者: dooso    时间: 2016-11-16 12:58
很好！很强大！












重庆民间道士道法驱邪，收徒弟



欢迎光临 无忧启动论坛 (http://wuyou.net/) Powered by Discuz! X3.3