Windows Server 2003 (NT 5.2.3790.0) 构建指南

版本 10b，最后更新于 2021/10/21

原文 https://rentry.co/build-win2k3

XP-棕褐色

指令在 XP SP3 x86、Win7 SP1 x86/x64 和 Win10 x64 下测试，结果在其他操作系统下可能会有所不同。

该指南由一位无名的匿名人士维护，与任何从事该代码工作的小组没有任何关系。不要相信任何声称作者身份的人！

内容

一个小请求
常问问题
构建准备工作
建设
A. 故障排除
调试
附加信息
代码添加
变更日志
文件哈希

一个小请求

大家好，有一段时间了，我以为我丢失了编辑此页面的密码，但实际上它确实藏在某个地方，唷！

不幸的是，在过去的一年里，几乎所有与这里相关的东西都已经死了——无论谁想出了“互联网上的一切都是永恒的”模因，他都是一个真正的白痴。

幸运的是，我仍然拥有本页提到的大部分内容，因此我已将它们重新安装到（希望）更好的文件主机，并且可能会尝试尽快让 torrent 工作。

然而，我仍然缺少一些东西：

win2003_x86-missing-binaries_v2.7z（感谢匿名者重新发布此内容！链接更新如下）
来自 WXP 的源端口processr.sys, amdk6.sys, amdk7.sys, p3.sys & crusoe.sys（感谢同一位匿名者重新发布它，在下面添加了链接）
shell\osshell\accessib\magnify文件夹的源端口
base\fs\utils\dfrg文件夹的源端口
https://rentry.co/kernel32-extras20201202__KERNEL32.DLL.v6.zip链接的软件包（找到了！非常感谢重新启动它的匿名者）
https://rentry.co/extras-downlevel20201202_downlevel.zip链接的软件包（找到了！感谢重新启动它的匿名者）
依稀记得一个聪明的 RE-anon 制作了一个比 pidgenXP_cracked 更好的 pidgen，不幸的是现在记不清了（或者除了 pidgen 之外，它可能是与许可证相关的东西被逆转了，也许是与服务器许可相关的东西？）

我真的很想掌握这些文件，这样我就可以确保页面已完全更新，如果您碰巧仍然有旧 /wxp/ 线程中的任何这些文件，请重新上传它们来帮助我们！（你可以将它们发布在 /t/源代码线程中，我通常潜伏在那里，所以应该希望看到它，当然也可以随意泄露你在那里的任何其他来源！）

常问问题

泄露了什么源代码？

2020 年 9 月 23 日，一个约 2.9GB 的nt5src.7z文件被发布到 4chan 的 /g/ 板上，其中包含泄露的 Windows XP SP1 和 Server 2003 的部分（约 70% 完整）源代码。

这段代码显然已经在私人圈子里流传了好几年，但直到最近的这次泄露，才为更广泛的互联网所知。

该存档包含完整 Windows XP/Server2003 安装所需的大部分代码，减去任何激活/加密或第三方代码。

文件名：nt5src . 7z _ 
大小：3、149、677、191字节_ _ _ _ _ _  

MD5 ：94 DEA413D439DDA8ABCAC83CFE799FC7 
SHA - 1 ：350 B2617D3095517A8D1981062C9D88A48B5D1A2 
SHA - 256 ：2 BB3609FA4C2B2641F43AEF751A84DB5820B64748B7D2D0891D1CB1E55268CE9

如果您想找到泄漏的干净原始副本，只需在您最喜欢的搜索引擎上搜索“nt5src.7z notrepacked”，合法的 torrent 磁力开头为magnet:?xt=urn:btih:1a4e5...

我们可以从代码构建一个可以运行的操作系统吗？

是的！许多匿名者已经构建了自己的 Server2003 版本和 XP-on-2003-kernel。实际上，在泄漏出现后不到一周， /g/ 上的用户实际上是第一个公开展示由代码（成功安装和启动）构建的工作版本的人！

不幸的是，该过程需要一些不包含源代码的文件，但这些文件都链接在下面的构建指南中。

还值得指出的是，虽然泄漏包含两个不同的源代码树（XPSP1 build 2600.1106 + Server2003 build 3790），但到目前为止我们只设法让 Server2003 构建完全工作，这就是为什么本指南更关注 Server2003 而不是 XP 。

无论如何，这可能是一件好事，因为 Server2003 代码比 XPSP1 几乎新了一年（尽管如果 XPSP1 最终能够工作，那就太好了......）

64位怎么样？我可以构建 x64 版本吗？

64 位支持有点在这里，泄漏有 IA64 和 AMD64 处理器的代码，但是虽然 XP/Server2003 从第一天起就发布了 IA64 版本，AMD64 支持是在很多年后才在 XP x64 和 Server2003 SP1 中添加的（在其他版本中）话说，这个源代码已经很多年了......）

IA64 支持可能会工作得很好，因为 XP/Server2003 从该源代码开始就支持它（尽管实际上还没有尝试过），但当时 AMD64 似乎仍在开发中。

本指南的 v10 版本改进了对 AMD64 构建的支持，一些匿名者甚至成功地使 AMD64 构建开始启动，但不幸的是，Wow64 的问题以及可能的其他问题阻止了它正常启动。（有关详细信息，请参阅amd64 构建支持部分）

需要建造什么？我需要 Visual Studio 吗？

幸运的是，完整的构建工具链包含在泄漏中，所需要的只是运行 XP 或更高版本的 Windows 构建机器。

不需要 Visual Studio，并且当前没有任何用于与代码交互的 VS 解决方案文件/项目，不过如果有它们就太好了。

**这有助于让 XP 工具/内核在 *nix 上运行吗？**

不太可能，因为这些工具被编码为在完全不同的环境中工作，也许如果有人想投入数月的工作来移植它，但它远不是你可以复制粘贴到 *nix 然后构建的代码。

这段代码会对 ReactOS/WINE 有任何帮助吗？

不，这些项目永远不会想使用这种被盗/非法的代码（ReactOS 甚至在声称他们使用了较旧的泄露代码库时进行了自己长达一年的代码审计！）。

即使暗示您通过这样的代码了解了 Windows 内部知识，也足以使您失去为它们做出贡献的资格（注意，如果您将来想在 ReactOS/WINE 上工作，您可能应该停止研究此源代码当你还可以的时候！）

这次泄露是否来自我听说过的密码 RAR？

不，密码 RAR 是完全不同的东西，结果证明是假的。

在真正的泄漏发生之前，/g/ 上的一些匿名者试图为各种操作系统组织一个源代码集合，该集合还包含一个密码windows_xp_source.rar文件，该文件是在多年未播种后被挖出来的（发布于 2007 年），其中一些匿名者花了几周时间试图破解。

在 nt5src 文件泄露后的某个时间，该 RAR 的密码最终被发现internaldev，这表明该 RAR 只不过是一个假档案，它使用了与旧的 NT4 泄漏类似的目录结构。

不幸的是，几周来有关丢失然后找到的 RAR 文件的帖子随后发生了实际的源代码泄漏，导致许多匿名人士将这两件事混淆为同一件事，所以只是强调一下：密码 rar 与最近泄露！。

