无忧启动论坛

标题: 问些wee菜单很怪的问题。 [打印本页]
作者: 求道者    时间: 2019-10-24 21:39
标题: 问些wee菜单很怪的问题。
本帖最后由 求道者 于 2019-10-24 21:44 编辑

今天我打算调试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批处理又大改了吗？
作者: hilsonma    时间: 2019-10-25 05:00
本帖最后由 hilsonma 于 2019-10-25 06:04 编辑

用bootice v1.3.3.2版本安装wee63.mbr，将默认菜单修改一下就可以了。

使用bootice v1.3.4 (x86)版本安装wee就会出现类似楼主所讲的问题。
这个问题只要用bootice v1.3.3.2版本修改wee菜单就可以解决。
在wee命令行下输入正确的菜单命令也可以启动。

例如：find --set-root /boot/bootmgr /boot/bootmgr
只要存在 \boot\bootmgr 就可以引导 \boot\bootmgr
然后bootmgr会使用\boot\bcd配置启动
只要存在\boot\bcd 且bcd设置正确就可以成功启动。

使用bootice v1.3.3.2内置的wee63.mbr (2013-08-28) 则wee菜单从7830开始
使用wee63.mbr (2016-01-30) 则wee菜单从7850开始
而楼主的图应是从7850开始的，所以前图 -sefind ...... 出错，后图 find ...... 正确。

作者: 不点    时间: 2019-10-25 14:28
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) 也会产生楼主所说的问题，如果使用weesetup内部自带wee63.mbr则没有问题。
作者: 不点    时间: 2019-10-25 15:30
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
本帖最后由 hilsonma 于 2019-10-25 17:00 编辑

建议使用bootice v1.3.3.2 来安装其内置的wee63.mbr (2013-08-28) 到硬盘mbr.
并修改其内置的菜单为适合自己的内容。

起码其中这句 find --set-root --active command +1 要改掉。

因为此句有歧义
歧义一：
find --set-root --active
command +1
歧义二：
find --set-root --active command
+1
应该原本是要一，结果可能是二，所以可能会出错。
作者: 不点    时间: 2019-10-25 17:37
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。

作者: 求道者    时间: 2019-10-25 18:50
本帖最后由 求道者 于 2019-10-25 19:47 编辑
不点 发表于 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，看看尾部的菜单起始于何处，就全清楚了。
作者: 求道者    时间: 2019-10-25 20:25
本帖最后由 求道者 于 2019-10-25 20:36 编辑
不点 发表于 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 而是其它shell 造成的。

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

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

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

是不是其他的地方也有这种垃圾字节？
汇编程序这样不应该……
作者: 不点    时间: 2019-10-25 20:46
有没有谁在 Linux 下编译一下看看？
作者: 求道者    时间: 2019-10-25 20:49
本帖最后由 求道者 于 2019-10-25 20:54 编辑
不点 发表于 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
求道者 发表于 2019-10-25 20:44
是不是其他的地方也有这种垃圾字节？
汇编程序这样不应该……

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

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

要强制把 /bin/sh 弄成指向 bash 才行。
作者: 求道者    时间: 2019-10-25 20:56
不点 发表于 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
求道者 发表于 2019-10-25 20:49
怎么弄？
我make一下试试
不一定有编译环境

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

作者: 不点    时间: 2019-10-25 21:08
求道者 发表于 2019-10-25 20:56
Makefile写死了
恐怕不是这样

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

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

SHELL=/bin/bash

作者: 求道者    时间: 2019-10-25 21:08
本帖最后由 求道者 于 2019-10-25 21:11 编辑
不点 发表于 2019-10-25 20:59
这些错误，你应该可以帮忙排除。你自己写 c 程序，有错了，不是一样需要排除吗？


这不是等于把wee的编译环境迁移到新版的gcc吗？
这工作量有点大
作者: 求道者    时间: 2019-10-25 21:16
不点 发表于 2019-10-25 21:08
那应该不会出现垃圾字节。

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

