问些wee菜单很怪的问题。

不点

求道者 发表于 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 08:40
好的，证据充分，你编译的，体积不是更大了，而是更小了。

从你贴出的 chenall 编译的结果来看，我不 ...

实际上如果用按C佬的说法用gcc45编译，则wee会变大到7d2e这和我用gcc4.8编译出的7bbb差的不是一点半点，毕竟源码是用的同一版本，只能是编译器差异了，那看来gcc45本身也挺差的，我回去试试高版本的gcc会咋样，只是最新版本就要改源代码了。

不点

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

同意你的分析。

求道者

不点 发表于 2019-10-27 11:03
同意你的分析。

我的那份wee63你看看有没有bug，搞不好也有。

求道者

不点 发表于 2019-10-27 11:03
同意你的分析。

按这个搞法，是不是用新的gcc编译grub4dos也会有优化？

不点

求道者 发表于 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 12:07
尾部的菜单格式上，没发现错误。至于说菜单之前的那些程序代码以及数据，那就要给编译器烧香了。只要编译 ...

华为好像只是在gcc上加了自己的组件对安卓优化，根本没重新做编译器，不过gcc有各种各样的问题的也不奇怪，毕竟gcc45一般也被认为是不应该再使用。
重做编译器的工程量恐怕是相当恐怖。

不点

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

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


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

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

求道者

不点 发表于 2019-10-27 14:13
编译器好像有别的可以选择。clang 是其中之一，可以完成 gcc 的大部分功能，成为 gcc 的一个替代品。其它 ...

就算是抨击华为也没事吧，毕竟方舟编译器本身就有问题，而且华为的宣传口径也有问题，没道理不让人说，clang好像被Google指定为NDK的编译器了，不过实际上换了编译器能好多少又是另外一码事了。

不点

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

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

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

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

求道者

不点 发表于 2019-10-27 14:57
抨击了谁，谁就不太舒服。至于说人家会怎么反应出来，不同的人可能有所不同。假如有人抨击了我，我的反应可 ...

说个事吧，和内核关系挺大的，前些日子的5.1.*内核出现过LVM bug导致你用了LVM并且加密数据的话呢，就会丢失所有数据，开始我没所谓，因为我不用，后来呢，btrfs文件系统也出了bug，而且我因此丢了几乎全部的数据…
这是正式发布版了，大哥，还有这种恶性bug，负责测试的人还行不行了？
后来想来也是，毕竟虽然是先进文件系统，但他的RAID5/6功能一直有问题，磕磕绊绊小问题不断，最后作为合作者的红帽放弃了将btrfs作为默认文件系统的计划，现在只有suse还把btrfs作为默认文件系统。人少测试不到位，太正常了。
一个文件系统尚且几万甚至数十万行代码，审计源码出错不奇怪，文件系统如此，内核更甚。
理想中当然是RC前后就应该解决所有bug，但现实往往不如意。
但就算这样我还是会用btrfs，因为没有比他更方便的选择了。(透明压缩，自带快照，ssd优化，在线调整分区大小，在线重建RAID)

不点

求道者 发表于 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 16:15
对呀。现实与理想，就差很远。正是因为有差距、有不满，它才能不断前进，才有前进的余地。

那个 risc- ...

复杂未必是坏事，能够更灵活，虽然学习起来更难。
Golang就是一个例子，他太简化了，以至于一些事情用其他的语言，可以最优解，Golang要绕路。
但Golang学习确实是容易，更易读，在创造大型项目时，因为限制多，更难以弄出屎山。
有利有弊
risc-v感觉更像是，作复杂指令集会更麻烦，作为初创项目，一开始就这么搞恐怕很费功夫。

不点

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

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

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

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

gnuxwy

不点老大这么牛的啊，直接看十六进制的数字就能看出毛病来？

利益的复杂性投射进开源的圈子，就产生了源码迷宫。。。
但氏烂氏比出来的，买硬件，用软件，都只能从一堆无奈产品中选出相对可接受的。

老大从dos、win98、winxp，win7一路换过来觉得很无奈。很快，尛软又要干掉win7了。
不过，屮用虚拟机，winxp照样用，实机为了驱动，只能上win7。若win7不支持，一样进虚拟机！