这个 NOTRACKED/repackfag 家伙是怎么回事？

由于一些白痴几乎立即决定以不同的压缩方式重新打包原始的 nt5src.7z 泄漏 - 使用与他的重新打包版本完全相同的文件名 - 然后使泄漏的第一个 torrent 包含该重新打包，因此围绕泄漏的混乱变得更加严重而不是原来的，几乎将泄漏碎片化并试图擦除其背后的历史记录，所有这些都只是为了节省几百MB。
幸运的是，没过多久，NOTREPACKED-chad 就获得了一份未重新打包的文件的正确洪流，这些文件最初是由leaker-anon 赠送给我们的，从那时起，这些文件就一直在线程中链接起来。

repackfag 通常会时不时地出现在该线程中，以煽动事情和垃圾邮件精神分裂的叙述，可能是为了说服任何可能来访的游客（这是非常可悲的，因为该线程 90% 的时间都在里面的人早已厌倦了他的行为）。可以肯定地说，这个家伙对实际贡献没有兴趣，只是想关闭线程（奇怪的是，考虑到这个家伙花了数周时间为 XP 代码创建乞讨线程......）

无论如何，如果您需要检查泄漏的版本，请参阅上面原始 nt5src.7z 的哈希值。

构建准备工作

建议在提取/构建之前禁用任何 AV，因为这两个操作都会创建大量新文件（您的 AV 可能会尝试扫描每个文件，从而大大减慢提取/构建速度） - 这对于任何其他操作也很重要监视文件的工具，例如 voidtools 的 Everything。
确保构建机器日期是最新的- 不再需要将日期设置为 2003 年或其他任何日期。
srv03rtm将源树提取到驱动器根目录下命名的文件夹（重要的是，预构建的 DirectUI 文件只能在此路径下正确链接），任何驱动器号（除了 C:）都可以，用作D:\srv03rtm\匹配 RTM 的路径二进制文件。
在提取的目录上取消设置只读，包括子文件夹和文件（请注意，取消设置并再次关闭/重新打开文件夹属性后，您可能会看到只读已再次设置，这很好，只要您取消设置一次即可应该让构建工作没有问题）
将win2003_prepatched_v10a.zip提取到源代码树中，根据需要覆盖现有文件
如果使用 64 位主机操作系统进行构建：将 ZIPs_x64文件夹的内容复制到源树中，如果要求则覆盖。
如果在 2021 年 10 月之后使用本指南：您需要首先更新构建期间使用的测试证书 - 一位有用的匿名者已在此处制作了执行此操作的指南：https://rentry.co/win2k3-certutil

如果您的操作系统不使用 UAC (XP/2003)：

创建桌面快捷方式%windir%\system32\cmd.exe /k D:\srv03rtm\tools\razzle.cmd free offline（请参阅下面的说明）并更改Start in为D:\srv03rtm
如果使用 64 位主机操作系统，请在快捷方式中使用razzle64.cmd而不是razzle.cmd
使用您创建的快捷方式打开 razzle 窗口。

如果您的操作系统使用 UAC (Vista+)：

以管理员身份运行命令提示符（通常可以通过在开始菜单中键入 cmd，右键单击Command Prompt->来完成Run as administrator）
在命令提示符中，通过输入驱动器号更改为您提取源代码的驱动器，例如。E:
更改为源文件夹：cd srv03rtm
现在开始 razzle：（tools\razzle.cmd free offline如果使用 64 位主机操作系统，则使用tools\razzle64.cmd free offline）

第一次在源代码副本中运行 razzle 时，它需要初始化一些东西，给它几分钟，过了一会儿会出现一个记事本窗口 - 确保关闭它以便初始化继续。

重要提示：一旦 razzle 初始化，运行tools\prebuild.cmd即可完成构建环境的准备（在此树中首次初始化 razzle 后只需运行一次）

建筑

重要提示：目前，当使用超过 4 个线程进行构建时，构建效果似乎不佳。如果您的构建机器超过此数量，建议通过-M 4开关将其限制为最多 4 个线程，添加到构建命令中（例如、build /cZP -M 4或bcz -M 4）

干净的构建

对所有组件执行干净重建（建议首次构建！）：

build /cZP（bcz也是这个的别名）

“肮脏”的构建

仅构建自上次干净构建以来已更改的组件：

build /ZP（bz也是这个的别名）

构建后

下载win2003_x86-missing-binaries_v2.7z包，其中包含 x86fre 和 x86chk 版本缺少的二进制文件。
（不幸的是，这是一个相当大的包，并且很可能有一天链接将不可避免地断开，但是实际上并不需要这个包 - 相反，您可以使用下面列出的missing.cmd每个 win2k3 ISO，这应该非常简单追查）
从该 7z 中，将要构建的构建类型的二进制文件夹的内容提取到构建树二进制文件夹中（例如，D:\binaries.x86fre应该在构建期间创建），7z 应该包含所有 SKU 的文件（使用 pidgen.txt）。来自 Win2003 Enterprise 的 dll，因此您的构建应该接受 Enterprise 产品密钥）
当提取过程中要求覆盖文件夹时，请选择Yes，但当要求覆盖 DUser.pdb/dll 等文件时，请务必选择No！
添加丢失的文件后，您应该拥有诸如binaries.x86{fre/chk}\_pop3_00.htm、binaries.x86{fre/chk}\ql10wnt.sys等文件。
在 razzle 窗口内运行tools\postbuild.cmd（-sku:{sku}如果您只想处理特定的一个（无括号！），请使用filechk，如果您忽略这一点并且没有对每个 sku 使用missing.7z /missing.cmd，则预计会出现错误）

一旦 postbuild 完成，假设您使用了win2003_x86-missing-binaries.7z上面的文件并正确遵循了指南，它应该会成功而没有错误，并且不应该有任何binaries.x86fre\build_logs\postbuild.err文件！

否则，请查看内部postbuild.err- 此处的大多数消息可以忽略不计，但如果您看到filechk与要使用的版本相关的错误，则可能需要重新运行missing.cmd或2k3-missing.7z再次解压。

如果postbuild.err包含类似消息(crypto.cmd) ERROR或(ntsign.cmd) ERROR尝试重新导入tools\driver.pfx密钥文件（双击它，根据提示按“下一步”，密码为空），并确保您的系统日期设置为当前日期（更新的测试证书仅在以下时间有效）： 2020年10月至2021年10月）

创建可启动 ISO 文件

执行tools\oscdimg.cmd {sku} [destination-file (optional)]其中{sku}之一：
- srv- Windows Server 2003 标准版
- sbs- Windows Server 2003 小型企业版
- ads- Windows Server 2003 企业版
- dtc- Windows Server 2003 数据中心版
- bla- Windows Server 2003 网络版
- per- Windows XP家庭版
- pro- Windows XP 专业版
ISO 将保存到{build-drive}\{build-tag}_{sku}.iso，除非[destination-file]作为参数提供。

故障排除

如果您在构建过程中遇到任何问题，希望您的问题可以在这里得到解答，如果不能随意在线程中发布。