[分享] 自己动手，在WINDOWS系统中搭建GRUB4DOS编译环境[2014-06-25]
chenall一直是在WINDOWS下编译的？
会出问题不奇怪
作者: 不点    时间: 2019-10-25 21:18
工作量应该不大。新版 gcc 检查严格罢了。都是无关紧要的错误。
作者: 求道者    时间: 2019-10-25 21:21
不点 发表于 2019-10-25 21:18
工作量应该不大。新版 gcc 检查严格罢了。都是无关紧要的错误。

大概有一处报错
主要是警告
错误：对‘log2_tmp’的静态声明出现在非静态声明之后
说不定能搞好吧
先找个ubuntu的容器部署gcc4.5编译看看
作者: 不点    时间: 2019-10-25 21:25
求道者 发表于 2019-10-25 21:16
[分享] 自己动手，在WINDOWS系统中搭建GRUB4DOS编译环境[2014-06-25]
chenall一直是在WINDOWS下编译的？ ...

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

wee 最好在 Linux 下编译。
作者: 求道者    时间: 2019-10-25 21:47
不点 发表于 2019-10-25 21:25
wee 的编译，不像 grub4dos 那样难。

wee 最好在 Linux 下编译。

总之出货了
gcc4.8下还是可以编译的
我用的archlinux貌似没有非常旧的gcclib
只有gcc4.5本身
作者: 求道者    时间: 2019-10-25 21:59
不点 发表于 2019-10-25 21:25
wee 的编译，不像 grub4dos 那样难。

wee 最好在 Linux 下编译。

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

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

作者: 不点    时间: 2019-10-25 22:02
好的，你上传，让大家都试试。
作者: 不点    时间: 2019-10-25 22:07
你编译的，好像比以前编译的体积大了几十个字节。不如以前编译的好。还是用以前编译的吧。只需把 6 个垃圾字节去掉便可。
作者: 求道者    时间: 2019-10-25 22:21
不点 发表于 2019-10-25 22:02
好的，你上传，让大家都试试。

wee.7z (35.57 KB, 下载次数: 87)
下载后校验sha512值（大概7z不损坏的话不会有问题，建议以防万一）

  1. b8d2772c49cc62d878688bb69407abf34e6a1c4ae0de1beed223a7037bb84ed6894c25d3c4bea38f85a6da29905b8a47a637350d85ef9fa3ef255a1ccd07d193  wee127.mbr
  2. b93014b26ac6187ee7b1f3f26f6d93e1cb33c9efdb902e166604ad3d10eec1b1d73f3743b3d027a1befe36bf2e076e048f8b0db4ad4a2e3e00d72cd24a75211b  wee63.mbr
复制代码


作者: 求道者    时间: 2019-10-25 22:27
本帖最后由 求道者 于 2019-10-25 22:42 编辑
不点 发表于 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-27 03:11
不点 发表于 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
求道者 发表于 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
本帖最后由 求道者 于 2019-10-27 11:51 编辑
不点 发表于 2019-10-27 08:40
好的，证据充分，你编译的，体积不是更大了，而是更小了。

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


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

同意你的分析。
作者: 求道者    时间: 2019-10-27 11:09
不点 发表于 2019-10-27 11:03
同意你的分析。

我的那份wee63你看看有没有bug，搞不好也有。
作者: 求道者    时间: 2019-10-27 11:53
不点 发表于 2019-10-27 11:03
同意你的分析。

按这个搞法，是不是用新的gcc编译grub4dos也会有优化？
作者: 不点    时间: 2019-10-27 12:07
求道者 发表于 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 12:13
求道者 发表于 2019-10-27 11:53
按这个搞法，是不是用新的gcc编译grub4dos也会有优化？

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

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

然而，wee 的代码要小得多，估计，碰到的麻烦也会没那么多。试试无妨。
作者: 求道者    时间: 2019-10-27 13:04
不点 发表于 2019-10-27 12:07
尾部的菜单格式上，没发现错误。至于说菜单之前的那些程序代码以及数据，那就要给编译器烧香了。只要编译 ...

