问些wee菜单很怪的问题。

不点

hilsonma 说得对。bootice 的某个版本（1.3.4） 好像有问题。用之前的版本（1.3.3.2）似乎正常。

bootice 的有问题的版本，似乎计算错了菜单的开始位置，导致启动失常。

不过，也有 workaround：

把菜单最开头的一句，重复写 2 遍，或写 3 遍，可能就躲过 bootice 的 bug 了。

不点

hilsonma 发表于 2019-10-25 15:12
使用chenall的weesetup (2013-09-25)的话，如果带-w参数使用外部 wee63.mbr (2016-01-30) 也会产生楼主所说 ...

这么说来，有可能这是根本原因。猜测，假如 BOOTICE 的内部采用的是 weesetup ，那么，两者可能出现同样的毛病。

不点

hilsonma 发表于 2019-10-25 16:59
建议使用bootice v1.3.3.2 来安装其内置的wee63.mbr (2013-08-28) 到硬盘mbr.
并修改其内置的菜单为适合自 ...

较早的 BOOTICE 版本，其内置的 wee63.mbr 中的程序代码，有可能不是最新的。

大家可以考虑下述方案是否可行：

用最新版的 BOOTICE 1.3.4 来安装，菜单采用默认的，不更动它（这是因为 bootice 有可能把你想定制的菜单内容，放在错误的偏移地址处，造成问题）。然后手动用 WinHex 之类的扇区编辑工具来编辑尾部的菜单，编辑成最新的菜单即可，也就是，chenall 网站上的那个 preset_menu_used。

不点

你用 hex 编辑器打开 wee63.mbr，看看尾部的菜单起始于何处，就全清楚了。

不点

这三个字节应该是个错误，应该删除。前后共有 6 个字节应该删除。

可能是由于编译环境不是 bash 而是其它shell 造成的。

当初发布的 wee63.mbr 应该没有这三个字节的。

不点

有没有谁在 Linux 下编译一下看看？

不点

求道者 发表于 2019-10-25 20:44
是不是其他的地方也有这种垃圾字节？
汇编程序这样不应该……

汇编程序不会有这些垃圾字节。

菜单是 shell 处理后附加在尾部的。编译的时候，如果发行版的 shell 不是 bash，就可能出现这个错误。

要强制把 /bin/sh 弄成指向 bash 才行。

不点

求道者 发表于 2019-10-25 20:49
怎么弄？
我make一下试试
不一定有编译环境

这些错误，你应该可以帮忙排除。你自己写 c 程序，有错了，不是一样需要排除吗？

不点

求道者 发表于 2019-10-25 20:56
Makefile写死了
恐怕不是这样

那应该不会出现垃圾字节。

你给出的编译结果可能比较早，那时还没有添加

SHELL=/bin/bash

不点

工作量应该不大。新版 gcc 检查严格罢了。都是无关紧要的错误。

不点

求道者 发表于 2019-10-25 21:16
[分享] 自己动手，在WINDOWS系统中搭建GRUB4DOS编译环境[2014-06-25]
chenall一直是在WINDOWS下编译的？ ...

wee 的编译，不像 grub4dos 那样难。

wee 最好在 Linux 下编译。

不点

好的，你上传，让大家都试试。

不点

你编译的，好像比以前编译的体积大了几十个字节。不如以前编译的好。还是用以前编译的吧。只需把 6 个垃圾字节去掉便可。

不点

求道者 发表于 2019-10-27 03:11
其实不是大了
是反而小了

好的，证据充分，你编译的，体积不是更大了，而是更小了。

从你贴出的 chenall 编译的结果来看，我不能确定这是否 chenall 发布的。从你的图片上，我发现了一个严重错误。你的图片第一行（就是 00007840 那行）有 B0 02 1A CE 标志。它是一个 4 字节的整数，含义是 Bootlace。但是，这个整数的位置不对。它应该起始于 4 字节对齐的偏移地址，而不应该起始于 00007843。发现在它前面，有三个垃圾字节 2D 65 20 （也即“-e”和一个空格）。因此，这也是由于编译时使用了错误的 shell 而导致的。去掉上述三个垃圾字节，让 B0 02 1A CE 起始于 7840 就对了。

另外，在 B0 02 1A CE 之后，紧接着，不多不少，应该有 12 个 00 字节，然后才是菜单内容。而你贴出的图片，在 B0 02 1A CE 之后，紧接着就是菜单内容，而且，菜单的开头仍然有三个垃圾字节 2D 65 20。这是又一个错误。估计这一揽子错误，皆是由编译时采用了错误的 shell 造成的。