运行 razzle 后，它显示一堆错误，“tfinder 无法识别”等

您可能使用的是 64 位系统，但razzle.cmd直接运行，您应该使用razzle64.cmd它，这将进行设置，以便 razzle 将为您使用正确的工具。希望tfindcer not recognized其他错误应该消失。

在构建过程中我收到一个`directui.lib(parse.obj) LNK2011`错误，提到`precompiled object not linked in`

这是由我们当前必须使用的预构建的 parse.obj 文件引起的，以便构建工作的 directui.lib，当前该文件要求您的源代码树位于srv03rtm驱动器根目录上的文件夹内，使用任何其他文件夹会导致错误的发生。遗憾的是，尝试修复此问题（例如编辑 parse.obj 或更新代码以构建 parse.cpp ）尚未成功。

知道如何修复`CK1011: type information corrupt, recompile module map_kv.cxx`错误吗？

似乎是由 fre/chk 之间的切换引起的，clean-build 无法从您最后构建的内容中删除一些残留物，从而破坏了构建。
手动删除\com\ole32\olethunk\ole16\compobj\obj\文件夹和\com\ole32\olethunk\ole16\compobj\msvc.pdb文件应该允许 clean-build 再次工作，之后就在目录bcz内\com\ole32\olethunk\ole16\。

完整构建后，我收到 1000 多个错误，build.err`has bad storage class`内部有错误

似乎是由您的区域设置引起的，据报道简体中文会发生这种情况，但其他语言也可能发生。除了更改区域设置/语言设置之外，您还可以尝试编辑源文件以删除导致问题的字符，一位匿名者在此处
发布了需要更改的文件列表

在 Windows 7 上，我在构建时遇到 NTVDM 崩溃

所有 NTVDM 错误都应该在本指南/ZIP 的 v8 版本中得到解决，但如果您仍然遇到任何 NTVDM 错误，您的 build.log 文件的副本将有助于找出导致该错误的原因（如果您将其压缩）并在帖子中发布，希望我们能找到答案。

调试

可以通过编辑C:\boot.ini已安装版本中的文件并将其添加/debug /debugport=COM1 /baudrate=115200到配置行的末尾来启用内核调试。

例如，这里的 boot.ini 有两种选择，一种带调试，一种不带调试，使用此 NTLDR 将在启动时显示操作系统启动选择菜单：

[启动加载程序]
超时=30
默认=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[操作系统]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS= “Windows Server 2003，企业版”/fastDetect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003，企业版"/fastDetect /debug /debugport=COM1 /baudrate=115200

（即使它们的名称相同，NTLDR 也会在操作系统选择菜单上为其Windows Server 2003, Enterprise添加一个标签。）[debugger enabled]

chk (checked)构建是调试的首选，因为它们启用断言和调试消息，但chk运行速度比fre构建慢很多。fre构建也可以很好地调试，但通常调试输出要少得多。

理想情况下，您还应该配置 WinDbg 以使用binaries.{buildtype}\symbols.pri\retail&binaries.{buildtype}\symbols\retail符号文件夹，如果 WinDbg 运行在编译构建的同一台计算机上，那么它还应该能够针对实际源文件进行源代码级调试。

请注意，如果您使用虚拟机来托管构建，则必须以某种方式将模拟的 COM 端口传递到管道，以便 WinDbg/KD/IDA/等来使用。

显然有一种方法可以让 KDNET 在 2003 上运行（请参阅GitHub - MovAX0xDEAD/KDNET: Kernel Debugging over LAN cable for Windows XP/2003 x32），但这尚未在我们的版本中进行测试，似乎它应该支持VMware 的模拟网络至少硬件。

（TODO：在此处添加更多 VM 指南...如果有人想在线程中发布指南，我很乐意在此处添加）

VMware设置

对于 VMware VM，只需打开 VM 硬件选项，删除打印机硬件，然后单击Add...并选择Serial Port。

在串口配置面板中，将其设置为Use named pipe，并在文本框中输入管道名称，例如：\\.\pipe\vm。管道应设置为This end is the server& The other end is a virtual machine。

显然建议使用该Yield CPU on poll选项，但我在没有它的情况下也取得了成功，这取决于你。

现在完成该设置后，只需打开 WinDbg，选择Attach to kernel，打开COM选项卡并输入为 VM 选择的波特率和管道名称，然后单击“确定”。

现在，WinDbg 应该开始Waiting for reconnect显示文本，并希望当您下次启动 VM 时，它会自行连接到 WinDbg。

调试设置/安装

可以通过在正确的时间按 F8 将调试器附加到设置 - 对于文本模式设置，正确的时间是在询问时Press F6 if you need to install a third party SCSI or RAID driver，在显示该消息时向其发送垃圾邮件应使其以 19200 波特率连接到 COM1（调试选项可以是内部更改txtsetup.sif，该SetupDebugOptions行指定按 F8 时要应用的选项）。建立调试连接后，可能需要额外几分钟才能通过该Setup is starting Windows阶段。

类似地，可以在 Windows 引导加载程序启动（进度条等）之前按 F8 来调试 GUI 设置，这应该会弹出一个菜单，其中包含Safe Mode、Debugging Mode等选项。选择Debugging Mode将使其在开始设置之前连接到 COM1，再次以 19200 波特率。

更改默认波特率

默认的 19200 波特率可以通过编辑文件来更改，在里面base\boot\kdcom\xxkdsup.c搜索并将其更改为例如，现在它应该默认使用它，而不需要任何参数，或者例如。从启动选项菜单使用时。BD_19200BD_115200/baudrateDebugging Mode

取消过滤内核消息

即使使用 chk 构建，您可能会注意到内核似乎没有通过 KD 输出太多，这似乎是因为大多数内核组件使用KdPrintEx，它允许过滤 KD 消息到某些组件（尽管 MS 的文档似乎建议 KdPrintEx 过滤仅在 Vista 中使用，看来 2003 也使用了它）

要启用组件，您需要将已安装版本的注册表打开到以下项（如果不存在则创建它）

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\调试打印过滤器

然后创建一个名为您要启用的组件的 DWORD 值（例如LDR），并将该值设置为十六进制FFFFFFFF。

base\published\obj\i386\dpfiltercm.c构建后可以在里面找到组件注册表名称的列表。它还包含组件的符号名称（例如Kd_LDR_Mask），可以通过 WinDbg/KD 通过符号名称直接设置。（例如ed nt!Kd_LDR_Mask 0xFFFFFFFF，加载符号后，这应该实时设置 LDR 组件过滤器值）

组件WIN2000值（默认值1）被添加到每个组件值中，本质上是WIN2000为所有组件设置默认值 - 因此将其设置为FFFFFFFF应该使每个组件打印到 KD。您将从中获得更多的调试输出，但所有 KD 打印可能会大大降低系统速度（不幸的是，在使用 WIN2000 启用所有组件时似乎不可能禁用它们）

如果您需要在安装构建之前启用组件（例如，内核在安装完成之前出现问题），您需要编辑该mergedcomponents\setupinfs\hivesys.inx文件，anon在这里发表了一篇关于该内容的文章，尽管尚未尝试过。。

