grub4dos0.45c/0.46a最新版底部说明汉化

不点

我觉得这个可以集成到正式发布版中。以下是我的思路，供 chenall 参考。

grub4dos 要处理菜单，这是肯定的。无论内置还是外置，它都是菜单，也都要经过 grub4dos 的菜单读取程序进行处理。在读取菜单的时候，可以通过分析，确定菜单的 title 中是否含有 utf8 编码的汉字，如果有，就记录在某个全局变量中，比如说 lang=zh 之类的。同时，修改菜单显示程序，让它在 lang=zh 时显示中文信息，而不是显示英文信息。

不点

lgl007 发表于 2015-5-27 22:09
我试了一下，用上下箭头选择菜单后，再按E键就可以进入命令行，刚刚进入后按E键进入死机状态。这还得请chen ...

你自己就能测试啊，你有测试条件。换成别人测试，即使成功了，也不能证明在你的机器上也成功。

不点

lgl007 发表于 2015-5-28 09:10
两位老大，我只是把菜单中底部说明改成了中文，别的源文件没有改动，这有关系吗？0.45C版本的grub4dos也是 ...

你确信你的改动不会对程序本身产生影响吗？我猜测恐怕是你的改动有 bug 吧？

要不你换编译器（或者换操作系统）再试一次，因为以前也确实因为编译器的问题产生过错误。

或者你让别人在别的环境进行编译（比如在某个 Linux 系统下编译）。

不点

还是 chenall 自己弄吧，不用再麻烦楼主了。

把某些东西汉化。如果时间不够，就只把菜单部分汉化。如果时间充裕，就连 help 中的信息也可汉化。

不点

2011yaya2007777 发表于 2015-5-29 06:34
同感

通过菜单设置标志，分别显示帮助菜单的中英文。这个我来处理吧。

可能是我没把意思表达清楚吧（我现在语文水平也在下降，这是自然规律）。

我的意思是，grub4dos 内核在读取菜单的时候，要处理 title （和 iftitle）命令并且保存 title 的内容到内存数组中。

在处理 title 的过程中（或者也可在全部 title 数组保存之后），立即检查 title 的字符串数组中是否含有 UTF8 格式的汉字。如果有，就把默认的 lang 变量设置为 zh。

lang 变量需要重新建立，它的默认值是 0 或者是空的字符串。lang 的变量名只是举例，我不懂 linux 和 windows 关于地区语言设置方面的约定，所以，你可以寻找一个更恰当的名字。lang 的变量类型可以是整数型，也可以是字符串型，依你的权衡而定。同样，其值可以是 zh 或 cn 或 zh_CN 之类的，我也不知道究竟怎么才好。也可以查阅有关语言设置方面的 RFC 文档。

这整个过程是在 grub4dos 的内核中处理的（是在内核的菜单处理部分进行处理的；也就是说，是自动的，无需用户干预），不是在菜单中由用户设置来处理的。当然用户也可以在菜单中设置 lang 变量，这样就强制覆盖了 grub4dos 从 title 中探测到的语言类型。

当读取一个 menu.lst 时，grub4dos 都要给出一个探测到的 lang 值。目前可以只探测中文，不探测别的语言。当未探测到中文时，lang 应该保持默认值（即空的字符串值；如果是整数，则为0）。在 menu.lst 中，当遇到用户设置 lang 变量时，以用户的设置为准。

lang 变量可以放在 grub4dos 的固定变量区。甚至也可以在 builtins.c 中为它创建一条同名的命令（添加lang_func() 函数）。

如果把 lang 放在固定变量区，我觉得最好不要放在 0x8200 处的区域，因为这个区域是在常规内存中，很宝贵。我们应该节约常规内存，因此，可以放在第二块固定变量区中，即，放在 0x307000 至 0x308200 这个区域中。其实我已经在第二个固定变量区中放置了几个变量。比如说，我在 0x308000 处放置了 cpu 的信息，占用 32 字节（即 8 个四字节整数的长度）：

unsigned int *sig = (unsigned int *)0x308000; //&vm_cpu_signature;

