# BOTO的中文显示和正常运行

- 项目简介
- 功能需求
- 存在问题
- 项目进展
- 设计实现

##　当前开发人员 (20160801-20160831)
- 陈威 - 完成了BOTO的中文显示和正常运行

#BOTO 开发阶段总结

##项目简介
本项目是OpenTHOS项目的一个子项目，其目的是为OpenTHOS(一个基于Android-X86发展而来的桌面操作系统）提供一个图形化的启动管理器。

##功能需求

| 功能需求        | 完成  |           备注                    |
| ----------------|:-----:|:--------------------------------- |
| 启动管理器      | 完成 缺PC显示测试  | 基于refind，已经添加对openTHOS内核的识别，openTHOS内核的引导文件应取名为otoVmlinuz   |
| BOTO背景图      | 完成 缺PC显示测试  | 支持PNG格式的桌面背景图  |
| 中文支持        | 准完成 缺PC显示测试 | 已经实现UEFI对中文的支持，正往BOTO中集成，预计今日完成  |
| 动态显示分辨率   | 准完成 缺PC显示测试 | 已经在测试程序中实现的系统UEFI支持的分辨率的检测，能够切换到最佳分辨率上进行显示 |

##辅助性工作
1. **了解UEFI开发环境**  
　　Intel为首的Tianorcore开源组织为UEFI实现完全不同以往的编译环境。编译器可以是VisualStudio，也可以是gcc，更可以是Intel EBC Compiler。但是配置UEFI程序的编译规则即不是VisualStudio的工程文件sln，也不是GCC的Makefile。UEFI对所有的代码进行了按包Pkg管理，具体某个程序或是库则称之为Module, 如AppPkg即是参考代码的一个包，而其中Applications/Helloword则为一个Module。关于AppPkg使用于AppPkg.dsc和AppPkg.dec来描述，而Hellowrod则由Helloword.inf来描述，这三个文件一起决定了Helloword是如何编译的。全新的规则需要花费一定的时间来学习。当然也有gnu-uefi这样的一个简易环境来编译程序，但不是所有的程序都可以由gnu-uefi来进行编译。
2. **学习基于Glyph的字库**  
　　UEFI使用了Glyph格式的系统字库，半角为8x19的点阵，全角16x19的点阵，如下所示为中文"东"的Glyph表示。  
`{ 0x4e1c, 0x00, { 0x00,0x00,0x00,0x00,0x00,0x0c,0x0c,0xff,0x19,0x31,0x71,0x7f,0x01,0x19,0x31,0x61,0xc3,0x1f,0x00 },
                  { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xfc,0x00,0x00,0x00,0xf8,0x00,0x60,0x30,0x1c,0x0c,0x00,0x00 }, { 0x00,0x00,0x00 } }, //东`  
　　有了某个汉字的Glyph以后，则需要按UEFI的规则将Glyph打包成字库，并将字库装入系统中。
　　但问题是UEFI开发环境几乎没有文档，前面的开发环境还有资料介绍，而到这一块Intel前员工的书籍中看似有介绍，但其所提供的示例代码一经编译，无法编译通过。于是回过头翻看Tianocore的edk2的代码，一点点扣出其是如何支持英文及法文的。通过这样的蛛丝马迹来推导中文的字库支持。
3. 各平台上UEFI引导问题
　　该问题的由来是，测试组反应，在同方的某些机器上，openTHOS liveUSB无法引导。经过测试，并非在同方平台无法引导，事实是各个平台上都无法进行纯UEFI的引导，原因是更新后的openTHOS liveUSB使用了grub2而不是grub2efi作为启动引导器。因此暂时基于grub的liveUSB应该设置UEFI环境的支持legacy模式的引导。
　　测试组后续又反应系统不能识别安装到硬盘的grub2efi，经研究发现，属于取名的问题，UEFI平台能够直接识别作为启动引导器的程序应处于ESD分区/EFI/boot/下，文件名为boot.efi或是bootIA32.efi(32位平台)或是bootX64.efi(64位平台)。其它位置或名称的必须由安装程序或手工添加的NVRAM中的启动列表中，才可启动。
3. **非UEFI程序及库到UEFI的移植**  
　　Refind本身过于冗长，且不支持多国语言，后期维护工作量大。代码之间互关联性比较高。且目前的中文支持方法，属于逐程序增加系统字库。如果将所GB18030字符都添加到系统字库中，系统的运行效率将极其低下，而如果只添加使用到的字符，则每改一个字符都需要仔细，以避免漏字。  
　　因此不论是基于代码维护的需要，还是简化字体支持的需要都需要进行一些其他程序及库到UEFI的移植工作。如freetype。
　　目前的现状是：已经能够创建新的包，暂为BOTO创建了一个BotoPkg，freetype也完成了在EDK2下编译的移植。但尚未进行基于freetype的应用测试。

##存在问题
1. **UEFI环境下显示分辨率问题**  
　　测试了多台机器，即使其显示器的分辨率为1366x768，UEFI也不支持该分辨率的显示输出。应该是UEFI平台的问题，目前只能在存在该问题的机器上按1280x800进行显示输出。
2. **启动顺序问题**
　　经测试发现，如果在安装BOTO之后再安装Windows等操作系统，则可能导致系统的默认引导不再是BOTO。  
　　目前解决方案是，进入UEFI设置环境，手动将BOTO设置为第一引导项。未来可以由BIOS厂商检测硬盘的ESD分区，发现/EFI/boto/bootX64.efi，则强制从这里启动。

##下一步工作重点
1. 由refind演进到自主BOTO
2. BOTO支持动态多国语言
3. BOTO中集成gmssl的efi程序验证