华为好像只是在gcc上加了自己的组件对安卓优化，根本没重新做编译器，不过gcc有各种各样的问题的也不奇怪，毕竟gcc45一般也被认为是不应该再使用。
重做编译器的工程量恐怕是相当恐怖。
作者: 不点    时间: 2019-10-27 14:13
本帖最后由 不点 于 2019-10-27 14:35 编辑
求道者 发表于 2019-10-27 13:04
华为好像只是在gcc上加了自己的组件对安卓优化，根本没重新做编译器，不过gcc有各种各样的问题的也不奇怪 ...

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


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

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

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

就算是抨击华为也没事吧，毕竟方舟编译器本身就有问题，而且华为的宣传口径也有问题，没道理不让人说，clang好像被Google指定为NDK的编译器了，不过实际上换了编译器能好多少又是另外一码事了。
作者: 不点    时间: 2019-10-27 14:57
抨击了谁，谁就不太舒服。至于说人家会怎么反应出来，不同的人可能有所不同。假如有人抨击了我，我的反应可能不会太强烈。但假如我抨击了别人，别人的反应会怎样，这可不容易预料。所以，还是尽量避免抨击别人吧。

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

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

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

作者: 求道者    时间: 2019-10-27 15:10
本帖最后由 求道者 于 2019-10-27 15:11 编辑
不点 发表于 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
本帖最后由 不点 于 2019-10-27 17:37 编辑
求道者 发表于 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
不点 发表于 2019-10-27 16:15
对呀。现实与理想，就差很远。正是因为有差距、有不满，它才能不断前进，才有前进的余地。

那个 risc- ...

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

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

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

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

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

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




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

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

我是这个软件的开发者啊，所以，有印象呗。要是别人的闭源软件，能通过看字节找出毛病来，那才是真有能耐。
作者: hilsonma    时间: 2019-10-28 14:45
本帖最后由 hilsonma 于 2019-10-28 15:09 编辑

楼主能不能把最新编译的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
这里也有源代码，楼主也可以看看用的源代码是不是跟这里的一样。
作者: 求道者    时间: 2019-10-28 16:48
hilsonma 发表于 2019-10-28 14:45
楼主能不能把最新编译的wee63.mbr放上来，看你和不点的一番讨论，或许你新编译的会好一些吧。

顺便说一 ...

我放出来了，你仔细看，源码我直接用的主干代码。
作者: hilsonma    时间: 2019-10-28 20:33
求道者 发表于 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-28 20:44
本帖最后由 求道者 于 2019-10-28 21:33 编辑
不点 发表于 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。
作者: 求道者    时间: 2019-10-28 20:59
本帖最后由 求道者 于 2019-10-28 21:31 编辑

我大概猜出了这个问题的症结……
总之就是C佬不知道用了什么编译器和编译环境编译出的wee有问题……
然后BOOTICE内嵌了那个……
weesetup也内嵌了那个……
然后就出问题了……
应该就是bootlace位置的问题……
至少BOOTICE1.3.4要返工，把写入外部wee的选项弄出来，还有更换内嵌的wee63.mbr
weesetup也要这么搞……
作者: 求道者    时间: 2019-10-28 21:28
本帖最后由 求道者 于 2019-10-28 21:42 编辑
不点 发表于 2019-10-27 18:36
一系列简单的东西，堆积成复杂的——我赞成这样的。

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


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

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

对于总会迎来的终结没有什么值得在意的……
现在这个阶段遇到任何问题我都不会奇怪，而且我已经遇到过了……
作者: 2011yaya2007777    时间: 2019-10-29 10:03
我使用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 试一试，看看正常与否，再进一步讨论。



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


原始菜单没问题，但改菜单就会出问题。
作者: 2011yaya2007777    时间: 2019-10-29 16:24
这是我编译的 wee63.mbr。
编译 weesetup 通不过，缺少 mbr.h .

wee63.mbr.txt

30.97 KB, 下载次数: 3, 下载积分: 无忧币 -2

