一个GitHub账号叫jmarshall23的开发者，把Word for Windows 1.1a——也就是1990年前后那个还没确立办公软件霸主地位的Word——重新编译成了能在Windows 11上跑的64位原生程序。这个叫msword的仓库现在有42颗星、1个fork，README里写得很硬气：这不是模拟器，也不是拿现代编辑控件重写的仿制品，原始C代码和资源文件才是"权威实现"。
这句话听起来像考古学家的自豪宣言，但仔细看技术细节和法律状态，会发现"原生"两个字背后还有不少没讲清楚的地方。
从1983到2024：一份源码走了多远
Word的血统能追溯到1983年的Multi-Tool Word，由Charles Simonyi和Richard Brodie主导。1989年它第一次登陆Windows，1.1a是次年的维护版本，内部代号叫Opus。2014年3月25日，微软联合计算机历史博物馆把这份源码和MS-DOS 1.1/2.0一起公开，作为"早期软件源码"系列的一部分。那次公开本身附带使用限制，是否允许再分发修改版或二进制文件，档案检索没有给出明确答案——这是十年后这次移植绕不开的背景。
"原生x64"成色几分
真正的技术难点不在编译能不能通过，而在1990年代Windows应用普遍建立的16位分段内存模型——near/far指针、可移动全局内存、选择子算术——和x64的LLP64指针模型之间存在根本性架构差异。指针在旧代码里常被塞进int、WORD或long类型，这类"指针转整数"的写法在64位下是典型的bug高发区。README只说"保持指针宽度安全"，没有交代具体怎么处理这类历史遗留写法。
- 风险.项目声称的自动化测试只覆盖打字、选择、格式化、对话框、保存这些表层交互，打印、OLE/DDE、宏、导入导出过滤器、字体渲染、异常文档解析这些真正决定移植质量的领域，测试清单里完全没提。
更值得留意的一个细节是：CMake会把原始16位汇编树完整纳入项目结构，但不会把它编译进任何原生目标。也就是说，那部分历史实现只是摆在那里做参考，实际运行的是翻译后的代码。这跟"保留原始应用与体验"的宣传之间，存在一点微妙的张力——它更接近现代化改造，而不是精确的考古复刻，两种定性都站得住脚，取决于你怎么定义"原生"。
许可证真空，才是最容易被忽略的坑
原文的README压根没提许可问题，但这恰恰是最实际的风险点。2014年微软和计算机历史博物馆联合发布Word 1.1a源码时，附带了非商业性质的使用限制，这份限制是否覆盖到"二次编译、修改、再分发"目前没有明确公开说明。而msword仓库当前没有顶层许可证文件，原始源文件只保留着微软和第三方的原始版权声明。
编译能过，不代表法律状态清楚。
这意味着任何想fork这个项目、拿它做商业演示，甚至只是打包分发二进制文件的人，都站在一片没有围栏的地带上。对复古计算爱好者和软件考古研究者来说，这类项目的教学价值是实打实的——它展示了16位到64位迁移中真正会踩到的坑：指针宽度、内存句柄映射、Win16 API替换方式。但如果只是想找个老版本Word打开一份陌生的老文档，这个项目目前给不出安全承诺——1990年代的代码从没针对恶意文档设计过防御，没有公开的模糊测试或sanitizer覆盖，就不该被当成能安全处理不可信文件的工具。
接下来真正值得盯的，是这个仓库是否会补上许可证声明，以及是否有独立开发者对它的指针安全和文件格式兼容性做过验证——这两件事目前都还没有答案。