GRUB4DOS for UEFI

2010happly

新技术层出不穷，疲于适用，前一个还没弄明白，又惶忙捡起下一个

不点

2010happly 发表于 2025-4-15 08:55
新技术层出不穷，疲于适用，前一个还没弄明白，又惶忙捡起下一个

不，不，不，

你应该庆幸，你不曾被旧技术套牢。

如果你昨天好不容易终于学精了某个旧技术，今天发现，世界变了，旧技术已经淘汰，你作何感想？

你应该庆幸，你跳过了旧技术，直接来到新技术。

2011yaya2007777

报 unaligned pointer 这种错误，个人感觉是严重错误。就是，程序含有 bug，居然能够让指针不对齐！32位的程序，应该是 4 字节对齐的。而 8e234252 不是 4 字节对齐。

这个问题终于搞清楚了。

据minmax发给我的消息中讲：
“出現選單就報以下錯，執行的話也是 aligned pointer 8e234252”
是因為引入了一行很舊的指令行(不顯示版本)，
call Fn.0 0x40000 "!BAT\necho -P:0000 $[0000]\t\t\t\t\t\t\t\t\t\0" && initscript (md)0x200+1
拿掉就好了

这是错误地沿用了G4D的菜单。因为G4E不能随便使用内存，必须使用函数分配。否则会破坏已有数据。
比如：
grub_free(abc);
而abc指针正好在 0x40000范围，比如指针值是0x678900，被污染后成了8e234252、

假大空

2011yaya2007777 发表于 2025-4-16 10:30
这个问题终于搞清楚了。

据minmax发给我的消息中讲：

厉害！知其然更知其所以然

不点

2011yaya2007777 发表于 2025-4-16 10:30
这个问题终于搞清楚了。

据minmax发给我的消息中讲：

太好了！又丰富了知识宝库。

好的，这就排除了对于 “grub2 代码造成堆栈错误”的怀疑。

所以，大家（广大用户们）应该尽快从 grub4dos for BIOS 中走出来，尽量早点摆脱。

应该以 g4e 为主。

nssn

赞一个!

sunsea

2011yaya2007777 发表于 2025-4-16 10:30
这个问题终于搞清楚了。

据minmax发给我的消息中讲：

有一说一，感觉对这种以前的trick类的这种用硬编码地址啊、非公开内容啊啥的东西，应该至少在g4e中要么予以直接移除，要么直接文档化、命令化，要不然全是屎山、或者引起难以排查的bug。既然开了新分支，就应该尽量一切从新开始。

2011yaya2007777

现在高人是不少，但是。使用G4E批处理或者外部命令编程的人少之又少。像以前大块头的作品如RUN，SISO，还有hotkey等等。有些所谓的未公开内容，我理解是当前实现了某种功能，开发者正在使用，但是可能不完善，所以没有正式发布。
对于硬编码，确实简单方便，使得程序小巧。不可能移除，再说移到那里？如果想使用这些变量，函数的入口，在asm.S中有定义。

不点

sunsea 发表于 2025-4-16 12:59
有一说一，感觉对这种以前的trick类的这种用硬编码地址啊、非公开内容啊啥的东西，应该至少在g4e中要么予 ...

说说我的一管之见。

旧的 grub legacy 架构，毛病很多。我前面的帖子里已经提到堆栈问题。grub4dos 对此进行了大规模的改造，才形成了目前的样子。比如说，把 32 位主代码空间挪动到物理地址 3M～4M 之间，这就腾出大量实模式空间，用于别的目的（包括增大了堆栈的空间，很重要！）。由于 grub legacy 没有分配内存的机制，所以，就采取了绝对地址的调用方式。这方面确实很混乱。

g4e 应该按照 g4e 自己应有的架构去设计。不用考虑与 g4d 的兼容性。当然，起初要照顾 g4d 的用户，所以，就较多地考虑了与 g4d 的兼容性。但是，当 g4d 逐渐成为历史，也就没必要再去考虑兼容性了。

g4e 应该有个文档，把那些与 g4d 不兼容的部分列出来。

另外，在解析菜单命令时，还要采取措施，禁止那些不兼容的用法。

比如，当用户使用 call Fn 时，报错，返回 false（表示失败），让用户知道这条命令不再支持。

又比如，当用户使用 gfxmenu 时，也要报错（返回 false），让用户知道这个用法是不正确、不适用的。

g4d 和 g4e 两者的 menu.lst 的位置本来就不一样，所以，原则上不会产生混乱。

2011yaya2007777

call Fn命令支持的。只是使用实模式地址要注意，只能使用常规内存。有时候uefi会占用部分常规内存。因此最好使用函数分配内存。

不点

2011yaya2007777 发表于 2025-4-16 19:45
call Fn命令支持的。只是使用实模式地址要注意，只能使用常规内存。有时候uefi会占用部分常规内存。因此最 ...

既然 call Fn 是支持的，那就要设法规避与 UEFI 占用的常规内存的冲突。

确实，grub_free 的出错信息，本身就表示问题很严重，属于内存冲突。堆栈溢出是内存冲突的一种。

应该给出一个说明文档，告诉用户如何使用 call Fn 以及如何使用外部命令和批处理命令才是安全的。

如果用户执行了某条“合法”的命令，却导致死机，那只能说，问题出在 g4e 的代码上。

【补充】忽然明白了，UEFI 系统要占用常规内存空间，这挤占了（压缩了）g4e 可以安全使用的空间。而在 BIOS 的时候，BIOS 系统可是不会随便占用常规内存空间的，除了“中断向量表”、“BIOS 数据区”、“扩展的 BIOS 数据区”之外。所以，在旧的 g4d 下能够使用的内存，在 g4e 中就可能会产生内存冲突（而死机）。

2011yaya2007777