作者: 求道者    时间: 2019-10-29 16:35
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 output file bin/weesetup.exe: No such file or directory
作者: 求道者    时间: 2019-10-29 17:03
2011yaya2007777 发表于 2019-10-29 16:24
这是我编译的 wee63.mbr。
编译 weesetup 通不过，缺少 mbr.h .

回去我用hex编辑器看看
作者: 求道者    时间: 2019-10-29 21:19
本帖最后由 求道者 于 2019-10-29 21:21 编辑
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
求道者 发表于 2019-10-29 21:19
你用gcc4.5编译的wee64.mbr吧……
体积大不少
但偏移常数是对的

fsys_ext2fs.c:39:1: 错误：对‘log2_tmp’的静态声明出现在非静态声明之后

修改fsys_ext2fs.c 37～44行
把
  1. static __inline__ unsigned long
  2. log2_tmp (unsigned long word)
  3. {
  4.   __asm__ ("bsfl %1,%0"
  5.            : "=r" (word)
  6.            : "r" (word));
  7.   return word;
  8. }
复制代码


移动到shard.h 389行，覆盖原来的
  1. extern inline unsigned long log2_tmp (unsigned long word);
复制代码

作者: 求道者    时间: 2019-10-29 22:47
本帖最后由 求道者 于 2019-10-29 22:52 编辑
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
复制代码

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

这个和我编译grub4dos的时候遇到的错误一样.我不懂汇编,所以没办法了
作者: 求道者    时间: 2019-10-29 23:06
wintoflash 发表于 2019-10-29 22:57
这个和我编译grub4dos的时候遇到的错误一样.我不懂汇编,所以没办法了


这个能搞定的话，应该能连同grub4dos一起迁移到gcc9吧……

yaya救命啊
作者: 不点    时间: 2019-10-30 10:17
本帖最后由 不点 于 2019-10-30 10:37 编辑
求道者 发表于 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
不点 发表于 2019-10-30 10:17
贴出 248 行以及 375 行附近的代码看看，汇编代码的错误，应该有办法解决。

忽然想起来了，可能没法 ...

248行和附近
  1. /* begin characteristics distinguish this sector from others */
  2.     .byte    0x8E, 0xDB        //movw    %bx, %ds
  3.     .byte    0x68, 0xE0, 0x07    //pushw    $0x07E0
  4.     .byte    0x07            //popw    %es    /* ES=0x07E0 */

  6.     //cmpl    $0xCE1A02B0, (wee63_signature - _start1 + 4 + STAGE2_SIZE - 4)
  7.     .byte    0x66, 0x81, 0x3E    //cmpl
  8.     .word    (wee63_signature - _start1 + STAGE2_SIZE)
  9.                 //this word is a pointer to the bootlace
  10.                 //signature near the end of pre_stage2
  11.                 //this word varies according to STAGE2_SIZE.
  12.     .byte    0xB0, 0x02, 0x1A, 0xCE    //this is the bootlace signature.
  13.                     //it should also appear at near the end
  14.                     //of pre_stage2
  15. /* end characteristics distinguish this sector from others */
复制代码


375行和附近
  1.         movb        $0x80, %dl        /* try hard drive first */
  2. 1:
  3.         xorl        %eax, %eax
  4.         pushaw
  5.         pushl        %eax
  6.         pushl        %eax
  7.         pushw        %es
  8.         pushw        %ax
  9.         pushw        $127        //$63
  10.         pushw        $0x10
  11.         movw        %sp, %si        /* DS:SI=SS:SP=disk address packet */
  12.         movw        $0x4200, %ax
  13.         call        int13
  14.         popaw
  15.         popaw

  17.         /* compare the sector to the MBR, ignoring BPB */

  19.         movw        $0x5A, %si
  20.         movw        %si, %di
  21.         movw        $((0x200 - 0x5A) / 2), %cx
  22.         cs repz cmpsw
  23.         je        1f
  24.         testb        %dl, %dl        /* floppy tried? */
  25.         je        Error_or_prev_MBR        /* yes. fail */
  26.         movb        $0, %dl                /* then try floppy */
  27.         jmp        1b
  28. 1:

  30.         movw        %es, %bx
  31.         addw        $((wee63_signature - _start1 + 4 + STAGE2_SIZE - 4) >> 4), %bx
  32.         movw        %bx, %ds

  34.         cmpl        $0xCE1A02B0, ((STAGE2_SIZE - 4) & 0x0F)
  35.         jne        Error_or_prev_MBR        /* Missing helper */
  36. 2:
  37.         ljmp        $0, $0x8200