不点

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

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

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

hilsonma

楼主能不能把最新编译的wee63.mbr放上来，看你和不点的一番讨论，或许你新编译的会好一些吧。

顺便说一下chenall 的2016-01-30 wee63.mbr 的出处：
http://bbs.wuyou.net/forum.php?m ... p;extra=&page=5
在46#楼

或者https://github.com/chenall/grubutils/releases/tag/2016-01-31
这里也有源代码，楼主也可以看看用的源代码是不是跟这里的一样。

求道者

hilsonma 发表于 2019-10-28 14:45
楼主能不能把最新编译的wee63.mbr放上来，看你和不点的一番讨论，或许你新编译的会好一些吧。

顺便说一 ...

我放出来了，你仔细看，源码我直接用的主干代码。

hilsonma

求道者 发表于 2019-10-28 16:48
我放出来了，你仔细看，源码我直接用的主干代码。

谢谢。是28#楼那个吧，我以为后面还新编译了，所以才叫你重新上传。

刚才试了28楼那个wee63.mbr，菜单位置从7828开始，用weesetup或bootice安装到硬盘mbr后，菜单依然都是从7828开始，不会出错。
而chenall编译发布的wee63.mbr(20160130)，菜单位置从784A开始，用weesetup或bootice安装到硬盘mbr后，菜单识别从7850开始（不知是不是安装工具的原因），从而出错。

所以现在决定使用你编译的wee63.mbr，启动代码相对较短，菜单识别也不会出错。

求道者

不点 发表于 2019-10-27 12:07
尾部的菜单格式上，没发现错误。至于说菜单之前的那些程序代码以及数据，那就要给编译器烧香了。只要编译 ...

首先我看了一下C佬16年编译的那个
偏移046C处是40 F6
但B0 02 1A CE是从偏移7843开始的
F640-7843=7DFD
不对……
哪里有问题……
但F640-7E00=7840
偏移7840处是2D 65 20的垃圾字节……

我用gcc45编译出的东西虽然大
但至少常数是7E00。

求道者

我大概猜出了这个问题的症结……
总之就是C佬不知道用了什么编译器和编译环境编译出的wee有问题……
然后BOOTICE内嵌了那个……
weesetup也内嵌了那个……
然后就出问题了……
应该就是bootlace位置的问题……
至少BOOTICE1.3.4要返工，把写入外部wee的选项弄出来，还有更换内嵌的wee63.mbr
weesetup也要这么搞……

求道者

不点 发表于 2019-10-27 18:36
一系列简单的东西，堆积成复杂的——我赞成这样的。

我不赞成的是，仅有复杂的，没有简单的，牵着你牛 ...

你忘了一个问题，就是linux这个项目也不是一个人在贡献代码……
是很多人，代码水平参差不齐，代码风格迥异，读起来自然非常费劲是理所当然，组件之间当然是这样，甚至于一个组件上补丁前后都有各种风格……
要想易读，简单，很简单Golang那样，你想花里胡哨，对不起，不能！
这样搞才最优化？
对不起，不能。
就只有这样强制性，直接不让干，代码才能，易读，容易学，容易管理。
你靠自觉，他总会想搞这个优化，那个优化，有没有用，是不是会有反作用，这全靠作者水平，然后最终就会整个项目难以管理。
但你做内核，直接不让他最优化，不点你觉得，这样的内核最终能有效率？
这是万万不能搞内核的，和效率有关恐怕都不行！

至于代码质量，我认为至少进内核的代码还是有人审计，至少openwrt那边你加个路由的支持，审计都要搞很久，比如几个月。
当然随着项目越来越大，贡献者越来越多，审计总会跟不上，但这已经是尽全力了，恶意破坏也有，不过现在的版本管理还是方便，发现了直接回滚就完事了，想直接破坏恐怕要从代码托管的服务器上动手，而且审计代码的也不只，管理团队自己，还有其他组织，毕竟是开源的。
不过一个老项目，代码质量总体会下降是必然的，符合客观事实的，随着项目的变大，贡献者的增多，审计必然跟不上，然后就是，管理缺失-混乱加剧-管理缺失加剧-混乱再加剧，这是和死亡一样无法避免的铁律，即使不破坏，发展下去的也会迎来这样的结局，如同宇宙总是会熵增然后迎来热寂，万物的本质，无法回避，无法改变。
即使作出大量限制，放弃最优化，也只是能够延缓，而无法根治。
按linux和众多大项目的年龄来看，差不多也该迎来这样的阶段了……
说点别的，实际上M$相关的阴谋论者很多，愿意审计他们提交的代码的人大有人在。
说起来上次github被收购还有一堆人迁移或者复制代码到隔壁网站……

