一个操作系统项目把386保护模式、Ring-3特权级、VGA文本控制台都做齐了,兼容性对照表里对老版本CP/M的BDOS覆盖率写着100%,可它现在连一块硬盘都读不出来。这就是GitHub上的开源项目CP/M-386——一个把1970年代的CP/M搬进386保护模式的复刻工程,眼下处于作者自己标注的"非常早期"阶段。
它现在能干什么
CP/M-386支持完整32位保护模式,可以用3.5寸软盘MBR或GRUB Multiboot方式引导,控制台走VGA文本或COM1串口。硬件层面兼容386及以后的机型,支持PC BIOS或带CSM的UEFI、8042 PS/2、8250系列UART、CMOS RTC、8253/8254 PIT。
但原文自己写得很直白:没有软盘、硬盘、CD、USB、网络、声音驱动。也就是说,这套系统现在能启动、能在屏幕上打字、能跑几个自带的测试程序,却没有办法从外部存储读写真正的数据。构建产物是cpm386.elf内核镜像和floppy.img软盘镜像,推荐用GCC而不是Clang编译,因为Clang编译出的i386代码体积更大。
兼容性数字背后是什么
项目给出的BDOS覆盖率表看着很扎实:
| 目标系统 | BDOS覆盖率 | 意味着什么 |
|---|---|---|
| CP/M-68K 1.3 | 100% | 完全对等 |
| CP/M 2.2 | 100% | 完全对等 |
| CP/M-Plus | 71% | 大部分调用可用 |
| DOS-Plus | 62% | 六成扩展已实现 |
| MP/M 2.1 | 50% | 多用户/多任务调用缺失 |
缺的那部分,主要是单用户系统本来就用不上的多任务、消息队列、进程控制调用,逻辑上说得通。但这张表和"无任何存储驱动"放在一起看,反差就出来了。
保护模式不等于能跑DOS
看到"386保护模式"四个字,很容易联想到"这下能跑DOS软件了吧"。这是常识层面的一个误会,值得说清楚。
386保护模式本身只是CPU提供的一种运行方式——分段分页、特权级隔离,谁都能用。CP/M-386用这套机制实现的是CP/M自己的BDOS/BIOS调用体系,和DOS的中断调用完全不是一回事。就像FreeDOS也跑在386上,但FreeDOS暴露的是DOS的系统接口,CP/M-386暴露的是CP/M的系统接口,两者谁都读不懂对方的可执行文件。芯片一样,操作系统的"语言"不一样。
更反直觉的一点是:CP/M-386并不是从同属x86谱系、理论上离386更近的CP/M-86演化而来,而是选择从CP/M-68K——一个跑在摩托罗拉68000上的分支——移植到386保护模式。CP/M-86和386共享指令集背景,按常理更容易做兼容;CP/M-68K和x86在指令集、执行环境上几乎没有交集。项目文档里没有解释这个选择的原因,这是一个留白的问题。
工程很硬,能用性很软
CP/M-386对构建环境的要求写得极其精确:cpmtools必须2.23版本以上,官方点名旧版本"看起来能用但有已知bug";已经在CentOS Stream 9、Fedora 36、Debian 12、Ubuntu 18.04/22.04、Alpine 3.24、OpenSUSE Leap 15.4上验证过能编译,还专门提醒FreeBSD当前打包的cpmtools2里mkfs.cpm功能是坏的,得自己重新编译且不能链接libdsk。
这种程度的版本锁定和多发行版验证,在个人复古计算项目里并不常见,说明作者对"能不能编译出来"这件事非常较真。
- 风险.一个连磁盘驱动都没有的系统,目前只能算保护模式启动实验,还谈不上"能用的操作系统"。
联网检索没能找到任何关于这个项目的外部讨论、发布历史或社区反馈——不是没有,是暂时没查到。这意味着它的活跃度、有没有人在用、后续会不会有人接手继续写驱动,眼下都是未知数,不该被默认成"热门项目"或"死项目",只能如实标注为待观察。
老话讲"其兴也勃焉,其亡也忽焉",用在开源小项目上未免夸张,但复古操作系统这条赛道确实反复上演类似剧本:一腔热情把底层架构做得漂亮,驱动和生态却迟迟跟不上,最后停在"能启动"这一步。CP/M-386眼下正卡在这个节点上。
- 结论.真正决定这个项目走向的不是BDOS覆盖率,而是有没有人愿意接着写磁盘和网络驱动。
对复古计算爱好者和操作系统教学场景来说,CP/M-386已经是个值得拿来读代码、看保护模式实现的样本。但要等它变成能真正跑起来、能读写文件的系统,还得看GitLab CI的构建节奏,以及"Future plans"里那些驱动计划什么时候真正落地。