手动修复以上错误，这个 wee63.mbr 就可以正常使用了。当然了，如果你自己能编译出体积更小的版本，那就没必要采用这个旧版本了。

不点

求道者 发表于 2019-10-27 10:56
实际上如果用按C佬的说法用gcc45编译，则wee会变大到7d2e这和我用7bbb差的不是一点半点，毕竟源码是用的 ...

同意你的分析。

不点

求道者 发表于 2019-10-27 11:09
我的那份wee63你看看有没有bug，搞不好也有。

尾部的菜单格式上，没发现错误。至于说菜单之前的那些程序代码以及数据，那就要给编译器烧香了。只要编译器没错，那就没错。有一些是 ASM 代码，那应该没有问题。也有很多代码，是没能用 ASM 来实现，依旧保持 C 代码，那就会受到 gcc 的影响了。说实在话，gcc 不可靠，我对它的开发者，也存在某些不信任。在没有合适的替代品之前，只好继续使用 gcc。本来指望华为能够出个可靠的操作系统以及可靠的编译器，可惜，从现有信息来看，这事很没谱，八成是虚构的，靠不住。得知华为的编译器是以 gcc 为基础，也就失望了。如果能以别的编译器（比如 clang）为基础，（在我看来）尚有希望。本人对启动引导软件开发没兴趣了，因此，本人也就不关心这些工作了。否则的话，我可能会尝试用 clang 来编译 grub4dos 或编译 wee。

在 wee63.mbr 的偏移 046C 处，有个整数（在你的编译之下，它是 F618），它指示了尾部 B0 02 1A CE 这个“bootlace 签名”的位置。你的签名实际上起始于 7818 处。两者的差值，应该是一个恒定的常数。也就是说，F618 - 7818 = 常数（屏蔽掉高位，只留下低 16 位的数值），这个常数是 7E00。你试试看，不同的编译，它们的差值是不是都是恒定的 7E00？

尾部的 B0 02 1A CE，正如前面所说，它应该位于 4 字节对齐的边界处。它后面紧跟 12 个 00 字节。然后紧接着就是菜单内容了。从 B0 02 1A CE 开始，不是由 gcc 生成的，而是由 shell 写入的。如果 shell 不是 bash，就有可能写入多余的垃圾字节，造成错误。

不点

求道者 发表于 2019-10-27 11:53
按这个搞法，是不是用新的gcc编译grub4dos也会有优化？

有人用新版 gcc 来编译 grub4dos，好像是 wintoflash 兄，但他没有弄成。估计会有不少麻烦。

不要抱太大的希望。成功了值得庆贺，失败了也属正常。我对 gcc 团队不信任。

然而，wee 的代码要小得多，估计，碰到的麻烦也会没那么多。试试无妨。

不点

求道者 发表于 2019-10-27 13:04
华为好像只是在gcc上加了自己的组件对安卓优化，根本没重新做编译器，不过gcc有各种各样的问题的也不奇怪 ...

编译器好像有别的可以选择。clang 是其中之一，可以完成 gcc 的大部分功能，成为 gcc 的一个替代品。其它还有没有更好的替代品，我不知道。


为了防止走过路过的朋友误读了我的意思，特别声明一下：

所有的言论，都只是自己一管之见，正确与否，是由看官您自己来判断的，不是由我说了算的。我并未对任何人（包括华为在内）进行指手划脚的意思。我也不会那么自不量力，我又不算老几，可能还会被人家当做“愤青”或者“高傲自大之人”等等，人家也不可能听我指挥。人家的任何做法，都有其道理，都是正确的，人家自己会负责的。只是我站的角度不同，因而理解不同罢了。我有发表自己看法的自由，任何人都有这样的自由。

不点

抨击了谁，谁就不太舒服。至于说人家会怎么反应出来，不同的人可能有所不同。假如有人抨击了我，我的反应可能不会太强烈。但假如我抨击了别人，别人的反应会怎样，这可不容易预料。所以，还是尽量避免抨击别人吧。

谁也不想换来换去的。想当年，我坚持使用 Win98，拒绝升级为 XP。后来人家逼着 Win98 退市，只好上了 XP 的架子（鸭子上架了）。再后来，XP 也封杀了，又上了 Win7 的架子。这不，现在 Win7 也好景不长了……

