问些wee菜单很怪的问题。

求道者

今天我打算调试PE
然后在虚拟机两个虚拟机里创建了共享的虚拟磁盘
因为要引导bootmgr而且位置不在根目录
所以用了wee
怪事就发生了
这是wee菜单
只有两行

1. find --set-root /boot/bootmgr
   
2. /boot/bootmgr

复制代码

用BOOTICE安装
结果

这是什么鬼东西？
于是找了别的安装程序
chenall写的grub4dos批处理
http://chenall.net/post/grub4dos_instwee/
我还改了 不改用不了
18行的这个

1. (hd%2)+1,0x1b0

复制代码

删了

1. ,0x1b0

复制代码

改后能用……

但也一样，不能正常引导

下意识看了一下hex
发现7830位置成这样了

？
这也……
难道
我改成

保存
重启虚拟机
能用了……
………………
所以wee的配置文件到底是在从哪个地址开始的？
7840？
还是有什么标记字符？

还有就是grub4dos_instwee为何不能用？
grub4dos批处理又大改了吗？

求道者

不点 发表于 2019-10-25 17:37
较早的 BOOTICE 版本，其内置的 wee63.mbr 中的程序代码，有可能不是最新的。

大家可以考虑下述方案是 ...

这就很怪了……
用BOOTICE1.3.4安装
看起来就会多一点字节
我尝试过从7830开始填0
然后在7830写入配置
wee似乎就不工作了
但2楼贴出来的图片
似乎表明7810开始就没数据了
清空7830应该没问题啊
果然wee版本变了吗？
最新版本从7850开始写数据？
但BOOTICE1.3.4用默认菜单
似乎是从7840开始写配置
-e似乎是配置开始段的标记


不点你不记得wee这个查找配置是怎么工作的了吗？
用BOOTICE1.3.3写入外部wee（2016-01-31）会得到这个
这应该是正确的吧



chenall还在活动吗？
能修BUG吗？

求道者

不点 发表于 2019-10-25 20:00
你用 hex 编辑器打开 wee63.mbr，看看尾部的菜单起始于何处，就全清楚了。

似乎wee63.mbr菜单以2D 65 20开头和结尾
似乎不用2D 65 20结尾也行
所以这个是标记开始？

我删了菜单开头的2D 65 20似乎也能启动……
我进一步从7848写入了菜单
然后

从784A开始写菜单就OK

求道者

不点 发表于 2019-10-25 20:43
这三个字节应该是个错误，应该删除。前后共有 6 个字节应该删除。

可能是由于编译环境不是 bash 而是其 ...

是不是其他的地方也有这种垃圾字节？
汇编程序这样不应该……

求道者

不点 发表于 2019-10-25 20:46
有没有谁在 Linux 下编译一下看看？

怎么弄？
我make一下试试
不一定有编译环境

1. make
   
2. gcc -m32 -mno-sse -g  -c asm.S -o ./asm.o
   
3. gcc -m32 -mno-sse -g -Os -fno-stack-protector -fno-builtin -mpreferred-stack-boundary=2 -fno-strict-aliasing -fomit-frame-pointer -fno-exceptions -fno-asynchronous-unwind-tables -fno-unwind-tables -nostdinc -Wall -Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -Wundef  -c builtins.c -o ./builtins.o
   
4. builtins.c: In function ‘map_func’:
   
5. builtins.c:1210:8: warning: variable ‘p’ set but not used [-Wunused-but-set-variable]
   
6.   char *p;
   
7.         ^
   
8. In file included from builtins.c:25:
   
9. builtins.c: At top level:
   
10. shared.h:389:29: warning: inline function ‘log2_tmp’ declared but never defined
    
11. extern inline unsigned long log2_tmp (unsigned long word);
    
12.                              ^~~~~~~~
    
13. gcc -m32 -mno-sse -g -Os -fno-stack-protector -fno-builtin -mpreferred-stack-boundary=2 -fno-strict-aliasing -fomit-frame-pointer -fno-exceptions -fno-asynchronous-unwind-tables -fno-unwind-tables -nostdinc -Wall -Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -Wundef  -c disk_io.c -o ./disk_io.o
    
14. In file included from disk_io.c:23:
    
15. shared.h:389:29: warning: inline function ‘log2_tmp’ declared but never defined
    
16. extern inline unsigned long log2_tmp (unsigned long word);
    
17.                              ^~~~~~~~
    
18. gcc -m32 -mno-sse -g -Os -fno-stack-protector -fno-builtin -mpreferred-stack-boundary=2 -fno-strict-aliasing -fomit-frame-pointer -fno-exceptions -fno-asynchronous-unwind-tables -fno-unwind-tables -nostdinc -Wall -Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -Wundef  -c fsys_ext2fs.c -o ./fsys_ext2fs.o
    
19. fsys_ext2fs.c:38:1: error: static declaration of ‘log2_tmp’ follows non-static declaration
    
20. log2_tmp (unsigned long word)
    
21. ^~~~~~~~
    
22. In file included from fsys_ext2fs.c:33:
    
23. shared.h:389:29: note: previous declaration of ‘log2_tmp’ was here
    
24. extern inline unsigned long log2_tmp (unsigned long word);
    
25.                              ^~~~~~~~
    
26. shared.h:389:29: warning: inline function ‘log2_tmp’ declared but never defined
    
27. make: *** [Makefile:62：fsys_ext2fs.o] 错误 1

复制代码

报错
看起来是GCC版本问题
但README没写用哪个版本……
不点知道吗？

求道者

不点 发表于 2019-10-25 20:55
汇编程序不会有这些垃圾字节。

菜单是 shell 处理后附加在尾部的。编译的时候，如果发行版的 shell 不 ...