对于总会迎来的终结没有什么值得在意的……
现在这个阶段遇到任何问题我都不会奇怪，而且我已经遇到过了……

2011yaya2007777

我使用bootice v1.3.4 (x86)版本安装wee，很正常呀！
内置菜单原始是这样的：

find --set-root /boot/grub/grldr
/boot/grub/grldr
timeout 1
default 0

title 1. DOS/Windows
    find --set-root --active /bootmgr /bootmgr
    find --set-root --active /ntldr /ntldr
    find --set-root --active /io.sys /io.sys
    find --set-root /bootmgr /bootmgr
    find --set-root /ntldr /ntldr
    find --set-root /io.sys /io.sys

title 2. GRUB4DOS
    find --set-root /BOOT/GRUB/GRLDR /BOOT/GRUB/GRLDR
    find --set-root /BOOT/GRUB.EXE /BOOT/GRUB.EXE
    find --set-root /BOOT/GRLDR /BOOT/GRLDR
    find --set-root /grldr /grldr

title 3. Plop Boot Manager
    find --set-root /BOOT/GRUB/PLPBT.BIN /BOOT/GRUB/PLPBT.BIN

title 4. Vboot
    find --set-root /vbootldr /vbootldr

title 5. Burg
    find --set-root /buldr /buldr

title 6. Previous MBR
    (hd0)1+1

title 7. Command Line
    exit

菜单是要查找 grldr，并且加载 grldr，在 grldr 环境下工作。
楼主修改为：
find --set-root /boot/bootmgr
/boot/bootmgr
直接查找 bootmgr。我不清楚 wee 是否有此功能。

不要修改内置菜单，并且根目录放置 grldr 试一试，看看正常与否，再进一步讨论。

求道者

2011yaya2007777 发表于 2019-10-29 10:03
我使用bootice v1.3.4 (x86)版本安装wee，很正常呀！
内置菜单原始是这样的：

原始菜单没问题，但改菜单就会出问题。

2011yaya2007777

这是我编译的 wee63.mbr。
编译 weesetup 通不过，缺少 mbr.h .

求道者

2011yaya2007777 发表于 2019-10-29 16:24
这是我编译的 wee63.mbr。
编译 weesetup 通不过，缺少 mbr.h .

我用hex编辑器看看

2011yaya2007777

weesetup 应当在 windoes 环境编译。
我在 msys-7.2 编译，提示
F:\msys-7.2\bin\../ld.exe: cannot open output file bin/weesetup.exe: No such file or directory

求道者

2011yaya2007777 发表于 2019-10-29 16:24
这是我编译的 wee63.mbr。
编译 weesetup 通不过，缺少 mbr.h .

回去我用hex编辑器看看

求道者

2011yaya2007777 发表于 2019-10-29 16:50
weesetup 应当在 windoes 环境编译。
我在 msys-7.2 编译，提示
F:\msys-7.2\bin\../ld.exe: cannot open ...

你用gcc4.5编译的wee64.mbr吧……
体积大不少
但偏移常数是对的
Bootlace在偏移0x7840
chenall编译的那个就问题不是一点半点了

首先我看了一下C佬16年编译的那个
偏移046C处是40 F6
但B0 02 1A CE是从偏移7843开始的
F640-7843=7DFD
不对……
哪里有问题……
但F640-7E00=7840
偏移7840处是2D 65 20的垃圾字节……

我用BOOTICE1.3.4安装WEE,情况和之前说的完全一样……

可能gcc4.5问题不止一点不然不该编译出的二进制体积差这么多……
或者干脆gcc4整个有问题。
但我用gcc9编译不通过
报错。
我不会改