复制代码

作者: 求道者    时间: 2019-10-30 21:12
不点 发表于 2019-10-30 10:17
贴出 248 行以及 375 行附近的代码看看，汇编代码的错误，应该有办法解决。

忽然想起来了，可能没法 ...

clang编译 报这个错
  1. clang -m32 -mno-sse -g  -c asm.S -o ./asm.o
  2. asm.S:7618:5: error: invalid operand for instruction
  3. cs lodsb
  4.     ^~~~~
  5. asm.S:7627:5: error: invalid operand for instruction
  6. cs lodsb
  7.     ^~~~~
  8. asm.S:8566:15: error: unexpected token in argument list
  9. addr32 loopz 1b
  10.               ^
  11. make: *** [Makefile:66：asm.o] 错误 1
复制代码
作者: 不点    时间: 2019-10-31 02:19
求道者 发表于 2019-10-30 21:02
248行和附近

这个已经说过了，是新版 gcc 编译的二进制结果体积太大导致的，无解。就是 STAGE2_SIZE 超级大，很多 M 字节。你的编译过程中，应该出现这个超级大的中间结果文件，那就是新版 gcc 编译出的中间结果文件。
作者: 不点    时间: 2019-10-31 02:40
求道者 发表于 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
本帖最后由 求道者 于 2019-10-31 13:01 编辑
不点 发表于 2019-10-31 02:40
clang 的汇编器可能不支持前缀 cs 和 addr32 等。解决办法：

把 cs lodsb 写成两行：

  2. make
  3. make WEE127=1 BUILDIDUNSUPPORTTED=0 wee127/wee63.mbr
  4. make[1]: 进入目录“/home/daiaji/grubutils/grubutils/wee”
  5. clang -m32 -mno-sse -g -DMBRSECTORS127 -c asm.S -o wee127/asm.o
  6. asm.S:4218:12: error: unknown token in expression
  7. lcall %cs:*(ROM_int15 - int13_handler)
  8.            ^
  9. asm.S:5708:12: error: unknown token in expression
  10. lcall %cs:*(ROM_int15 - int13_handler)
  11.            ^
  12. asm.S:5789:11: error: unknown token in expression
  13. ljmp %cs:*(ROM_int15 - int13_handler)
  14.           ^
  15. asm.S:5835:11: error: unknown token in expression
  16. ljmp %cs:*(ROM_int15 - int13_handler)
  17.           ^
  18. asm.S:5872:12: error: unknown token in expression
  19. lcall %cs:*(ROM_int15 - int13_handler)
  20.            ^
  21. asm.S:6042:12: error: unknown token in expression
  22. lcall %cs:*(ROM_int15 - int13_handler)
  23.            ^
  24. asm.S:6169:11: error: unknown token in expression
  25. ljmp %cs:*(ROM_int15 - int13_handler)
  26.           ^
  27. make[1]: *** [Makefile:66：wee127/asm.o] 错误 1
  28. make[1]: 离开目录“/home/daiaji/grubutils/grubutils/wee”
  29. make: *** [Makefile:55：wee127/wee63.mbr] 错误 2
复制代码
而且clang不支持-mpreferred-stack-boundary=2
作者: 不点    时间: 2019-10-31 15:08
本帖最后由 不点 于 2019-10-31 16:40 编辑
求道者 发表于 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 的情况也可以用这种方法来处理。



作者: 求道者    时间: 2019-10-31 18:42
本帖最后由 求道者 于 2019-10-31 18:56 编辑
不点 发表于 2019-10-31 15:08
这次的错误其实只有一个：都是不认识 %cs:*(ROM_int15 - int13_handler)

