MS-DOS 4.00源代码公开过程中的Git转储失误会破坏构建并删除元数据

MS-DOS 4.00源代码公开过程中的Git转储失误会破坏构建并删除元数据 正如OS/2 博物馆的软件策展人 Michal Necasek 所指出的那样，正确的做法是将源代码转入Git 仓库，而不是提供原始存档。他提出了一个很好的观点："历史悠久的源代码应该以 ZIP、tar 或 7z 等文件归档的形式发布，并保留所有时间戳和每个字节的原样。Git 根本就不是一个合适的工具"。将源代码扔进 Git 后，微软可能以多种方式破坏了文件，例如，Git 忽略了原始时间戳，带走了关于每个文件最后修改时间的潜在有价值的元数据。更糟糕的是，UTF-8 编码的转换把一些代码变成了乱码，破坏了构建过程。正如 Necasek 所强调的，几十年前的源代码不仅仅是文本，它本质上是二进制数据，需要完全保存，不能做任何修改。重新编码会导致程序崩溃，因为像 MASM 5.10 和 Microsoft C 5.1 这样过时的工具自然无法处理像 UTF-8 这样的 Unicode 格式，而当时还不存在这种格式。虽然 MS-DOS 4.00 代码的可用性对于研究从 MS-DOS 到 Windows 发展历程的软件历史学家来说无疑是一个福音，但 GitHubbing 方法可能会不必要地破坏将代码作为真实档案材料进行构建和分析的努力。不过，一位用户名为"starfrost"的评论者声称，他们与微软合作发布了这一版本，并在原文中表示，他们有可能获得原始 ZIP 文件。不过可能无法获得时间戳，因为"数据保护法规定源文件必须匿名"。此外，Necasek 还表示，他可以通过将代码复制到 PC DOS 2000 虚拟机并在其中运行构建过程来成功构建整个代码。因此，如果你想构建代码，这是一个不错的选择。微软更明智的做法是直接从内部备份中以干净的 ZIP 或 7z 压缩包形式提供源代码，并进行适当编码，以原始形式保留每个字节。计算机的遗产对于业余爱好者来说实在是太珍贵了。值得称赞的是，微软还额外提供了来自 Ray Ozzie 档案的测试版二进制文件、原始文档和磁盘映像，以方便用户进行仿真。 ... PC版： 手机版：