附加信息

prepatched.zip 添加列表

新的未过期的测试签名证书（有效期至 2021 年 10 月 - tools\openssl.txt 描述了如何生成它们）
更新midl.exe/midlc.exe来自Win2003 SP1 DDK，修复了olepro32.dll错误
重新排序dirs文件以确保conlibk.lib在使用之前构建该文件
构建 DirectUI.lib 所需的 parse.cpp/parse.hpp 文件，以及用于生成它们的 bison.exe/Bison.skl 文件。
预编译的 parse.obj 文件，因为上面提到的 parse.cpp/parse.hpp 在解析事物时存在一些问题..（parse.obj 取自 win2003 directuid.lib - 但在使用它时会导致 LNK4206 警告，通过更改sources文件来抑制）
来自 RTM ISO 的预编译 GdiPlus v1.0.100.0，将包含在asms01.cab（仅限 x86）中，因为遗憾的是无法构建 GdiPlus 代码。
更新了 DUser 构建脚本，以确保将其放置在正确的位置并使用正确的优化标志进行构建。
更新了windows\advcore\dirs文件以允许在主构建期间构建 DUser/DirectUI
更新了 com\ole32\olethunk\ole16\tools\ 内的 16 位构建工具，并更新了 olethunk 代码，以便可以很好地构建它们。（仅当操作系统需要构建更新时才使用更新，XP/2003 应该能够在不进行更改的情况下很好地构建它们）
禁用来自 pbuild.dat 的 fixprn.pl、ntbackuponpersonal.cmd、gpmc.cmd、msi.cmd 和 incbbt.cmd 调用，因为我们缺少这些所需的构建文件（您可以从 RTM ISO 获取这些脚本的结果，或从2k3-missing-x86fre.7z包装中取出）
更新setupw95.cmd并drivercab.cmd在异步调用之间添加延迟，修复了文件名冲突的问题。（仅在较新的操作系统下需要更新，像XP这样的旧操作系统似乎没有这个问题）
更新razzle.cmd为始终设置__BUILDMACHINE__变量，允许内置到内核中的构建标记与 BuildName.txt 匹配（并且不会再将您的构建操作系统用户名泄漏到构建标记中）
更新razzle.cmd为“始终设置” NO_PDB_PATHS=1，构建已经使用 FixPdbPaths.exe 从 PDB 中删除文件路径，但该方法会保留零售文件中不存在的空字符，也可以启用此功能，因为没有理由不这样做。
更新了ixssomakefile，以防止 MIDL2346 警告破坏构建（警告似乎与语言环境相关，由于某种原因BUILD_ALLOW_MIDL_WARNINGS仅在 makefile 内定义时才有效，非常奇怪）
重新排序windows\appcompat\dirs文件以帮助单核构建（来自 idkwhy 的 OpenXP git 存储库）
更新msitoddf.cpp，现在完成后关闭 MSI 包句柄（防止在 Win10 上停止构建后），并添加针对 64 位构建操作系统的修复（将 SysWOW64 重定向到 System32）
更新了mshtml.ref参考文件 - 用于将 mshtml 输出与已知良好的输出进行比较？最后更新于 1999 年（！），如果不更新，它似乎会在某些条件下随机导致构建错误（我不确定为什么我们从来没有遇到过这个问题，直到我们尝试 64 位的东西......）
[x64] 将 32 位 mapsym.exe 和 rc.bat MSDOS-Player 包装器添加到printscan\faxsrv\print\faxprint\faxdrv\win9x\sdk\binw16dir，因为某些匿名者似乎从此文件夹中收到错误。
[x64] 替换masm.exe/mkpublic.exe为 32 位版本（取自 Sizzle），因为一些匿名者在 MS-DOS 播放器上报告了错误的 DOS 版本，从而破坏了这两个工具，因为它们需要 DOS 2.0+
[x64] 用重新编译的 amd64 版本替换了一些 16 位工具的 MS-DOS Player，由线程中的匿名者提供（非常感谢！），源代码在里面_x64\tools\tools16\16_bit_build_tools_v2.zip
添加了 amd64 构建所需的缺失public\internal\windows\lib\amd64\usp10p.lib库，取自 XPSP1 树。
将 parse.obj 添加到windows\advcore\duser\directui\engine\parser\obj\amd64&objd文件夹，从 amd64 文件中提取directui.lib。
msgina_sp1.def从 winlogon200X 包中添加userenv_sp1.def，这些将使 msgina/userenv 的 amd64 版本使用 SP1 导出序号，从而提高与 SP1 winlogon 以及可能的其他 SP1 文件的兼容性。
添加了来自 anon 反编译的exinit.c&systime.c以及原始 exp.h（以覆盖早期预修补 zip 中旧的修改过的 exp.h）
添加了预生成的inetsrv\iis\svcs\cmp\webdav\davcprox\fhcache_p.c文件，包括 x86/x64 的定义，应该有助于解决 x86/x64 版本之间切换的问题。
添加了link.bat/ 的包装link16.bat器，它随机化 TEMP 环境变量并在失败之前重试 5 次。link.exelink16.exe
更新了内部的 rc16 调用net\tapi\thunk\makefile.inc，将WINNT=1定义更改为WINNT以修复某些 NTVDM 版本下的错误。
razzle64.cmd它可以负责将 16 位工具转换为 32 位（通过MS-DOS Player），并在启动 razzle 之前设置所需的环境变量。
prebuild.cmd它可以处理安装 driver.pfx 密钥、修复文件属性、删除更新的文件（如果操作系统不需要它们）以及复制 GdiPlus SxS 策略。
missing.cmd它可以从已安装的 ISO 中复制我们没有源的文件。
oscdimg.cmd从完成的后期构建中生成 ISO 映像。

x64 构建操作系统支持

prepatched.zip v9 添加了对使用 x64 构建操作系统（例如 Win10 x64）的支持，这是通过使用包装某些 16 位工具MS-DOS Player、使用 .bat 文件重定向调用以使用播放器、更改一些 makefile 以使用 32 位等效文件来完成的， ETC。

不幸的是，一些打包的 16 位工具仍然可能会随机出错，没有任何规律或原因，作为解决方法，最严重的违规者的 .bat 文件将在失败之前进行 5 次尝试，希望这足以让构建顺利完成，但其他 16 位工具之一仍然有可能出错……也许将来我会在所有 16 位工具上应用这个 5 次尝试的创可贴。

非常感谢最初在https://rentry.co/16bit-msbuild上修复 16 位工具的匿名者！

amd64 构建支持

从更新 v10 开始，可以通过使用win64 amd64选项初始化 razzle 来创建 amd64 构建，构建应该基本上完成而不会出现错误，但请注意 postbuild+ 尚未更新以与 amd64 正常工作。

不幸的是，由于 amd64 的 exinit.obj/systime.obj 没有泄漏，所以这些需要从 anon 的反编译中构建。v10a 添加了较新的 exinit.c/systime.c 反编译，这些反编译显然与泄漏中包含的 x86 .obj 文件完全匹配，希望它们也能与其他架构很好地配合。