在 0x307FFC 处放置了 preset_menu 变量（四字节整数）。
在 0x307FF8 处放置了 use_preset_menu 变量（四字节整数）。

我不知道 chenall 后来有没有使用这个空间。如果没有使用，你可以接着使用 0x307FF4，0x307FF0，……，一直到 0x307000，都是可以使用的。个别大块的字符串变量，可以使用 0x308020 至 0x308200 的空间（因为 刚才说了，0x308000 处的 32 字节已经用于 cpu 信息了）。

内核在显示菜单的时候，可以根据 lang 变量的值，来决定显示中文或英文。举例来说，如果 lang 的值是 zh，就显示中文，否则，显示英文。当然，如果是文本模式，那只能显示英文。必须进入 VBE 图形模式以后，才可以显示中文。

整个过程是自动的，不需要用户在菜单中有任何设置。用户以前的菜单不需要进行任何修改，只要换成新版，就能够自动处理中文。用户唯一需要保证的是，title 行上能够找到一个 UTF-8 编码的中文字符。只要满足这个条件，剩余的事都是 grub4dos 内核的工作了。

希望这次我说明白了。如果还有不清楚的，请继续交流。


关于汉字探测，再提醒一点需要注意。grub4dos 只支持 65536 个 Unicode 字符，也就是 BMP 的 unicode 字符。超过这个范围的汉字是不支持的，无需探测。

不点

chenall 发表于 2015-5-29 10:31
我倒是有另外一个想法.

