Windows Server 2003 (NT 5.2.3790.0) 操作系统源代码编译构建指南版本 10b，上次更新 2021/10/21

Windows Server 2003 (NT 5.2.3790.0) 构建指南
版本 10b，上次更新 2021/10/21

XP-Tan

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

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

内容
一个小小的要求
常问问题
搭建准备
构建
一个。故障排除
调试
附加信息
代码添加
变更日志
文件哈希
一个小小的要求
大家好，有一段时间了，我以为我丢失了编辑此页面的密码，但实际上它确实藏在某个地方，呸！

不幸的是，在过去的一年里，几乎所有链接到这里的东西都死了——想出“互联网上的一切都是永恒的”模因的人是一个真正的白痴。

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

但是，我仍然缺少一些东西：

win2003_x86-missing-binaries_v2.7z （感谢匿名者重新提出这个！链接更新如下）
来自 WXP 的源端口 processr.sys, amdk6.sys, amdk7.sys, p3.sys & crusoe.sys （感谢同一个 anon 重新添加它，在下面添加了链接）
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 所需的大部分代码，减去任何激活/加密或第三方代码。

1
2
3
4
5
6
文件名： nt5src 。7 ž
大小： 3 、149 、677 、191 字节

MD5 : 94 DEA413D439DDA8ABCAC83CFE799FC7
SHA - 1 : 350 B2617D3095517A8D1981062C9D88A48B5D1A2
SHA - 256 : 2 BB3609FA4C2B2641F43AEF751A84DB5820B64748B7D2D0891D1CB1E55268CE9
如果您想找到泄漏的干净原始副本，只需在您最喜欢的搜索引擎上搜索“nt5src.7z notrepacked”，合法的洪流磁铁以 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 的问题以及其他可能的问题阻止了它在 atm 中正常启动。（有关更多信息，请参阅amd64 构建支持部分）

需要建造什么？我需要 Visual Studio 吗？
幸运的是，完整的构建工具链包含在泄漏中，所需要的只是一台运行 XP 或更高版本的 Windows 构建机器。

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

这是否有助于在 *nix 上运行 XP 工具/内核？
不太可能，因为这些工具被编码为在一个完全不同的环境中工作，也许如果有人想投入几个月的工作来移植它，但这远不是代码，你可以复制粘贴到 *nix 然后构建。

这段代码是否会以任何方式帮助 ReactOS/WINE？
不，这些项目绝不会想要使用这种被盗/非法的代码（ReactOS 甚至执行了他们自己长达一年的代码审计，据称他们使用的是较旧的泄露代码库！）。

即使暗示你通过这样的代码学到了 Windows 内部知识，也足以使你失去为它们做出贡献的资格（关于这一点，如果你将来想在 ReactOS/WINE 上工作，你可能应该停止查看这个源代码趁你还可以！）

这个泄漏是否来自我听说的密码 RAR？
不，加密的 RAR 是完全不同的东西，结果证明是假的。

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

在 nt5src 文件泄露后的某个时候，最终找到了该 RAR 的密码，即internaldev，这表明 RAR 只不过是一个伪造的存档，它使用了与旧 NT4 泄漏类似的目录结构。

不幸的是，关于丢失然后找到的 RAR 文件紧随其后的实际源代码泄漏的帖子数周导致许多匿名者将两者混淆为相同，所以只是强调：密码-rar与最近泄露！.

这个 NOTREPACKED/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
使用您创建的快捷方式打开 razle 窗口。
如果您的操作系统使用 UAC (Vista+)：