现在没几个人对编写批处理或者外部命令感兴趣。如果真有感兴趣的人，并且明白g4d的旧代码，看一下本篇开头，以及RUN抛砖引玉那篇，就会明白不同之处及应当注意点事。

wintoflash

不点 发表于 2025-4-17 05:31
既然 call Fn 是支持的，那就要设法规避与 UEFI 占用的常规内存的冲突。

确实，grub_free 的出错信息 ...

如果主板的UEFI支持CSM的话，会把前面的内存锁定防止普通uefi程序申请占用，以便切换到Legacy BIOS模式后Legacy BIOS的bootloader能够使用这些内存。

不点

2011yaya2007777 发表于 2025-4-17 06:11
现在没几个人对编写批处理或者外部命令感兴趣。如果真有感兴趣的人，并且明白g4d的旧代码，看一下本篇开头 ...

本人的使用，极其简单。基本就是在 “一盘走天下【自由拼装修改版】”当中使用罢了。不曾用到批处理之类的。外部命令也没用到。

您提到的那些文档，我从未看过，因为我的应用范围太狭窄，用不到那些知识。我只需要看发布包中的样板 menu.lst 就够了。

为了方便那些需要批处理编程的人，应该把必要的知识都放在发布包中，而不是放在某个帖子中。在帖子中的，不属于 “正式文档”。在 Readme 中的，才算是正式文档。

2011yaya2007777

所以在UEFI模式下，不要有常规内存的概念，只要使用内存，就分配一块。

不点

wintoflash 发表于 2025-4-17 09:27
如果主板的UEFI支持CSM的话，会把前面的内存锁定防止普通uefi程序申请占用，以便切换到Legacy BIOS模式后 ...

那我觉得这还是挺严重的一个问题，需要仔细对待。旧的 call Fn 之类的绝对地址使用方式，以及 g4e 对于绝对地址的占用，就可能与 UEFI、CSM 产生内存冲突。比如说，旧的 g4d 的批处理程序占据了某个绝对地址，这本身就有可能与 UEFI 相冲突。这在 BIOS 下是不会有冲突的，因为 BIOS 系统不会占据 chenall 为批处理设定的内存位置。

这让我想到了 Ventoy。Ventoy 没有与 g4d 兼容的包袱。所以，Ventoy 就不存在这方面的问题。

wintoflash

sunsea 发表于 2025-4-16 12:59
有一说一，感觉对这种以前的trick类的这种用硬编码地址啊、非公开内容啊啥的东西，应该至少在g4e中要么予 ...

能把BIOS下grub4dos的map功能移植到BIOS的grub2下就好了。
但是grub4dos目前代码太乱太多了，我搞不明白。
目前在研究syslinux的memdisk。

pentium4

这个棒，感谢分享。   

shibbb12345

谢谢楼主分享。

sunsea

不点 发表于 2025-4-17 09:59
本人的使用，极其简单。基本就是在 “一盘走天下【自由拼装修改版】”当中使用罢了。不曾用到批处理之类 ...

我也基本一样，对于g4e主要的命令知识都来自于菜单中的样板菜单。

不点

wintoflash 发表于 2025-4-17 12:18
能把BIOS下grub4dos的map功能移植到BIOS的grub2下就好了。
但是grub4dos目前代码太乱太多了，我搞不明白 ...

继续操作 BIOS，不知有啥想法？依我的看法，for BIOS 不用再继续搞了。继续搞，就是浪费时间，就是浪费生命。

UEFI 下有了 map，就已经很不错了，这个工作很棒。甚而至于，UEFI 下（即使）不用 map 也有（别的）启动 ISO 的方法。map 的地位在降低。也就是说，连 map 都要过时了，或者说，已经在“过时”的过程中。

vyuha

谢谢

mygamexxx

最近使用zenemu测试遇到点问题，就使用“Qemu启动测试器x64”测试。发现“Qemu启动测试器x64”与EasyWebSvr配合，ipxe.efi能通过HTTP顺利PXE启动至PE桌面（需要改变内存至2048M，1024M提示内存不够）。但测试到G4E，发现能出菜单，但使用的是TFTP，无法顺利启动PE。

另外，同一个PE，zenemu无法在该PE中使用，“Qemu启动测试器x64”能使用。

2011yaya2007777

最近使用zenemu测试遇到点问题

新版本可以使用qemu网起了。

ebaqiang

感谢分享、

xiaoy

2011yaya2007777 发表于 2025-5-10 11:10
新版本可以使用qemu网起了。

我同样的启动环境，１２月１６版能显示菜单　　启动失败，　２月２５的版本　菜单　启动一切正常　ＨＴＴＰ速度不快　　　其它版本均看不到菜单　　包含最新的5.10

liuzhaoyzz

2011yaya2007777 发表于 2025-5-10 11:10
新版本可以使用qemu网起了。

grub4dos-for_UEFI-2025-05-10版本，
vmware16.1.2测试，uefi下面启动pe.wim，似乎过程中有时候有出错提示，有时候又没有出错提示；大部分时候正常，有时候会蓝屏。
启动pe.iso可以。
速度基本跑满了网速带宽。


用wintoflash的zemu_qemu0.2版本测试，似乎找不到/efi/grub/menu.lst菜单。

mygamexxx

新版用QEMU测试：NTBOOT方式，能出菜单，有出错信息，最终结果蓝屏。

mygamexxx

map方式：能出菜单，有出错信息，最终结果蓝屏。

mygamexxx

旧版QEMU，TFTP，NTBOOT方式，/efi/ext/ntboot (http)/boot/boot.wim，能出菜单，有出错信息。/efi/ext/ntboot /boot/boot.wim，能出菜单，无出错信息。所需时间太长(估计需15分钟左右)，未等待最终结果。