1. SHELL=/bin/bash
   
2. SRC_C := builtins.c disk_io.c fsys_ext2fs.c fsys_fat.c fsys_ntfs.c
   
3. SRC_S := asm.S wee63start.S
   
4. BUILDROOT := .
   
5. LDFLAGS :=

复制代码

Makefile写死了
恐怕不是这样

求道者

不点 发表于 2019-10-25 20:59
这些错误，你应该可以帮忙排除。你自己写 c 程序，有错了，不是一样需要排除吗？

这不是等于把wee的编译环境迁移到新版的gcc吗？
这工作量有点大

求道者

不点 发表于 2019-10-25 21:08
那应该不会出现垃圾字节。

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

[分享] 自己动手，在WINDOWS系统中搭建GRUB4DOS编译环境[2014-06-25]
chenall一直是在WINDOWS下编译的？
会出问题不奇怪

求道者

不点 发表于 2019-10-25 21:18
工作量应该不大。新版 gcc 检查严格罢了。都是无关紧要的错误。

大概有一处报错
主要是警告
错误：对‘log2_tmp’的静态声明出现在非静态声明之后
说不定能搞好吧
先找个ubuntu的容器部署gcc4.5编译看看

求道者

不点 发表于 2019-10-25 21:25
wee 的编译，不像 grub4dos 那样难。

wee 最好在 Linux 下编译。

总之出货了
gcc4.8下还是可以编译的
我用的archlinux貌似没有非常旧的gcclib
只有gcc4.5本身

求道者

不点 发表于 2019-10-25 21:25
wee 的编译，不像 grub4dos 那样难。

wee 最好在 Linux 下编译。

应该就是了
估计是编译环境引起的垃圾字节
或者gcc版本的问题……

这就没有
如果编译的能用
我就上传二进制文件吧

求道者

不点 发表于 2019-10-25 22:02
好的，你上传，让大家都试试。

wee.7z (35.57 KB, 下载次数: 87)

2019-10-25 22:20 上传

点击文件名下载附件
下载积分: 无忧币 -2

下载后校验sha512值（大概7z不损坏的话不会有问题，建议以防万一）

1. b8d2772c49cc62d878688bb69407abf34e6a1c4ae0de1beed223a7037bb84ed6894c25d3c4bea38f85a6da29905b8a47a637350d85ef9fa3ef255a1ccd07d193  wee127.mbr
   
2. b93014b26ac6187ee7b1f3f26f6d93e1cb33c9efdb902e166604ad3d10eec1b1d73f3743b3d027a1befe36bf2e076e048f8b0db4ad4a2e3e00d72cd24a75211b  wee63.mbr

复制代码

求道者

不点 发表于 2019-10-25 22:07
你编译的，好像比以前编译的体积大了几十个字节。不如以前编译的好。还是用以前编译的吧。只需把 6 个垃圾 ...

也许是gcc4.8的问题
貌似提过一嘴

wee需要在gcc 4.5的环境中编译，否则生成的文件太大超过了32KB。如果你不需要编译wee可以略过以下内容。

某些版本的gcc编译出来文件会变大……
Ubuntu 16.04貌似才有gcc4.5
按这个尿性来看
都不用迁移gcc……
怎么回事啊

哪天迁移到gcc9 试试？（兴许修复了体积过大的BUG）
说不定会更小

求道者

不点 发表于 2019-10-25 22:07
你编译的，好像比以前编译的体积大了几十个字节。不如以前编译的好。还是用以前编译的吧。只需把 6 个垃圾 ...

其实不是大了
是反而小了

如你所见我用4.8编译的二进制文件
菜单部分是从7828开始的，16年C佬编译的菜单部分是从784A开始的
至于最后为什么体积反而大些
那显然是因为“preset_menu changed and fix Makefile issue”
更新菜单似乎就没编译……
不过虽然我浪费了挺长时间寻找合适的老系统安装gcc4.5
但也算有所收获
不知道是不是依赖环境的问题用gcc4.5编译后wee反而会大到7d2e
用gcc4.8编译体积更小可能是因为修复BUG 或者做了优化……
那么可以考虑迁移到gcc9了
感想就是gcc4.5实在太老了……
能裝的系统都够难找

Makefile还是不好，没弹性，换gcc版本还要用链接……
还有就是Docker救了我的命
最后发现了即开即用的gcc容器镜像
总算在现在搞完了……
明天试试gcc4.9或者gcc5 之类的编译wee
或者修了那个BUG 用gcc9

求道者

不点 发表于 2019-10-27 08:40
好的，证据充分，你编译的，体积不是更大了，而是更小了。

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

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

求道者

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

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

求道者

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

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

求道者

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

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

求道者

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

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

求道者

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

那个 risc- ...

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

求道者

hilsonma 发表于 2019-10-28 14:45
楼主能不能把最新编译的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 发表于 2019-10-29 10:03
我使用bootice v1.3.4 (x86)版本安装wee，很正常呀！
内置菜单原始是这样的：

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

求道者

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

我用hex编辑器看看

求道者

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编译不通过
报错。
我不会改

求道者

wintoflash 发表于 2019-10-29 21:46
fsys_ext2fs.c:39:1: 错误：对‘log2_tmp’的静态声明出现在非静态声明之后

修改fsys_ext2fs.c 37～44 ...

NICE！
但别的地方报错了

1. wee63start.S: Assembler messages:
   
2. wee63start.S:248: 错误：value of 131336476 too large for field of 2 bytes at 132
   
3. wee63start.S:375: 错误：value of 8208529 too large for field of 2 bytes at 289
   
4. make: *** [Makefile:66：wee63start.o] 错误 1

复制代码