这很容易搞。试试两个办法， ...
  1. asm.S:4218:2: error: unknown use of instruction mnemonic without a size suffix
  2. lcall %cs:(ROM_int15 - int13_handler)
  3. ^
  4. asm.S:5708:2: error: unknown use of instruction mnemonic without a size suffix
  5. lcall %cs:(ROM_int15 - int13_handler)
  6. ^
复制代码
似乎是编译失败……
但我不不知道产物去哪了……

并没有wee127/asm.o
作者: 不点    时间: 2019-10-31 19:01
说明去掉星号起作用了。它还要求精确的字宽后缀。给指令添加w后缀试试。w代表 word，即 16 位宽度。

就是说，把 ljmp 改成 ljmpw，把 lcall 改成 lcallw。
作者: 求道者    时间: 2019-10-31 19:23
本帖最后由 求道者 于 2019-10-31 19:29 编辑
不点 发表于 2019-10-31 19:01
说明去掉星号起作用了。它还要求精确的字宽后缀。给指令添加w后缀试试。w代表 word，即 16 位宽度。

就 ...
  1. make
  2. make WEE127=1 BUILDIDUNSUPPORTTED=0 wee127/wee63.mbr
  3. make[1]: 进入目录“/home/daiaji/grubutils/grubutils/wee”
  4. clang -m32 -mno-sse -g -DMBRSECTORS127 -c asm.S -o wee127/asm.o
  5. asm.S:4218:9: error: invalid operand for instruction
  6. lcallw %cs:(ROM_int15 - int13_handler)
  7.         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  8. asm.S:5708:9: error: invalid operand for instruction
  9. lcallw %cs:(ROM_int15 - int13_handler)
  10.         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  11. asm.S:5789:8: error: invalid operand for instruction
  12. ljmpw %cs:(ROM_int15 - int13_handler)
  13.        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  14. asm.S:5835:8: error: invalid operand for instruction
  15. ljmpw %cs:(ROM_int15 - int13_handler)
  16.        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  17. asm.S:5872:9: error: invalid operand for instruction
  18. lcallw %cs:(ROM_int15 - int13_handler)
  19.         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  20. asm.S:6042:9: error: invalid operand for instruction
  21. lcallw %cs:(ROM_int15 - int13_handler)
  22.         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  23. asm.S:6169:8: error: invalid operand for instruction
  24. ljmpw %cs:(ROM_int15 - int13_handler)
  25.        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  26. make[1]: *** [Makefile:66：wee127/asm.o] 错误 1
  27. make[1]: 离开目录“/home/daiaji/grubutils/grubutils/wee”
  28. make: *** [Makefile:55：wee127/wee63.mbr] 错误 2
复制代码

作者: 不点    时间: 2019-10-31 19:57
这次报操作数错误。试试去掉%cs:，在指令前面插入一行 .byte 0x2E
作者: 求道者    时间: 2019-10-31 20:03
不点 发表于 2019-10-31 19:57
这次报操作数错误。试试去掉%cs:，在指令前面插入一行 .byte 0x2E

make
make WEE127=1 BUILDIDUNSUPPORTTED=0 wee127/wee63.mbr
make[1]: 进入目录“/home/daiaji/grubutils/grubutils/wee”
clang -m32 -mno-sse -g -DMBRSECTORS127 -c asm.S -o wee127/asm.o
asm.S:4220:9: error: invalid operand for instruction
lcallw (ROM_int15 - int13_handler)
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~
作者: 不点    时间: 2019-10-31 20:29
添加星号试试
lcallw *(ROM_int15 - int13_handler)

如果不行，再试试

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

看哪个能成功。注意星号和 w 之间有空格。
作者: 求道者    时间: 2019-10-31 20:45
不点 发表于 2019-10-31 20:29
添加星号试试
lcallw *(ROM_int15 - int13_handler)