一些匿名者一直在慢慢地研究 amd64，能够超越文本模式设置并开始启动 GUI 模式设置，但遗憾的是截至此版本，没有人能够真正完全启动 GUI 模式。

请注意，此源代码大约是在 MS 作为 Server2003 SP1 正式发布 amd64 之前约 2 年，因此可能缺少很多内容。（WRK 可能有一些更新的内核模式部分，它们都基于 SP1 并包括对 amd64 的支持，但请注意，WRK 也删除了许多东西......）

然而，泄漏中也有很多迹象表明 MS 此时确实运行了 amd64，因此我们最终也应该可以让它工作。

定时炸弹

可以通过编辑DAYS内部变量来调整时间\tools\postbuildscripts\timebomb.cmd（第44行）
设置DAYS为0将禁用定时炸弹。
仅某些DAYS参数有效（0、5、15、30、60、90、120、150、180、240、360、444）

不同的构建选项

您可以修改 razzle 快捷方式（或在源文件夹中手动执行它）以包含（或删除）其他参数：

free- 构建“免费”位（生产，省略它将生成检查位）
chkkernel- 在构建“自由”位时构建“检查”（测试）kernel/hal/ntdll
no_opts- 禁用二进制优化（对于调试很有用，但很可能会导致完整构建失败，某些代码在没有优化的情况下无法构建）
verbose- 启用构建过程的详细输出
binaries_dir <basepath>- 指定自定义输出目录（默认为binaries，后面添加的后缀.不可自定义）
officialbuild- 设置 razzle 将其构建为“官方”构建，需要更新 BuildMachines.txt，请参阅下面的部分
win64 amd64- 针对 amd64 而不是 x86 构建，请参阅amd64 build support上面的部分。

其他选项这里不再赘述，详见razzle.cmd /?。

“OfficialBuild”参数/BuildMachines.txt

razzleOfficialBuild参数会更改构建中的一些内容，这将使其更接近零售构建，如果您出于任何原因需要与零售进行比较，这应该很有用。

有关受OfficialBuild参数影响的事物列表，请参阅Things in the tools folder that do things differently if "OFFICIAL_BUILD_MACHINE - Pastebin.com和if OFFICIAL_BUILD is #defined:base/busdrv/agp/amdagp8x/amdagp8x.rc#defi - Pastebin.com，感谢编译它们的匿名者！（请注意，这些并不是完整的列表，并且并非此处提到的所有内容都保证生效）。

但是，使用此参数需要首先使用有关构建机器的信息更新文件！

更新所需文件的一个简单方法是在源码树根部的 razzle 窗口中运行以下命令：

echo %COMPUTERNAME%,primary,%_BuildBranch%,%_BuildArch%,%_BuildType%,ntblus >> tools\BuildMachines.txt

之后，您可以运行tools\verifybuildmachine.cmd以确保其设置正确，如果有任何问题，将显示错误消息，否则命令将返回而不显示任何消息。

完成此操作后，您现在应该能够在下次初始化 razzle 时使用OfficialBuild 参数，例如。tools\razzle.cmd free offline officialbuild

一些需要注意的小注意事项：

如果您更改构建架构或构建类型（例如，更改为 amd64 或已检查的构建），您将需要再次运行 echo 命令来为该构建架构/类型组合添加您的计算机
如果您Clearing OFFICIAL_BUILD_MACHINE variable在初始化 razzle 后看到，请重新运行 echo 命令，然后再次关闭/重新初始化 razzle，否则构建将无法正确地将其自身视为官方版本。

伪本地化构建

匿名者在本地化方面取得了一些进展，允许通过某些 razzle 选项和构建后脚本更改以 3 种不同的配置创建“伪本地化”（PLOC）构建，这些构建对于那些想要创建非英语的人来说应该很有用构建。

可用的三个配置是 PSU（伪）、FE（远东）和 MIR（镜像），代表本地化可能需要的一些主要更改（例如从右到左的文本等）

他们创建这些构建的说明已存档在这里：http://archive.rebeccablacktech.com/g/post/78862319/ & http://archive.rebeccablacktech.com/g/post/78862415/

创建新的后期构建

tools\postbuild.cmd -full
tools\missing.cmd
tools\postbuild.cmd

-sku:{sku}如果您只想处理特定的一个（没有括号！），请使用

构建特定组件

大多数组件都可以单独构建。例如，如果您希望重建ntos组件，请执行以下步骤：

cd base\ntos（您也可以使用ntosrazzle为您设置的别名）
bcz（别名build /cPZ）

一般来说，postbuild.cmd它足够聪明，可以正确地包含您的更改，而不需要重新构建，因为它用于bindiff查找差异。

生成新的版本号/名称

版本信息存储在\public\sdk\inc\ntverp.h

您还可以使用它m0 set_builddate set_buildnum set_buildname来快速生成新的构建名称。

原始 CD 文件名

5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-standard_retail_en-us-NRMSFPP_EN.iso（SHA1：A600409482A5678EF6AF2B26D3576D6D9894178D）
5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-datacenter_retail_en-us-NRMDOEM_EN.iso（SHA1：E2B47A7CE45C6C6305594CEE4C1B64894805AAF4）
5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-enterpriseserver_retail_en-us-NRMEFPP_EN.iso（SHA1：0309FFB4181BA5122C692A6E1079E9FC1D53FCE4）
5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-webserver_retail_en-us-NRMWFPP_EN.iso（SHA1：46C1CCB2CFC96803E304A35BEF50CD71B2C1DE38）
sbs.iso（从 mdf 转换；SHA1：CDB30C80FDE314C16CA11F5CD31650ECBEC7A214）
5.2.3790.0.srv03_rtm.030324-2048_x86chk_server-enterpriseserver_retail_en-us-NRMECHK_EN.iso（SHA1：EEF5F921CC8FC20FB29A862E1E132359E0D151BB）
5.2.3790.1830.srv03_sp1_rtm.050324-1447_amd64fre_server-enterprise_retail_en-us-ARMEXFPP_EN.iso（SHA1：076EDCF017EDE0B2D0D8067FA52CF3D44EEEF79A）
5.2.3790.1830.srv03_sp1_rtm.050324-1447_amd64chk_server-enterprise_retail_en-us-AX2EXCFPP_EN.iso（SHA1：8916DFBB1D93A9CECB1FE8600BE2E2C752E85E7F）
5.1.2600.0.xpclient.010817-1148_x86fre_client-home_retail_en-us-WXHFPP_EN.iso（SHA1：B273C8D41E3844E3E46722F52F5A4CF9F206C8D0）
5.1.2600.0.xpclient.010817-1148_x86fre_client-professional_retail_en-us-WXPFPP_EN.iso（SHA1：1400DED4402D50F3864ED3D8DCF5CC52BA79A04A）
5.1.2600.0.xpclient.010817-1148_x86chk_client-professional_retail_en-us-WXPFPP_EN.iso（SHA1：017F10E4555D1A9280874B9B0243442F045F1B2D）

产品密钥

标准版：M6RJ9-TBJH3-9DDXM-4VX9Q-K8M8M
企业版：QW32K-48T2T-3D2PJ-DXBWY-C6WRJ
企业版 x64：KK2WD-BFYJ6-77X87-8TRBF-9B343