现实与理想是有距离的。研究了 Linux 内核，震惊于 Linus Torvalds 管理之下的内核，竟然有那么多的污垢。此处我用这个词，那当然是我的看法了。也许人家不那么认为，也许人家说那是宝贝。所以，对 Linux 内核已经不信任了。但有什么办法呢？又不存在更好的替代品，只好忍了。

同样，对 gcc 也是一样的感受。人只要年轻，精力旺盛，就可以通过“亮剑”来发泄自己的不满，说干就干，做出自己的不一样的产品出来。但人一老，干不动了，就只剩一张嘴巴了，也只能空空地宣泄一通了事。

不点

求道者 发表于 2019-10-27 15:10
说个事吧，和内核关系挺大的，前些日子的5.1.*内核出现过LVM bug导致你用了LVM并且加密数据的话呢，就 ...

对呀。现实与理想，就差很远。正是因为有差距、有不满，它才能不断前进，才有前进的余地。

那个 risc-v 开源 CPU 架构，就是一个例子，反映了那些不满现状的人，拿起武器，亮剑了。

相对于 1000 年以后的人，我们都是古人。那时候，很可能许多事情都解决了、改善了。

然而，今天，那些像 risc-v 那样从头做起的开拓者们，或许就是未来人们前进的奠基者，未来的人可能会从中受益。不仅 CPU 需要像 risc-v 那样简化，操作系统也需要简化，编程语言也需要简化。那些故意把它复杂化的努力，必将被历史抛弃。商业公司再怎么努力把它复杂化，都没有用。未来的人不会甘心情愿受它摆布。矛盾必然推动世界向前发展。

我认为，做一个人，就要起到一个人的作用。自己是个人，而不是个畜生，就不能以畜生的要求，来要求自己；对自己的要求要高一点。做一个人，就要留下人的足迹，而不是留下一个畜生的足迹。做一个人，就要有人的理想，要做对整个人类生存发展有意义的事情。在年轻的时候，在力所能及的情况下，要干出一番能够让自己满意的事情。自己来世上也只有一遭，没有机会再来一次。这辈子不努力，永远也就没机会了。


顺便说，美国也有很多好的东西。像 risc-v、GPL、BSD 等，都是从美国出来的。同样，中国也有很多好的东西。什么东西好，什么东西不好，这是不分国度的。也没有判断的标准，如果有的话，那每个人自己就是标准的制定者。

人是啥？人跟其它动物还是有一些差别的。一个人就是一个哲学体系的载体。不同的人，就有不同的哲学体系。哲学体系是一个人的经验、知识的集合。每个人的经验和知识不同，那么哲学体系也就不同。没有完全相同的两个人，没有完全相同的两个哲学体系，两个人的经验和知识，多多少少总会有差别的。同一个人也是动态变化的，反映在他的哲学体系上，也是在动态变化着的。动物和植物，也有其经验和知识，也有它的哲学体系。不同的哲学体系，在成熟度上有不同，有些属于初级的，有些属于高级的。就像念书一样，有的是幼儿园，有的是小学、初中、高中……，层级不同。

不点

求道者 发表于 2019-10-27 17:58
复杂未必是坏事，能够更灵活，虽然学习起来更难。
Golang就是一个例子，他太简化了，以至于一些事情用其 ...

一系列简单的东西，堆积成复杂的——我赞成这样的。

我不赞成的是，仅有复杂的，没有简单的，牵着你牛鼻子走，学习难度高。

闭源的东西，基本都是这样的思维套路。它给你一个成品，可能很好用。但它隐藏了很多，或者说，让你知道的，仅是皮毛，其它全是秘密。本来就没打算让你了解太多，你了解多了，对它构成威胁。用户只能在人家圈定的监狱里活动。有些人混进开源队伍里，他们也是想把系统搞得尽量复杂，让人看不懂。然后，他就可以在开源的框架下做他原来在闭源框架下所做的那些事。我感到震惊的，不是这件事。我震惊的，只是一向比较信任的内核维护者，也能做这样的事。因此，我觉得该考虑放弃 Linux 的事了。确实有人在做操作系统的工作，不过，还不成熟。从 CPU、操作系统、编程语言等各个层面，都需要重建。这个工作，肯定有人做的，只是可能需要很多代人的工作罢了。

不点

gnuxwy 发表于 2019-10-27 21:02
不点老大这么牛的啊，直接看十六进制的数字就能看出毛病来？