以管理员身份运行命令提示符（通常可以通过在开始菜单中键入 cmd，右键单击Command Prompt-> 来完成Run as administrator）
在命令提示符中，通过键入驱动器号更改到您将源代码提取到的驱动器，例如。 E:
切换到源文件夹： cd srv03rtm
现在启动拉扎勒：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.sku）。 dll 来自 Win2003 Enterprise，因此您的构建应该接受 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)]where{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 后，它显示了一堆错误，“无法识别 tfindcer”等
您可能在 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.errhas bad storage class内部有错误
似乎是由您的语言环境引起的，据报道这在简体中文语言中会发生，但在其他语言中也可能发生。
除了更改您的区域/语言设置，您还可以尝试编辑源文件以删除导致问题的字符，anon 在此处发布了需要更改的文件列表

在 Windows 7 上，我在构建时遇到 NTVDM 崩溃
所有 NTVDM 错误都应该在本指南/ZIP 的 v8 版本中得到解决，但是如果您仍然遇到任何 NTVDM 错误，则 build.log 文件的副本将有助于找出导致它的原因，如果您将其压缩并在线程中发布，希望我们能找到一些东西。

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

例如，这里有一个 boot.ini 有两个选择，一个有调试，一个没有，这个 NTLDR 将在启动时显示一个操作系统启动选择菜单：

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[操作系统]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS= “Windows Server 2003, Enterprise” /fastdetect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Windows Server 2003, Enterprise” /fastdetect /debug /debugport=COM1 /baudrate=115200

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

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

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

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

显然也有一种方法可以让 KDNET 在 2003 上工作（请参阅https://github.com/MovAX0xDEAD/KDNET），但是我们的构建尚未对此进行测试，似乎它应该支持VMware 的模拟网络至少硬件。

（待办事项：在此处添加更多 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阶段。

同样，GUI安装可以通过Windows的引导程序启动之前按F8键调试（进度条等），这应该弹出一个菜单，其中的选项Safe Mode，Debugging Mode等选择Debugging Mode将其连接到COM1在19200波特率设置开始，再次之前。

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

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter\

然后创建一个名为要启用的组件的 DWORD 值（例如LDR），并将该值设置为 hexadecimal 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在此处发表了一篇关于此的帖子，尽管尚未尝试过 afaik .

附加信息
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为 always set NO_PDB_PATHS=1，构建已经使用 FixPdbPaths.exe 从 PDB 中删除文件路径，但该方法会保留零售文件中没有的空字符，也可以启用此功能，因为没有理由不这样做。
更新了ixssomakefile，以防止 MIDL2346 警告破坏构建（警告似乎与语言环境相关，出于某种原因，BUILD_ALLOW_MIDL_WARNINGS仅在 makefile 中定义时才起作用，很奇怪）
重新排序的windows\appcompat\dirs文件以帮助进行单核构建（来自 idkwhy 的 OpenXP git repo）
更新msitoddf.cpp，现在在完成时关闭 MSI 包句柄（防止在 Win10 上停止后期构建），并添加了针对 64 位构建操作系统的修复（将 SysWOW64 重定向到 System32）
更新的mshtml.ref参考文件 - 用于将 mshtml 输出与已知良好的输出进行比较？最后一次更新是在 1999 年（！），如果不更新它似乎会在某些情况下随机导致构建错误（我不知道为什么我们从来没有遇到过这个问题，直到我们尝试了 64 位的东西…）
[x64] 向printscan\faxsrv\print\faxprint\faxdrv\win9x\sdk\binw16目录添加了 32 位 mapsym.exe 和 rc.bat MSDOS-Player 包装器，因为一些匿名者似乎从这个文件夹中得到了错误。
[x64] 替换masm.exe/mkpublic.exe为 32 位版本（取自 Sizzle），因为一些匿名者在 MS-DOS 播放器报告错误的 DOS 版本时遇到问题，破坏这两个工具，因为它们需要 DOS 2.0+
[x64] 用重新编译的 amd64 版本替换了一些 16 位工具的 MS-DOS 播放器，由线程中的匿名提供（非常感谢！），内部提供源 _x64\tools\tools16\16_bit_build_tools_v2.zip
添加public\internal\windows\lib\amd64\usp10p.lib了 amd64 构建所需的缺失库，取自 XPSP1 树。
将 parse.obj 添加到windows\advcore\duser\directui\engine\parser\obj\amd64&objd文件夹，从 amd64directui.lib文件中提取。
从 winlogon200X 包中添加msgina_sp1.def& userenv_sp1.def，这些将使 msgina/userenv 的 amd64 版本使用 SP1 导出序数，提高与 SP1 winlogon 和可能的其他 SP1 文件的兼容性。
添加exinit.c&systime.c来自 anon 的反编译，以及原始的 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 位等效项来完成的，等等。

不幸的是，一些打包的 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 模式以完全启动。

请注意，此源代码是在 amd64 作为 Server2003 SP1 由 MS 正式发布之前大约 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 - 在构建“免费”位时构建“已检查”（测试）内核/hal/ntdll
no_opts - 禁用二进制优化（对于调试很有用，但很可能会导致完整构建失败，某些代码在没有优化的情况下无法构建）
verbose - 启用构建过程的详细输出
binaries_dir - 指定自定义输出目录（默认为binaries，后缀.不可自定义）
officialbuild - 设置 razzle 将其构建为“官方”构建，需要更新 BuildMachines.txt，请参阅下面的部分
win64 amd64- 为 amd64 而不是 x86 构建，请参阅amd64 build support上面的部分。
其他选项这里不做介绍，razzle.cmd /?详情请见。

‘OfficialBuild’ 参数 / BuildMachines.txt
该OfficialBuild拉扎勒参数更改在构建一些东西，这将使其匹配更接近零售版本，应该是有用的，如果你需要对零售比较的任何理由。

有关受 OfficialBuild 参数影响的列表，请参阅https://pastebin.com/VgVph3Xv和https://pastebin.com/gYzWGLM5，感谢编译它们的匿名者！（请注意，这些不是完整的列表，并非此处提到的所有内容都能保证生效）。

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

更新所需文件的一种简单方法是在 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，否则构建将不会正确地将自己视为正式版本。
伪本地化构建
anon 在本地化方面取得了一些进展，允许以 3 种不同的配置创建“伪本地化”（PLOC）构建，通过某些 razzle 选项和构建后脚本更改，这些构建应该对希望创建非英语的人有用建立。

可用的三个配置是 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 源端口
在 XPSP1 树中可以找到 Win2003 源中缺少的一些组件，尽管通常比 Win2003 RTM 附带的组件二进制文件更旧（缺少某些错误修正等）。一些匿名者已经成功地将它们移植到 Win2003 树，甚至基于 Win2003 二进制文件更新它们。

base\hals\processor\： 负责 processr.sys, amdk6.sys, amdk7.sys, p3.sys & crusoe.sys
起初不会在 Win2k3 树中构建，但一个匿名者发现了构建所需的编辑，另一个匿名者后来添加了基于 Win2003 驱动程序二进制文件的代码更新。除了GetAcpiTable功能外，大部分都更新到了Win2003 SP0级别。

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

base\ntsetup\pidgen\： 负责 pidgen.dll
Win2003 RTM 二进制文件暴露了 XP 版本中缺少的一些新导出，这是 Win2003 安装程序和其他使用它所必需的。
这些是由匿名添加的，但后来发现 Win2003 还使用了一个更新的加密库，允许使用更大的公钥，遗憾的是在源包中的任何地方都没有。

这使得更新 XP 代码以匹配 Win2003 的二进制文件变得更加困难，但是使用较新导出的更新代码仍然可以用于制作 Win2003 的安装程序可以使用的 DLL - 例如。anon 使用此代码制作了一个接受任何密钥的 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 二进制文件旧，并且缺少一些小的更新/错误修复。
Anon 后来提供了补丁代码，使其更接近 Win2003 版本，尽管：

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

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

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

为了解决这个问题，anon 发布了一个从 win2000 移植到 server2003 的 winlogon 代码版本，后来另一个 anon 修复了这个端口以重新启用 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（不是科学怪人 win2000 版本！） - 或者，科学怪人-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 上似乎可以正常工作，但后来发现会导致蓝屏死机。那个匿名后来发布了一个显然解决了蓝屏死机的固定版本，但后来匿名者也发现这个固定版本仍然有它自己的一些问题（使用自旋锁而 .obj 从来没有，缺少 win2003 有但 WRK 没有的功能），另一个匿名者还发现，在使用这些重新创建时，系统时钟似乎移动得慢了很多。

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

几周后，匿名者开始发布 exinit.c 文件，这些文件“100% 匹配”以供匿名者测试，一旦其他匿名者试用它们并发现并修复了一些小错误，匿名者随后发布了一个包含系统时间的包.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
界面库
一个匿名者发现了一个适合时期的 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来自 anons 反编译，以及原始 exp.h（覆盖早期预修补 zip 中较旧的修改 exp.h）
(v10a) 更新 prebuild.cmd 以删除包含在泄漏中的 fre exinit.obj/ systime.obj，因此将使用我们重新创建的版本（允许构建更接近原始的 chk 内核，而不是包含 fre exinit/systime 位的 chk 内核）如果您从较早的预修补 ZIP 更新，建议再次运行 prebuild.cmd！
(v10a) 更新了 missing.cmd 以包含一些仅 chk 的文件和 srv_info.chm
(v10a) 添加了预先生成的inetsrv\iis\svcs\cmp\webdav\davcprox\fhcache_p.c文件，包括 x86/x64 的定义，应该有助于解决在 x86/x64 版本之间切换的问题。
(v10a)为/添加link.bat/link16.bat包装器，它随机化 TEMP 环境变量并在失败前重试 5 次。link.exelink16.exe
(v10a) 更新了其他 .bat 包装器文件以使用 5 次重试而不是 3 次。
(v10a) 更新了 rc16 内部调用net\tapi\thunk\makefile.inc，将WINNT=1定义更改WINNT为修复某些 NTVDM 版本下的错误。
[x64] 用重新编译的 amd64 版本替换了一些 16 位工具的 MS-DOS 播放器，由线程中的匿名提供（非常感谢！），内部提供源 _x64\tools\tools16\16_bit_build_tools_v2.zip
添加public\internal\windows\lib\amd64\usp10p.lib了 amd64 构建所需的缺失库，取自 XPSP1 树。
将 parse.obj 添加到windows\advcore\duser\directui\engine\parser\obj\amd64&objd文件夹，从 amd64directui.lib文件中提取。
添加了base\ntos\ex\exp.h基于匿名反编译的更新的& amd64 exinit.obj/systime.obj 文件。
从 winlogon200X 包中添加msgina_sp1.def& userenv_sp1.def，这些将使 msgina/userenv 的 amd64 版本使用 SP1 导出序数，提高与 SP1 winlogon 和可能的其他 SP1 文件的兼容性。
v9
(v9c) [x64] 向printscan\faxsrv\print\faxprint\faxdrv\win9x\sdk\binw16目录添加了 32 位 mapsym.exe 和 rc.bat MSDOS-Player 包装器，因为一些匿名者似乎从这个文件夹中得到了错误。
(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不需要官方构建参数（上面添加列表中的推理）
ixsso通过添加BUILD_ALLOW_MIDL_WARNINGS=1到 makefile 来修复构建错误，阻止 MIDL2346 警告破坏构建（警告似乎是由使用非美国语言环境引起的？这可以通过参数或语言环境模拟器修复吗？）
重新排序windows\appcompat\dirs文件以帮助进行单核构建（来自 idkwhy 的 OpenXP git repo）
更新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__变量而不管“offline”参数如何，允许构建标记内置到内核中以匹配 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 位工具，而不是使用预先构建的东西（如果操作系统需要它们，只会使用更新的文件）
禁用了来自 pbuild.dat 的 fixprn.pl、ntbackuponpersonal.cmd、gpmc.cmd 和 msi.cmd 调用，因为我们缺少这些所需的构建文件（您可以从 RTM ISO 或2k3-missing-x86fre.7z包中获取这些脚本的结果)
感谢制作 的匿名者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 root 中
(7c) 更新了 DUser bldenv.cmd 以便“bldenv 发布”也将重置优化标志，现在发布版本将得到适当的优化
包括 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