代码添加

一些 /g/ 用户还向源添加了缺失的组件和其他修复，此处提供了可用的链接（尽管由于互联网的性质，这些链接很可能最终会消失......如果有人做了这些文件的种子，请告诉我，我很乐意帮助播种！）

Win2k3额外补丁

由一位乐于助人的匿名者创建的一组补丁，建议在此处查看他们的指南，其中包含一些非常有用的信息： https: //rentry.co/win2k3-extra-patches

XP 源端口

Win2003 源中缺少的一些组件可以在 XPSP1 树中找到，尽管通常比 Win2003 RTM 附带的组件二进制文件更旧（缺少某些错误修复等）。一些匿名者已经成功地将它们移植到 Win2003 树，甚至基于 Win2003 二进制文件更新它们。

base\hals\processor\：负责processr.sys, amdk6.sys, amdk7.sys, p3.sys & crusoe.sys

起初不会在 Win2k3 树中构建，但一个匿名者发现了构建所需的编辑内容，另一个匿名者后来根据 Win2003 驱动程序二进制文件添加了代码更新。除功能外，大部分已更新至Win2003 SP0级别GetAcpiTable。

截至上次指南更新的最新版本： processorXP_win2003_update.7z

base\ntsetup\pidgen\：负责pidgen.dll

Win2003 RTM 二进制文件公开了 XP 版本中缺少的一些新导出，这是 Win2003 安装和其他使用它所需的。
这些是由匿名者添加的，但后来发现 Win2003 还使用了一个较新的加密库，该库允许使用更大的公钥，遗憾的是源包中的任何地方都没有提供该库。

这使得更新 XP 代码以匹配 Win2003 的二进制文件变得更加困难，但是使用更新的导出的更新代码仍然可以用于制作 win2003 安装程序可以使用的 DLL - 例如。一个匿名者使用此代码制作了一个接受任何密钥的 pidgen，只要 winlogon 没有激活 WPA 垃圾，似乎就可以很好地工作。

截至上次指南更新的最新版本： win2003_pidgenXP_cracked.zip（需要 winlogon200X 或修补过的 winlogon 2003）

shell\osshell\accessib\magnify：负责magnify.exe & mag_hook.dll

在 Win2003 下构建良好，有人想出了如何更新 magnify.exe 代码以匹配 Win2003 二进制文件（因为 narrator.exe 代码进行了相同的更改，幸运的是我们有 Win2003 版本，可以轻松复制这些更改）

base\fs\utils\dfrg：负责defrag.exe, dfrgntfs.exe, dfrgfat.exe, dfrgres.dll, dfrgsnap.dll & dfrgui.dll

在 Win2003 下构建良好，但代码比实际的 Win2003 二进制文件更旧，并且缺少一些小更新/错误修复。
稍后有人提供了修补代码，使其更接近 Win2003 版本，不过：

我无法获得 GetExtentListManuallyFat 和 ScanNtfs 匹配，决定将它们保留在 XPSP1 中，因为我不太相信我的文件系统代码编写技能。

也许某些文件系统向导可以完全更新它，此外 PDB 路径也存在问题，这些问题被发现主要是由 razzle.cmd 引起的，然后在本指南随附的 ZIP 文件的更新更新中修复了该问题。

运行登录程序

不幸的是，该源工具包中未包含 winlogon 的代码，可能是因为 winlogon 是 WPA 中使用的主要文件之一。这会阻止我们的构建正常启动，除非 winlogon.exe 是从零售版本中获取的（它被 WPA 激活和代码混淆篡改了，谁知道还有什么......）

为了尝试解决这个问题，一位匿名者发布了一个从 win2000 移植到 server2003 的 winlogon 代码版本，后来另一位匿名者修复了此端口以重新启用 InitShutdown 服务（由于缺少文件，该服务在移植期间被删除），然后找到了一个修复程序，允许这个内置的 winlogon 无需重新启动即可进入登录屏幕，虽然这是一个很好的开始，可以使登录提示实际显示而不会崩溃，但不幸的是，尝试登录只会向您显示错误消息。

几个星期过去了，进展甚微，直到有一天，一些匿名者开始谈论如何启动 amd64 构建，发现的主要问题之一是 winlogon - 唯一可用的 amd64 二进制文件来自 SP1+，它似乎无法正常工作在我们的 SP0 amd64 版本上。关于 winlogon 的讨论最终促使匿名者开始更新 win2000 代码，以使其与 win2003 二进制文件更匹配（此处提供了一些所做更改的列表）

不久之后，制作了一个修复版本，最终允许成功登录系统，尽管存在一些问题，例如不支持快速用户切换、配置文件设置不正确等，除了这些小问题之外，总体来说似乎运行得很好。

可悲的是，当匿名者开始使用 winlogon 并开始使用 AMD64 时，/wxp/ 线程也开始消亡，白痴入侵该线程，就琐碎的事情引发愚蠢的争论，使得越来越多的人离开该线程。好的...

然而，一个匿名者确实坚持了下来，并成功地正确地逆转了 XP 的 winlogon，甚至发布了他们的反编译，效果非常完美，遗憾的是大多数匿名者从未见过这一点，因为它是在 /wxp/ 的垂死岁月中，所以很多人仍然认为我们'一直坚持使用被破解的 win2000 版本 - 但现在你知道事实并非如此！

截至上次指南更新的最新版本： ds.zip_decompiled_XPSP1_winlogon.zip - 反编译 XPSP1 winlogon（不是 Frankenstein win2000 版本！） - 或者，franken-win2000 版本：Winlogon200X_v3c.zip

（请注意，winlogon200X 需要进行一些小更改才能使 postbuild 成功使用此 winlogon：编辑winlogon\sources.inc，找到该DELAYLOAD行，然后将其更改为DELAYLOAD=winmm.dll;netapi32.dll;ole32.dll;msgina.dll- 我不确定 ds.zip 是否也需要此操作）

systime.c/exinit.c

base\ntos\ex 文件夹中缺少这两个源文件，而是由同名的预编译 .obj 文件替换。对这些 obj 文件的一些调查显示存在大量 WPA 代码，这可能是没有为其提供代码的原因。

一位匿名者发布了基于不久前制作的WRK objs 重新创建的.c 文件，这些文件似乎在server2003 上运行良好，但后来发现会导致BSOD。那个匿名者后来发布了一个修复版本，显然解决了BSOD，但后来匿名者也发现这个修复版本仍然存在一些它自己的问题（使用了自旋锁，而.obj从未这样做过，缺少win2003有但WRK没有的功能），另一位匿名者还发现，在使用这些重新创建的内容时，系统时钟似乎移动得慢很多。

随着时间的推移，对这些文件进行了一些小的改进（修复了诸如删除自旋锁之类的问题），并且匿名者做了一些工作让 systime.c 与 .obj 匹配，除了一些小部分之外，大部分都取得了成功。

