如果经常折腾电脑，可能会有过这样一个想法：
“如果操作系统不是 Windows，也不是 Linux，而是自己写出来的，会是什么样？”
真正开始做以后才会发现，操作系统并不是一个简单的“黑屏命令行程序”。
从开机以后看到的第一个字符，到磁盘、文件、内存、程序，再到后来出现的窗口、鼠标，实际上全部需要操作系统自己提供支持。
笔者最近也是一直在折腾一个自己的操作系统项目——AMUNOS。
仓库地址Github
目前这个项目已经能够从 FAT12 引导进入 x86 32 位保护模式，并逐渐拥有了自己的文件系统、Shell、程序加载、C 编译环境以及图形界面。项目使用 C 和 x86 汇编编写，目标并不是做一个能够替代 Windows 的操作系统，而是尝试把一台计算机从启动开始，一点一点做成一个真正“可以使用”的系统。
一、从一个引导扇区开始
AMUNOS 的启动方式其实非常传统。
机器首先从 FAT12 引导扇区启动，然后加载内核，进入 x86 32 位保护模式。
这一过程听起来可能很简单，但真正实现以后会发现，操作系统一开始面对的甚至不是“文件”和“程序”，而是：
CPU
内存
中断
磁盘
键盘
显示器
这些最基本的东西。
AMUNOS 目前采用 x86 32 位环境，没有分页机制，虚拟地址与物理地址保持一致。内核本身主要使用 C 编写，而启动部分和部分底层代码使用 x86 汇编。
这也是自己写操作系统比较有意思的地方。
在 Windows 或 Linux 上，一个程序调用：
printf("Hello");背后可能经过非常复杂的一整套系统。
而在AMUNOS系统里，这个 printf() 最后到底做了什么，完全可以一直追到系统调用、显存和字符绘制代码。
二、真正麻烦的其实是“让程序跑起来”
操作系统能够启动，只能算是第一步。
如果只能打印几个字符，和操作系统还差远了。
因此接下来要解决的问题就是：
程序怎么运行？
AMUNOS 目前使用 ELF32 作为程序加载格式，用户程序可以被系统加载到指定地址，然后跳转到程序入口运行。
同时，系统提供了自己的 int 0x30 系统调用接口。
例如用户程序需要读文件，并不是直接操作硬盘，而是：
用户程序
↓
libc
↓
int 0x30
↓
系统调用
↓
文件系统
↓
磁盘驱动
这样，应用程序就与硬件分开了。
这也是操作系统真正开始有意思的地方。
因为到了这一步，已经可以开始写：
HELLO.ELF
EDIT.ELF
GUI.ELF
而不是把所有功能全部写进内核。
三、最重要的一步：让操作系统自己编译程序
如果一个自己写的操作系统只能运行预先编译好的程序，那有何意义？不能自己给自己编译程序，那只是依赖Windows的空壳而已。
所以 AMUNOS 加入了 TinyCC。
项目中使用 TinyCC 0.9.27，并配套了一个用户态的 minilibc。这样在系统自己的 Shell 里，就可以直接编译 C 程序。
例如：
A:/> TCC USR/SRC/HELLO.C -o HELLO.EXE
A:/> HELLO
HELLO OK FROM TCC
这件事情对于一个 Hobby OS 来说其实很重要。
因为这意味着：
操作系统
↓
编译器
↓
C 程序
↓
操作系统 API
↓
新的程序
开始形成了一个闭环。
也就是说，AMUNOS 不只是“运行在 QEMU 里的一个内核”，而开始具备了软件生态。
当然，目前这个编译环境距离完整的现代 C 开发环境还有很大差距，但这恰恰也是接下来最值得折腾的部分。
内置的移植FreeDOS开源EDIT
四、文件系统：从软盘到硬盘
另外一个非常现实的问题就是：
文件放在哪里？
AMUNOS 目前使用 FatFs 作为 FAT 文件系统后端，并支持 FAT12、FAT16、FAT32，多盘以及跨盘路径。
例如：
A:/>
B:/>
C:/>
D:/>
不同磁盘可以被系统识别和挂载。
目前项目还加入了 IDE、软盘、ATAPI 光驱以及 AHCI SATA 等存储设备支持，并能够读取 ISO9660 光盘。
笔者并不打算把它做成一个完全脱离 DOS 时代的系统。
相反，像：
A:/USR/
A:/SYSTEM/
A:/GAMES/
A:/DOC/
这种路径方式非常直观。
但是 AMUNOS 并不准备完全照搬 DOS。
未来会逐渐形成一套自己的 Shell 操作逻辑。
五、中文
自己做操作系统以后，还有一个问题很容易被忽略：
中文怎么办？
英文字符只有几十种常用字符，直接做一个点阵字库并不困难。
中文则完全是另一回事。
AMUNOS 目前使用 HZK16 点阵字库，并提供 UTF-8 到 GB2312 的转换，同时支持中文文件名和中文显示。
所以现在已经可以做到：
Hello 中文
中英混合 abc 123
你好，AMUNOS！
这种显示。
这也是AMUNOS相对其他自制操作系统最重要的优势之一。
因为这时候它已经不再只是一个英文实验环境。
六、图形界面
到了这里，AMUNOS 又开始走向另一个方向。
如果一直停留在 Shell：
A:/> DIR
A:/> EDIT
A:/> TCC当然也可以使用。
但既然已经到了图形模式，那么为什么不试试自己做一个 GUI？
于是现在有了 AMUNOS Classic GUI。
目前图形系统运行在 640×480、16bpp 的 VBE 帧缓冲上。
窗口由内核中的 GUI Server 管理，每个窗口都有自己的离屏缓冲区，最后再按照窗口 Z 序合成到屏幕上。
用户程序不需要直接操作显存，而是通过 int 0x30 系统调用使用 GUI。
目前已经支持：
窗口
按钮
文本框
多行文本编辑
列表
复选框
单选框
菜单
状态栏
鼠标
中文显示
窗口还可以进行拖动、最小化、最大化和关闭。
七、“另一个 Windows”
做到这里，很容易走进一个 Hobby OS 常见的方向：
自己写一个内核
↓
做 VGA GUI
↓
蓝色标题栏
↓
灰色按钮
↓
做一个“我的电脑”
↓
越来越像 Windows 3.1
这样的系统其实并不少见。
AMUNOS 目前的 GUI 也确实有一些早期 Windows 的影子，但是至少我并不想继续往 Windows 的方向走。太过于前篇一律了，从2000年代的《30天自制操作系统》这本书开始，每个自制操作系统都是这样，毫无新意
工业
复古
信息密集
直接
TUI反而要更加符合我理想的走向
因此目前比较倾向于把 TUI 的思维方式放进 GUI。窗口还是 GUI。鼠标还是可以点。但是视觉语言和信息组织方式更接近 TUI。这可能会成为 AMUNOS 后期较重要的一条路线。
八、到底能干什么？
这是 AMUNOS 接下来的问题。
如果做一个操作系统只是为了：
启动
显示 Hello World
其实做到这里就可以结束了。
但如果继续做下去，就必须开始回答：
这个系统上的软件是什么？
目前已经有 FreeDOS EDIT 移植过来的 EDIT.ELF。
但是我更希望继续做一些具有“人味”的东西。
例如：
AMUN WRITE
一个简单的文字处理软件。
AMUN SHEET
一个非常简单的电子表格。不需要追求 Excel 的复杂程度。只要能够真正完成一些计算，它就是一个完整的软件。
AMUN DRAW
简单的绘图程序。
AMUN SYNTH
甚至可以做一个简单的声音合成器。通过 PC Speaker 或声卡输出声音。这种程序看起来甚至有些“不务正业”，但实际上非常符合早期个人计算机的软件生态。
这像是一个80年代办公室、工作室里的人会干的事。
并没有今天这么复杂的软件。
一个人可以写：
文字处理
绘图
音乐
小游戏
数据库
程序编辑器
这些东西共同构成一台计算机真正的“使用价值”。
九、AMUNOS
现在 AMUNOS 已经逐渐有了：
Boot
│
├── Kernel
│
├── Memory
│
├── Task
│
├── File System
│
├── Device
│
├── Shell
│
├── ELF
│
├── TCC
│
├── libc
│
├── GUI
│
└── Serial
后面还会继续完善：
网络
设备管理
串口
程序开发环境
更多 GUI 控件
更多应用程序
其中网络部分尤其值得期待，如果以后可以做到：
NET
DEVS
PING
CONNECT
等功能，甚至可以让两台运行 AMUNOS 的机器通过内网通信，那么这个系统也算真正开始从“操作系统实验”向“计算机系统”走了一步。
十、写操作系统其实也是一种考古
现在我们接触计算机时，已经很少会关心：
CPU 是怎么进入保护模式的？
磁盘的第一个扇区是什么？
文件系统怎么找到一个文件？
程序怎么加载？
键盘怎么产生中断？
窗口怎么画出来？
，
甚至电脑小白越来越多，电脑不再是钻研的对象，而是使用的工具。我曾在一篇知乎的文章中看到，能自制一个完整操作系统，将会是每个计算机学生最大意义的成就。当再次做回最底层的逻辑时，可曾又仿佛回到70年代家用电脑要自己焊，比尔盖茨在西雅图手搓BASIC的时候？这就是独属计算机的浪漫。
十一、AMUNOS 还远没有完成
目前这个项目仍然有很多地方比较简陋。
例如：
- C 编译器生态仍然有限
- libc 还需要继续完善
- GUI 控件仍然比较基础
- 内存管理仍然需要继续加强
- 网络功能尚未形成完整体系
- 软件生态基本从零开始
- GUI 与 Shell 的操作逻辑还需要进一步统一
还有不少乱七八糟的BUG
但对于一个自己从头写出来的系统来说，这些问题反而是项目的一部分。
毕竟真正有意思的地方并不是“我已经写完了一个操作系统。” 而是 “我正在一点一点制作一个可用的计算机。”
评论区 (2)