-rw-r--r-- 1 daiaji daiaji 126M 10月 31 20:44 wee127.mbr
-rw-r--r-- 1 daiaji daiaji 126M 10月 31 20:44 wee63.mbr
能编译但是产物非常大
代码我改成这样了

  1.          .byte 0x2E
  2.         lcallw        *(EXT_C(ROM_int15) - int13_handler)

  4.         .byte 0x2E
  5.         ljmpw        *(EXT_C(ROM_int15) - int13_handler)
复制代码

作者: 不点    时间: 2019-10-31 21:08
这么大的文件，是错的。我猜可能是操作系统底层更改造成的。算了，不折腾了。安心用旧版 gcc 编译吧。
作者: 求道者    时间: 2019-10-31 21:34
本帖最后由 求道者 于 2019-10-31 21:35 编辑
不点 发表于 2019-10-31 21:08
这么大的文件，是错的。我猜可能是操作系统底层更改造成的。算了，不折腾了。安心用旧版 gcc 编译吧。


前面汇编代码部分似乎被充了很多零，然后菜单前面有100M多的零.
可能是填充出了问题，gcc是对的。
作者: 不点    时间: 2019-10-31 21:40
求道者 发表于 2019-10-31 21:34
前面汇编代码部分似乎被充了很多零，然后菜单前面有100M多的零.
可能是填充出了问题，gcc是对的。

跟踪 Makefile 的执行过程，可以了解究竟是哪个步骤增大了体积。
作者: 求道者    时间: 2019-10-31 21:44
不点 发表于 2019-10-31 21:40
跟踪 Makefile 的执行过程，可以了解究竟是哪个步骤增大了体积。

pre_stage2 非常大
这不正常吧？
作者: 不点    时间: 2019-10-31 22:26
这个 pre_stage2 是 gcc 生成的，是编译过程生成的。情况与 grub4dos 一样，无解了。老老实实用旧版 gcc 吧。
作者: 求道者    时间: 2019-10-31 22:43
本帖最后由 求道者 于 2019-10-31 22:47 编辑
不点 发表于 2019-10-31 22:26
这个 pre_stage2 是 gcc 生成的，是编译过程生成的。情况与 grub4dos 一样，无解了。老老实实用旧版 gcc 吧 ...


好消息恐怕是，两者的迁移经验应该是差不多的，未来也许能完成迁移……
谁知道这东西是怎么生成的？
作者: 不点    时间: 2019-11-1 17:05
求道者 发表于 2019-10-31 22:43
好消息恐怕是，两者的迁移经验应该是差不多的，未来也许能完成迁移……
谁知道这东西是怎么生成的？

我个人感觉，折腾 gcc 的意义不大。我也不想研究，究竟是 bin-utils 的原因呢，还是 gcc 的原因，拟或是别的什么原因（比如 Linux 内核的原因）。整个 Linux 内核连同 GNU 工具链，都不可靠，而且是越来越不可靠。

我在想，将来或许会有人从以前的某个 Linux 版本以及某个 GNU 工具链开始，重新建立一个新系统。GNU 的 GPL 协议提供了这种可能性。不过，那也许是猴年马月的事了，我不一定能看得到。

我目前对待 Linux 的态度就是，凑合着用。这与我对待 Windows 的态度也差不多是一样的。不要太认真，过一天是一天。至于说 wee 呀，grub4dos 呀，都不是大事，能有一个编译版本用着，就该知足了。能有一个编译方法在网上找得到、行得通，就该满意了。

对待同一件事，不同的人，站的角度不同，态度就不同，结论也不同，处理方法也不同。
作者: 求道者    时间: 2019-11-1 18:19
不点 发表于 2019-11-1 17:05
我个人感觉，折腾 gcc 的意义不大。我也不想研究，究竟是 bin-utils 的原因呢，还是 gcc 的原因，拟或是 ...

你这完完全全就是不符合客观事实的臆测了！
事实就是gcc起码直接告诉你就是pre_stage2生成的有问题！
clang还有一堆汇编方法不支持，要手动汇编！最后pre_stage2还是很大！
没错，clang是没怎么报警告，但这只是说明clang习惯宽松的语法检测！或者干脆不报！
这不能说明clang更好，更先进！