利益的复杂性投射进开源的圈子，就产生了源 ...

我是这个软件的开发者啊，所以，有印象呗。要是别人的闭源软件，能通过看字节找出毛病来，那才是真有能耐。

不点

求道者 发表于 2019-10-29 22:47
NICE！
但别的地方报错了

贴出 248 行以及 375 行附近的代码看看，汇编代码的错误，应该有办法解决。

忽然想起来了，可能没法解决。

可能是 gcc 新版生成的代码体积太大（上百M，天文数字）造成的。

算了吧，死了这条心。

其一是可以用旧版 gcc。
其二是用 clang
其三是用 tcc（Tiny C Compiler）

应该还有许多别的可能性。


个人顺便留个阶段性的结论（声明：只用于提醒自己，与别人无关）：

Linus Torvalds 不值得信任。gcc 和 bash 属于 GNU 的，也不能信任。如此，GNU/Linux 也就不能信任了。这就为将来努力抛弃 Linux 找到了完整的理由。

不点

求道者 发表于 2019-10-30 21:02
248行和附近

这个已经说过了，是新版 gcc 编译的二进制结果体积太大导致的，无解。就是 STAGE2_SIZE 超级大，很多 M 字节。你的编译过程中，应该出现这个超级大的中间结果文件，那就是新版 gcc 编译出的中间结果文件。

不点

求道者 发表于 2019-10-30 21:12
clang编译 报这个错

clang 的汇编器可能不支持前缀 cs 和 addr32 等。解决办法：

把 cs lodsb 写成两行：

.byte   0x2E    // 手动编码前缀 cs
lodsb

同理，把 addr32 loopz 1b 也写成两行：

.byte   0x67    // 手动编码前缀 addr32
loopz  1b

不点

求道者 发表于 2019-10-31 13:00
而且clang不支持-mpreferred-stack-boundary=2

这次的错误其实只有一个：都是不认识 %cs:*(ROM_int15 - int13_handler)

这很容易搞。试试两个办法，其一，试试去掉星号，看看能否通过。其二，那就得手动替它汇编了。手动汇编还得查阅 intel 相关指令手册。你就先试试去掉星号，看看怎么样？

不支持 -mpreferred-stack-boundary=2 没关系，这个参数不重要。


lcall 和 ljmp 就相当于微软汇编里面的 call far 和 jmp far。


有个偷懒的办法，可以不用查阅 intel 手册，就能知道


ljmp %cs:*(ROM_int15 - int13_handler)


能够编码成什么字节串。


在 gcc 编译的情况下，你在




ljmp %cs:*(ROM_int15 - int13_handler)


的前后插入一些垃圾字节，比如这样：



.ascii   "hihihi" // 这些垃圾字节当然不可以出现在正式使用的编译结果中

ljmp %cs:*(ROM_int15 - int13_handler)
.ascii    "hello!" // 这些垃圾字节当然不可以出现在正式使用的编译结果中


然后，你在编译结果中查找这些字符串，就能知道两个字符串中间的编译结果了。然后，通过猜测，就能知道指令代码 ljmp 和 cs 前缀分别是啥，以及跟着的参数(ROM_int15 - int13_handler) 的值。于是，就可以用


.byte  0x??     // 这应该是 cs 前缀，也就是前面曾经用过的 0x2E

.byte  0x??     // 这个应该是 ljmp 间接寻址的指令码，究竟是单字节还是两个字节，我不太确定。如果是俩字节，那就是 .byte  0x?? , 0x?? 的格式。

.word (ROM_int15 - int13_handler)


来构造汇编代码，让 clang 能够运转了。



同理，lcall 的情况也可以用这种方法来处理。

不点

说明去掉星号起作用了。它还要求精确的字宽后缀。给指令添加w后缀试试。w代表 word，即 16 位宽度。

就是说，把 ljmp 改成 ljmpw，把 lcall 改成 lcallw。

不点

这次报操作数错误。试试去掉%cs:，在指令前面插入一行 .byte 0x2E

不点

添加星号试试
lcallw *(ROM_int15 - int13_handler)

如果不行，再试试

lcallw 7777
lcallw *7777
lcallw (7777)
lcallw *(7777)

看哪个能成功。注意星号和 w 之间有空格。

不点

这么大的文件，是错的。我猜可能是操作系统底层更改造成的。算了，不折腾了。安心用旧版 gcc 编译吧。