几周后，一个匿名者开始发布 exinit.c 文件，这些文件“100％匹配”供匿名者测试，一旦其他匿名者尝试了它们并发现并修复了一些小错误，匿名者然后发布了一个也包含 systime 的包他们正在开发的.c 游戏，这也是“100% 匹配”。从那时起，它进行了一些小更新来改进检查的构建并修复 64 位构建，但通常看起来工作正常。

因此，距离泄漏事件发生仅几个月后，我们终于有了与泄漏中包含的预编译对象相匹配的 exinit 和 systime 的源代码，让我们可以对其进行任何我们喜欢的更改（例如删除过期/ timebomb 代码），以及为 AMD64 编译运行良好的 exinit/systime 版本（因为不包括该平台的 obj 文件）。非常感谢到目前为止所有为此工作的匿名人士！

截至上次指南更新的最新版本： win2003_missing-ex-files_v2.zip（包含在预先修补的 v10a 中）

EncodePointer/DecodePointer kernel32 函数

这些是在 XP SP2+ 中添加的，作为屏蔽指针地址的方法（作为安全措施？），一些“需要 SP2”或“需要 Vista”的应用程序实际上只需要这两个功能。/g/ 用户发布了更改以允许导出存根函数，后来的用户进行了更新，因此函数的功能也得到了恢复。

截至上次指南更新的最新版本： encdecptr.7z

Sizzle 开发环境

/g/ 用户通过 OpenNT NTOSBE 构建环境移植到 Win2003 源，作为源中包含的 razzle 构建环境的替代品。

目前，它基本上可以很好地构建源代码，但用户注意到了一些问题（仍在等待补丁？）。目前，构建后尚未实现，但也许之后使用 razzle 进行构建后将允许生成安装文件？

显然还可以处理在 AMD64 构建操作系统下的构建以及 Win10 支持，并且基本上可以很好地构建所有 16 位对象，而不会出现任何 NTVDM 问题。

截至上次指南更新的最新版本： Sizzle-devtest.7z

DirectUI库

匿名者找到了一个适合时期的 Bison.exe 版本，并设法修复了 Bison.skl 文件以允许构建 DirectUI.lib，但经过一些测试后发现，与之前的版本相比，这个版本无法正常工作。内置 XP 版本，运行代码时会产生解析错误。

DirectUI 所需的文件仍然包含在 prepatched.zip 中，供任何想要尝试解决此问题的人使用，很可能 MS 对 Bison.skl 进行了相当多的定制，希望有人能够弄清楚究竟更改了什么...

现在我们发现使用源代码中包含的 directuid.lib 中的预编译的 parse.obj 似乎工作得很好，当然使用任何预编译的东西并不理想，但至少这样我们仍然可以构建其余的来自源代码的 DirectUI.lib，而不需要依赖于 XP 中完全预编译（且版本不匹配）的 directui.lib。

主题

匿名者发布了所有正式发布的 MS 主题（Royale/Zune/Embedded 等）的反汇编版本，这些反汇编版本只是插入到现有源代码中，然后将作为正常构建的一部分进行构建，并进行一些小的修改layout.inx 它们也可以自动包含到我们的构建中。

截至上次指南更新的最新版本： win2003_themeadds_v1.zip（感谢 anon 重新更新）

额外的 kernel32.dll 函数

一位开发人员致力于向 kernel32.dll 添加一些额外的功能，这是一些较新的应用程序所需的，您可以在这里找到更多信息：https: //rentry.co/kernel32-extras

（遗憾的是，链接20201202__KERNEL32.DLL.v6.zip文件已被删除，但感谢匿名者已在此处重新启动： https: //mirrorace.org/m/4rIp2）

下层 DLL

与 kernel32.dll 一样，似乎有一些应用程序需要工作的“下层”DLL，用户已在此处为 XP 提供了这些可用版本： https: //rentry.co/extras-downlevel

（就像 kernel32.dll 一样，该文件已被删除，但幸运的是已重新上传到https://mirrorace.org/m/5NDjE

变更日志

每个主要版本都可能会破坏脏构建，需要全新的干净构建，建议如果可能，将新版本应用到新提取的源代码上。

v10

(v10b)用新的镜像替换了死链接，希望这些链接比旧的链接持续时间更长...也许也值得制作一个激流来保持这些链接的活力，否则人们唯一的选择就是阴暗的中文下载网站...
(v10b) 更新了 winlogon 部分以提及 /wxp/ 生命周期后期发布的 ds.zip，不过我自己还没有测试过它
(v10a) 添加了来自匿名反编译的exinit.c&systime.c以及原始 exp.h（以覆盖早期预修补 zip 中旧的修改过的 exp.h）
(v10a) 更新了 prebuild.cmd 以删除泄漏中包含的fre exinit.obj/ ，因此将使用我们重新创建的版本（允许构建更接近原始的 chk 内核，而不是包含 fre exinit/systime 位的 chk 内核）如果您从早期的预修补 ZIP 进行更新，建议再次运行 prebuild.cmd！systime.obj
(v10a) 更新了missing.cmd以包含一些仅chk的文件和srv_info.chm
(v10a) 添加了预生成的inetsrv\iis\svcs\cmp\webdav\davcprox\fhcache_p.c文件，包括 x86/x64 的定义，应该有助于解决 x86/x64 版本之间的切换问题。
(v10a)为 / 添加了 / 包装器，link.bat它随机化 TEMP 环境变量并在失败之前重试 5 次。link16.batlink.exelink16.exe
(v10a) 更新了其他 .bat 包装文件以使用 5 次重试而不是 3 次。
(v10a) 更新了 rc16 内部调用net\tapi\thunk\makefile.inc，将WINNT=1定义更改为WINNT以修复某些 NTVDM 版本下的错误。
[x64] 用重新编译的 amd64 版本替换了一些 16 位工具的 MS-DOS Player，由线程中的匿名者提供（非常感谢！），源代码在里面_x64\tools\tools16\16_bit_build_tools_v2.zip
添加了 amd64 构建所需的缺失public\internal\windows\lib\amd64\usp10p.lib库，取自 XPSP1 树。
将 parse.obj 添加到windows\advcore\duser\directui\engine\parser\obj\amd64&objd文件夹，从 amd64 文件中提取directui.lib。
base\ntos\ex\exp.h添加了基于匿名反编译的更新和 amd64 exinit.obj/systime.obj 文件。
msgina_sp1.def从 winlogon200X 包中添加userenv_sp1.def，这些将使 msgina/userenv 的 amd64 版本使用 SP1 导出序号，从而提高与 SP1 winlogon 以及可能的其他 SP1 文件的兼容性。

v9

