二楼目录

# `0x00` 看前须知
本文共介绍两种构建方法，分别对应 Windows 平台的两组编译环境：MSVC 和 mingw(gcc). 无论使用哪一个方法都能达到目的，如果你现在不能确定要使用哪一个工具，建议先完整阅读本文再评估适合自己的方法，之后如有需要再选定其中一种边看边做。因为两种方法各有各难受的地方，不要做到一半才发觉这条路子不适合自己，白白浪费时间。

# `0x01` 准备工作
## nhsetup
刚从 git 拉取下来的仓库在使用前需要进行一定的准备工作。打开项目目录，转到 `\sys\windows` 目录，执行里面的 `nhsetup.bat` .

成功后，根据末尾提示，找到这个目录下的 `Install.windows` 文件，这个文件详细记录了后续步骤。

# `0x01` 准备工作
## 构建 submodules
第 72 行开始，提示我们在编译前需要构建这个仓库依赖的 submodules:

按照提示，我们需要在项目根目录执行如下命令：
git submodule init
git submodule update
但直接执行命令大概率会失败，报错信息如下：

git 不认为当前仓库是安全的，因为该仓库的 owner 并不是当前用户。你可以执行最下方弹出的提示信息接管当前仓库，如果你跟我一样在用 vscode 执行这些操作，也可以用 GUI 完成操作 (Ctrl+Shift+G 源代码管理)。

解决完当前问题，重新执行上述两条命令。过程中会从 GitHub 拉取仓库 `lua` , `pdcurses` , `pdcursesmod` . 因为是从一个众所周知的网站上下载，所以要么看运气要么懂得都懂，这里不过多赘述。在 update 过程中这三个仓库同样也需要我们解决安全问题，再次，如果你在用 vscode 等集成 git 功能的环境完成这些操作，可能会直接有交互式 GUI 帮助你：


至此，预处理的一些操作都已完成。

# `0x02` 方案一：使用 MSVC 构建
## 安装 Visual Studio
官网下载 Visual Studio Installer，社区版足矣。
https://visualstudio.microsoft.com/zh-hans

请至少勾选 `使用 C++ 的桌面开发` ，并选择右侧附加项目的 `Windows 10 SDK (10.0.20348.0)` . 未来，devteam 可能会变更 SDK 版本，但当前的情况是最好选择该版本，别的版本可能无法正常通过编译。

# `0x02` 方案一：使用 MSVC 构建
## 构建
打开项目目录下 `\sys\windows\vs` 目录，找到解决方案文件 `NetHack.sln` ，双击打开（使用 Visual Studio 打开）。

成功载入解决方案后看到如下窗口：

现在就已经可以开始编译了，但你需要注意：
1. 右侧 10 个项目中与你直接有关的就是 NetHack 和 NetHackW
2. 默认会选中 NetHackW ，即 Windows 平台的 GUI 版本，如果你只需要命令行版本，单击 NetHack 即可选中
3. 上方的编译优化选项默认为 Debug，暂时不需要调试的话请切换到 Release 模式。因为 Debug 模式会生成体积庞大的调试信息，同时不会对可执行文件进行优化，影响执行性能
4. 最后点击菜单栏上的 `生成->生成 NetHack(或 NetHackW)` 即可开始编译

成功后命令行输出会提示生成路径，默认在 `\binary\Release(如果是 Debug 模式下编译，此处为 Debug)\x64` 下会找到可执行文件。

# `0x03` 方案二：使用 mingw 构建
## 安装 mingw
个人使用的是 `winlibs_mingw`
https://github.com/brechtsanders/winlibs_mingw/releases
需要将其中的 `mingw64\bin` 目录添加到 PATH 环境变量。

# `0x03` 方案二：使用 mingw 构建
## 构建
根据 `Install.windows` 文件，需要先进入项目的 `src` 目录，执行如下命令：

正常情况下，从第二条命令开始就已经出错了。命令行可能仍然是 0 值返回，但输出文本的结尾都有 error，且得不到我们想要的结果。

在 error 的前面，可以看到具体是哪个 makefile 的哪一行出错了，如此处的 `Makefile.mingw32:1211` 表示错误出现在文件 Makefile.mingw32 的 1211 行。如果是在 IDE 或其他编辑器环境内，可以 Ctrl + 左键 点击这个文件名，直接跳转到文件的指定行数。此处我们要整玄学的，在出错的行末尾添加 空格 + #，如：

再次执行刚刚出错的那一个命令，就会发现这一行的问题解决了，错误跑到了另外一个地方。所幸在 make 过程中可以从之前未完成的步骤继续，我们只需要把每个报错的地方都做同样的处理，就能一点点推进进度，最后顺利跑完 3 条 make 命令。

为什么会出现这个问题呢？可能的说法是，在 linux 平台，mkdir 等指令是单独的可执行文件，而 windows 则是集成在了命令行功能内，没有单独的 mkdir.exe 等。如果你稍微观察就会发现，所有出错的地方都和系统调用有关，在 CreateProcess 过程中“找不到文件”。而 # 符号会将命令直接提供给 makefile. 这只是一种猜测，至于内部的具体原因，实际上我也不清楚。在 Windows 平台大量使用 makefile 的场景本身并不多见，相关的信息也难以检索，有一个类似的讨论在这里：
https://stackoverflow.com/questions/36401973/windows-makefile-c-mkdir-p

不管怎么说，最终我们编译出了可执行文件。如果你没有修改 Makefile 文件，默认会同时编译出 NetHack.exe 和 NetHackW.exe. 它们保存在 `\binary` 目录下。