首先把内核里面的英文资源全部提取出来到某个文件或数组中(也比较方便进行翻译等 ...

这也不错。现在上了年纪，不再研究新知识了，我不知道其他国际化的软件，通常都是怎么做的。可以参考借鉴别的软件的做法。

如果需要放在文件里面，可以考虑放在 unifont.hex 的开头，与字库共用一个文件。

另外，我觉得，英文是默认的，应该内嵌到二进制文件的程序体里面（就像目前这样）。

其他主要语言（中、法、西、俄等）也都可以内嵌（可以采用数组的方式）。

help 的内容不翻译，因为内容太多，其占用空间太大。使用 help 的人大多都是有一定基础的，可以看懂英文。可以搞个外部的 txt 文件，用 cat 命令来看文档（需要不同语言的翻译者来翻译文档；现在是网络时代，也可以使用谷歌翻译）。

如果不翻译 help，那么，剩下的那些与语言有关的字符数已经不多了，完全可以支持所有的语言（需要有不同国家的贡献者才能支持相应的语言；现在是网络时代，也可以使用谷歌翻译）。

以前我还提到过一个想法，就是把倒计时的秒数显示在靠近高亮条的最右端（与高亮条处于同一行）。倒计时所使用的阿拉伯数字是全球通用的，因此不用任何提示信息。

不点

lgl007 发表于 2015-5-29 08:20
chenall、不点、yaya各位老大你好：
   附件为在colinux系统下用git clone下载的0.45c的源码，然后在cdlin ...

buff 的缓冲区只有 256 个字节。UTF8 汉字太长，每个汉字占用 3 字节，整个字符串超过了 256 字节，造成字符串溢出，引起程序错乱和死机。

你把 buff 的定义扩大为 512 字节，应该不会出问题了。

不点

2011yaya2007777 发表于 2015-5-29 13:10
看了一下 diff 文件，没见端倪。按说修改显示信息，最多是翻译错误，不可能引起按键出错。

能内部自动判 ...

世上什么事都有可能。不可能的事发生了。前面我已经指出了错误的根源。

buff 这个变量的空间只有 256 个字节。strcpy 函数把 utf8 汉字字符串拷贝到 buff 上，导致溢出，立即死机。

buff 是在堆栈上，所以，溢出是会导致立即死机的。像这样的错误是最容易调试出来的了。

死机有利于排错。只要死机，这个错误就不难查到。

不点

2011yaya2007777 发表于 2015-5-29 14:43
我这里，使用提供的 diff 修改源码，编译后测试，没有问题。

数数拷贝到 buff 上的字节数，看看是否溢出。如果没有溢出，那就不是这里的问题。

那就可能是编译器的问题了。你的编译环境与楼主的不同？也许是 Windows 的问题？

我刚刚数了一遍，确实是超限了。

光是拷贝到 buff 上的汉字（中文标点符号也是一个汉字），就满满 80 个。这占用 UTF-8 的字节长度 = 80 × 3 = 240 个。再数数其中的英文字符和空格，很快就知道超过 16，没有精确去数。但超过 16 个字节。两者相加就超过 256 字节了。

你没遇上死机，是不是因为你没有按 e 键进入编辑状态？你按 e 键试试看？

不点

2011yaya2007777 发表于 2015-5-29 17:02
进入菜单后，直接按 e 键，没有问题。再按 e 键也没有问题。
那里有个判断语句 config_entries ？... : .. ...

我不知道是不是因为标点符号造成的，也许中文的标点符号只占用两字节？再仔细数一遍：

1.         i = grub_sprintf (buff,"\n 用 %c 和 %c 两键将一个菜单置为高亮。"

复制代码

其中，汉字是 13 个。中文的句号 1 个。英文的回车符 1 个，英文空格 5 个，英文的 char 有 2 个。

1.         " 在当前行，按  \'e\' 键进行编辑，按 \'d\' 键删除，"
   
2.                 " 按 \'O\' 和 \'o\' 两键可在其之前或之后插入一个新行。当编辑结束时，"
   
3.                 "按 \'b\' 键启动，按 \'c\' 键进入命令行，按 ESC 键退回到主菜单。"

复制代码

其中，汉字是 57 个。中文的逗号和句号 8 个。英文的单引号 12 个，英文空格 17 个，英文的 char 有 9 个。


这样，汉字总数是 70 个，中文的逗号和句号 9 个。英文字符共有 1+5+2+12+17+9=46 个。

70×3=210
9×2=18（姑且把中文标点符号按 2 个 utf8 字节计算，不一定对，也许是 3 个）。

这样，210 + 18 + 46 = 274，仍然是超过 256 的！

如果中文标点符号占 3 个字节，那就是 210 + 27 + 46 = 283 个字节。

这与你调试得到的 233 不符啊？问题究竟在哪里？

【更新】

我似乎猜到是怎么回事了。你只计算了第二个字符串的长度，却没有计算第一个字符串的长度。第一个字符串的长度正好是 50 个字节，这样，283 - 50 = 233 就是你调试得到的值。但这不是从 buff 处放置的字符串，而是从 buff + i 处放置的字符串。此处 i = 50，因此，这仍然是要溢出的。

不点

zqywult 发表于 2015-5-29 17:33
请把您编译的按e键没有问题的汉化版分享一下，谢谢！！！

我觉得这个版本仍然存在缓冲区溢出问题，它只不过没有引起死机罢了。这不是一件好事。死机能暴露出问题，不死机会让问题隐藏起来。如果某个编译器自动把 buff 放在 “堆” 内存而不是 “栈” 上，那就有可能避免死机。但只要溢出，会破坏堆内存的数据，是个隐患。因此我认为，这个版本不可靠。

不点

lgl007 发表于 2015-5-29 17:39
chenall、不点及各位老大，你们好：
    根据不点老大的意见，我对汉化的文字进行了精简，终于解决了死机 ...

这个版本是安全的，不再发生溢出。

1.                 "\n用%c和%c两键将一个菜单置为高亮。"
   
2.                 "在当前行，按 e 键进行编辑， d 键进行删除。"
   
3.                 " 按 O 和 o 可在分别其之前或之后插入一个新行。编辑结束时，"
   
4.                 "按 b 启动，c 键进入命令行，ESC 键退回到主菜单。"

复制代码

汉字 67 个。中文标点 9 个。英文字母 11 个，回车 1 个，英文空格 13 个。

总字节数为 67×3 + 9×3 + 11 + 1 + 13 = 253，距离 256 还有 3 个字符的空间。如果连字符串结尾的 Null 字节计算在内，则有 2 个字节的空间。

不点

等待秒数放在高亮处，英文说明也要改一改了。怎样写合适？

什么地方还需要英文说明？倒计时只在高亮条右端显示秒数，不显示任何英文说明。地球人一看就明白，无需说明。

增加 jpg 格式支持，有什么潜在问题？

这个应该不会有问题吧。如果有问题的话，我猜可能出现在 malloc 分配内存。你最好避免使用 malloc 函数。

不点

2011yaya2007777 发表于 2015-5-29 19:54
我是说这句话
" The highlighted entry will be booted automatically in %d seconds."

我的意思也正是要删除这句话。既然倒计时的秒数显示在高亮条上，就不需要这句话了。这样也就节约了它所占用的内存空间以及也同时节约了屏幕上的一行显示空间。另外一个好处，也不用翻译成各种语言了，所节约的空间是海量的。

不点

chenall 发表于 2015-5-29 21:44
增加 jpg 格式支持,应该没有什么潜在的问题,主要是没有人做这一块,我也不熟,半吊子.

按照我的理解，好像是 yaya 自己要做这个工作。你支持了 bmp 图片，是一个很大的工作。yaya 想锦上添花，再支持比较常用的 jpg 图片，这能够大大减少图片的体积。

顺便说，内存占用不可以太大。屏幕顶行显示的 End: 内存地址不要与其他内存数据发生重叠。End：处所显示的内存地址，大致反映了 grldr 程序的 bss 变量所占据的内存。

为了节约内存空间，必要时，可以去掉 splashimage 命令。我们没必要在新版本中继续支持用于 vga 模式的 splashimage 命令。

不点

报告一下有关国家地区语言代码的搜索结果。

首先，两个字母组成的语言代码，似乎已经成为事实工业标准。它已经被广泛采用。举例来说，zh 表示中文，en 表示英文。

其次，关于国家地区代码，也已形成 iso 国际标准。同样地，两个字母也已经被广泛采用。比如，cn 代表中国大陆，tw 代表中国台湾，us 代表美国，gb 代表英国。需要注意的是，英国不是 uk，这很容易弄错（网上确实发现有人弄错了）。乌克兰的代码也不是 uk。而且 uk 是特别保留的，任何国家都不能使用这个代码。

第三，语言代码和地区代码合成为一个代码，中间的用下划线或者减号来连接，这很混乱，两种用法都有。

第四，语言代码似乎约定俗成都使用小写字母，而地区代码则有使用小写的，也有使用大写的。这比较混乱。

第五，除了国家地区以外，还有多如牛毛的限定规范，这些规范也都是正式的国际标准。一个精确表示某个语言的字符串，可以长达 40 字符左右，也许这还不是最长的。

第六，zh_Hans 和 zh_Hant 分别表示简体中文和繁体中文，也符合正式的国际规范。但使用得不普遍。

总结一下，语言和地区两者合起来基本可以满足电脑软件国际化的需要。其他多余的修饰一般是用不到的。

至于说究竟如何在 grub4dos 下使用，以下是两种参考方案。

第一种，采用四字节整数，恰好包含 两字节的语言代码和两字节的地区代码。语言代码用小写字母，地区代码用大写字母。（为了适应以后的变化，可以采用 8 字节的整数，其高四字节保留）。

第二种，采用字符串，字符串的最大长度定为 64，这样可以适应极其复杂的语言代码。

如果让我来权衡，我感觉第一种比较合适。第二种太过于精细，没有必要。

以上说的是内部存储方式。至于说给用户的命令接口，可以采用 lang=zh_CN 的形式。

以上也只是提供一种思路，供开发者参考。具体实施时，由开发者再进行权衡，作出最终决定。

不点

Fake write 以及 read only 都是 grub4dos 的实模式仿真参数，不是 windows 下的 firadisk 和 winvblock 的仿真参数。这两个驱动程序没有实现 fake write 和 read only 参数。

因此，这两个参数在实模式有效，在 windows 下无效。