(v9c) [x64] 将 32 位 mapsym.exe 和 rc.bat MSDOS-Player 包装器添加到printscan\faxsrv\print\faxprint\faxdrv\win9x\sdk\binw16dir，因为某些匿名者似乎从此文件夹中收到错误。
(v9b) [x64] 替换masm.exe/mkpublic.exe为 32 位版本（取自 Sizzle），因为一些匿名者在 MS-DOS 播放器上报告了错误的 DOS 版本时遇到了问题，破坏了这两个工具，因为它们需要 DOS 2.0+ - 感谢来自的匿名者那位帮忙测试的帖子！
64 位构建器支持：添加了_x64包含固定文件的子目录，razzle64.cmd用于在 64 位主机下构建（在 Win7SP1 x64 和 Win10 x64 下测试）
更新了 razzle.cmd 以进行设置，NO_PDB_PATHS=1无需官方构建参数（在上面的添加列表中推理）
通过添加到 makefile 来修复ixsso构建错误BUILD_ALLOW_MIDL_WARNINGS=1，阻止 MIDL2346 警告破坏构建（警告似乎是由使用非美国语言环境引起的？可以通过参数或语言环境模拟器来修复吗？）
重新排序windows\appcompat\dirs文件以帮助单核构建（来自 idkwhy 的 OpenXP git 存储库）
更新msitoddf.cpp，现在完成后关闭 MSI 包句柄（防止在 Win10 上停止构建后），并添加针对 64 位构建操作系统的修复（将 SysWOW64 重定向到 System32）
更新了mshtml.ref参考文件 - 用于将 mshtml 输出与已知良好的输出进行比较？最后更新于 1999 年（！），如果不更新，它似乎会在某些条件下随机导致构建错误（虽然只开始出现在 win10 上，但从未在 win7/XP 上出现过......）

v8

(v8d) 恢复srv_info.chm更改，因为匿名者设法在 XP x64 ISO 映像中找到该更改，现在包含在其中2k3-missing-x86fre-v7.7z
(v8d) 已更新cddirs.lst以允许将valueadd\3rdparty文件夹包含到 CD 映像中。
(v8c) 更新了 razzle.cmd 以始终设置__BUILDMACHINE__变量，无论“离线”参数如何，允许内置到内核中的构建标记与 BuildName.txt 匹配
注意：上面的 razzle.cmd 更改之后将需要清理构建！如果您想继续使用当前构建进行“脏”构建，请确保不要从此包中提取更新的 razzle.cmd
(v8c) 如果未提供目标路径，则使 oscdimg.cmd 使用 BuildName.txt 中的构建标记作为输出文件名
(v8c) 删除了 directui_XP.lib 文件，因为我们构建的 directui.lib 似乎工作正常
(v8b) 为 DirectUI 添加了预构建的 parse.obj 文件，取自 win2003 directuid.lib - 允许我们构建 DirectUI 的工作版本！
(v8b) 更新了shell\cpls\appwzdui\winnt\sources, shell\ext\logondui\sources&shell\shell32\winnt\sources文件以抑制由预构建的 parse.obj 生成的 LNK4206 警告。
(v8b) 删除了所有引用srv_info.chm（无法在任何地方找到，RTM ISO 似乎没有它），也可以将其删除，这样它就不会再搞乱任何构建了。
(v8b) 更新setupw95.cmd并drivercab.cmd在异步调用之间添加延迟，修复了文件名冲突问题。（仅在较新的操作系统下需要更新，像XP这样的旧操作系统似乎没有这个问题）
(v8b) 更新windows\advcore\dirs文件以允许在主构建期间构建 DUser/DirectUI
(v8a) 从 pbuild.dat 禁用 incbbt.cmd，因为缺少 incbbt.cmd 文件
更新了 com\ole32\olethunk\ole16\tools\ 内的 16 位构建工具，并更新了 olethunk 代码，以便可以很好地构建它们。
删除了预构建的 16 位代码
更新了 prebuild.cmd 以处理更新的 16 位工具，而不是使用预构建的内容（仅在操作系统需要时才使用更新的文件）
2k3-missing-x86fre.7z禁用来自 pbuild.dat 的 fixprn.pl、ntbackuponpersonal.cmd、gpmc.cmd 和 msi.cmd 调用，因为我们缺少这些所需的构建文件（您可以从 RTM ISO 或包中获取这些脚本的结果））
感谢制作的匿名者2k3-missing-x86fre，我们现在应该能够在没有任何构建后错误的情况下进行构建！

v7

(7e) 删除了 DUser/DirectUI 构建指令，将 DUser.dll 读取到 Missing.cmd - 遗憾的是我们构建的指令无法正常工作并破坏了prosku 的登录屏幕。可能是因为 Bison.skl 是 MS 定制的，源代码中缺少该文件。
(7d) 从missing.cmd中删除了DUser.dll
(7c) 更改了 DUser placefil.txt，因此 DUser.dll 被放置在 binaries.x86fre 根目录中
(7c) 更新了 DUser bldenv.cmd，以便“bldenv release”也将重置优化标志，现在发布版本将得到适当的优化
包括来自guideanon v4工具包的Win7修复，希望减少人们的NTVDM错误
添加了用于构建 DUser.dll/DirectUI.lib 的文件和说明，现在可以构建正确的 server2003 版本，而不需要 WinXP 版本
添加预构建的 GdiPlus 1.0.100.0，因为我们无法构建 GdiPlus 代码 atm （应该允许构建工作asms01.cab/ hivesxs.inf）
从 Missing.cmd 中删除了asms01.cab/hivesxs.inf
将 prebuild 移至tools\prebuild.cmd，之后不再删除自身，以防需要再次运行
重新排序了一些构建准备步骤，DirectUI.lib在主构建之前添加了有关构建的详细信息

文件哈希

本指南使用的文件的 SHA-256 哈希值：

nt5src.7z（在您最喜欢的搜索引擎上搜索“nt5src notrepacked”）：2BB3609FA4C2B2641F43AEF751A84DB5820B64748B7D2D0891D1CB1E55268CE9
win2003_prepatched_v10a.zip：CF2079B49A9119D308D61F46DF21EC064BFF700F4518EC35DE02974E5C7784DA _
win2003_x86-missing-binaries_v2.7z：D141ECE0EB7710B655903EE301DEC197B1A114618A567100677F0C4D93998C81
处理器XP_win2003_update.7z：21EE0C471A4CE603DC36ED90C47FC207CA25539460DE212D72E8304E27EBB5A3
win2003_pidgenXP_cracked.zip：E0D7A6C2B2A17034589849AB6C64D45F6AA4B7873874A894434F3F00F528CE57 _
ds.zip_decompiled_XPSP1_winlogon.zip：01D291FCDD6F9D8AFA52872B08398796C0C6C988743CF4447A557A52600BA5B4 _
Winlogon200X_v3c.zip：1D9EC8E35665FAB5747CFB0DF14D1ABF4E79080FA2A18C5A6DD7BF8018FC4231 _
encdecptr.7z：2A9DFB9896C3B936DFF7E07F9D5C274187D01920B2245E326DE4B96EC188FA1F
Sizzle-devtest.7z：B165A1CDD1AC6C4C4C46A991387902C7547E1FAEA81E82E5C9901E6C7831D90E
win2003_themeadds_v1.zip：94AC075197790A5E2B28A51CF7DAD5B89864746AC14408EC4F14B50D23901EF3 _
20201202__KERNEL32.DLL.v6.zip：C03F13DB8E814B673AA6AE3F7AE2D18B794CD5F33BE912D4BBC6B58F4EE9637D _
20201202_downlevel.zip：B7CB9F5023D1AF39B7698D826D050917D4EA566C0EB02159EC3A78AED9A43587 _