clang还浪费了一堆时间！

感觉顶多就是语法变了！
搞不好还是c的问题！
作者: 求道者    时间: 2019-11-1 18:43
  1. gcc -m32 -mno-sse -g -o 1.bin -nostdlib -Wl,-N -Wl,-Ttext -Wl,308200 -Wl,-N -Wl,--build-id=none ./asm.o ./builtins.o ./disk_io.o ./fsys_ext2fs.o ./fsys_fat.o ./fsys_ntfs.o

  3. ls -alh 1.bin
  4. -rwxr-xr-x 1 daiaji daiaji 122K 11月  1 18:41 1.bin

  6. objcopy -O binary 1.bin

  8. ls -alh 1.bin         
  9. -rwxr-xr-x 1 daiaji daiaji 126M 11月  1 18:41 1.bin
复制代码


我个人的一点点进展
不知道为什么objcopy -O binary之后体积变大
我不知道objcopy -O binary是怎么工作的……
作者: 不点    时间: 2019-11-1 20:14
本帖最后由 不点 于 2019-11-1 20:51 编辑
求道者 发表于 2019-11-1 18:43
我个人的一点点进展
不知道为什么objcopy -O binary之后体积变大
我不知道objcopy -O binary是怎么工 ...


我不懂，所以，臆测一下，也很自然。谁懂，谁就多劳啊！

你这不已经很有成效了吗？发现 objcopy 使得体积变大。抱歉，对这些，我又是完全不懂。

让懂的人来帮你，或者，你自己查资料搞定。

关键是，我俩站的角度不同。我对 Linux 的整体大环境没兴趣了，而你还很有兴趣。我失望了、没有希望了，而你还很有希望。我觉得折腾这些编译没有意义，随便有个编译能够凑合着用也就够了。而你还满怀信心和希望，你不满足于我的那种低标准和低要求。那接下来看看现实世界会朝哪个方向发展，看看实践检验的结果究竟如何。咱也没必要进行争论，实践会检验的。几年以后，Linux、GNU 工具链、发行版的情况变好，能有很大的进展，我倒是希望如此。希望在将来，你不会沦落到像我这么样的地步、像我这么样的心态。恕我直言，对这个 Linux，我目前在逐渐把它看成“又一个 Windows，一个开源的 Windows”，越来越没有新鲜感了。

作者: 9001    时间: 2020-5-20 22:11
求道者 发表于 2019-10-29 15:54
原始菜单没问题，但改菜单就会出问题。

还真是这样。
一旦修改，比如原始菜单修改了写入移动硬盘，以下面一句开头
  1. timeout 1
复制代码

一个偶然的机会，用fbinsttool打开了移动硬盘，发现菜单是以 " t 1"开头，显然是前面6个字符“timeou"被吃掉了。
据此，可以在菜单开始处加上6个空格就OK了。测试也是成功的。

通过fbinsttool可以看到，修改后的菜单结尾有单独一行“-e”，这个会影响到最后一个菜单。需要使用winhex清除或者在它之前加一个隐藏无意义的菜单屏蔽之。
作者: 9001    时间: 2020-5-20 22:14
本帖最后由 9001 于 2020-5-23 23:05 编辑
9001 发表于 2020-5-20 22:11
还真是这样。
一旦修改，比如原始菜单修改了写入移动硬盘，以下面一句开头就是说，如果菜单出了问题，用bootice写入修改的菜单，bootice是看不出来的。
但是，fbinsttool可以非常直观地再现菜单问题，与实际启动后显示的一致。
现在的解决办法是：
1、winhex大法，尽管bootice写入的菜单地址是0x7850，之前有那么6个字节的乱码，用winhex把6个乱码清零，从7850处复制菜单，把菜单情况的-e清零。
2、使用上面28楼求道者编译的WEE63.mbr，使用bootice导入到MBR。当然，可以事先把自己的菜单使用hex编辑器修改好。





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