我尝试迁移的 MFC 应用程序使用 afxext.h，这会导致设置 _AFXDLL，如果我设置 /MT，则会导致此错误：
请为 _AFXDLL 构建使用 /MD 开关
迄今为止，我的研究表明，使用 Visual Studio（在本例中为 C++）2005 构建在 Windows NT 4.0 上执行的应用程序是不可能的。
这是真的吗？有没有可用的解决方法？
【问题讨论】：
标签： c++ visual-studio compatibility windows-nt
不，有许多使用 VS2005 构建的应用程序必须支持 Windows XP、2000、NT 以及整个堆栈。问题是（默认情况下）VS2005 想要使用 NT 上不存在的库/导出。
有关背景信息，请参阅this thread。
然后开始通过预处理器宏限制您的依赖关系，并避免使用 NT 不支持的 API。
【讨论】：
为了摆脱 _AFXDLL 错误，您是否尝试过更改设置以将 MFC 用作静态库而不是 DLL？这类似于您在将运行时库更改为静态而不是 DLL 时已经在做的事情。
【讨论】：
虽然我不熟悉 afxext.h，但我想知道它是什么使它与 Windows NT4 不兼容......
但是，要回答原始问题： “我迄今为止的研究表明，使用 Visual Studio（在本例中为 C++）2005 构建在 Windows NT 4.0 上执行的应用程序是不可能的。”
答案应该是肯定的，尤其是如果应用程序最初是在 NT4 上编写或运行的！除了 afxext.h 之外，这应该很简单。
我发现问题的另一件事是人们抛弃 NT 术语的松散性质。诚然，大多数人认为“NT”是 Windows NT4，但它仍然模棱两可，因为“大多数人”不等于“所有人”。
实际上，“NT”一词等同于 NT 系列。 NT系列是NT3、NT4、NT5（2000、XP、2003）和NT6（Vista）。
Win32 是一个子系统，您也可以针对您的 C/C++ 代码。所以我认为没有理由不能针对这个 NT4 平台和子系统，或者，如果这是一个平台移植练习，删除 VC 可能强加的 MFC 依赖项。
将 afxext.h 添加到组合中，这听起来像是子系统兼容性问题。它是我 Google 研究中 MFC 的一部分。 afxext.h 似乎是 MFC（Microsoft 基础类）扩展。
你能去掉你对 MFC 的依赖吗？这是什么类型的应用程序？ （CLR、服务、GUI 界面？）能否在 VC 8.0 中将项目转换为非托管 C++ 项目？
希望其中的一些内容对您有所帮助。
【讨论】：
解决方法是修复多线程 DLL。 Simple instructions。简短总结：
随附的 8.0 C 运行时库 DLL (MSVCR80.DLL) 不支持 NT 4.0 SP6 有一个原因，而且只有一个原因：Microsoft 的某个人 添加了对
GetLongPathNameW的函数调用，该函数调用在 NT 4.0 上的 kernel32.dll。CRTLIB.C 在第 577 行，调用了
GetLongPathNameW。只需将其替换为：ret = 0;仅在 NT 4.0 上使用此版本的 MSVCR80.DLL。
一旦你得到这些工作，想出一个更通用的解决方案应该是微不足道的。
【讨论】：
想法是需要exe链接到静态库。
请试试这个 “配置属性”、“常规”、“使用 MFC”到“在静态库中使用 MFC” “配置属性”、“常规”、“ATL 的使用”到“ATL 的静态链接”
“配置属性”、“C\C++”、“代码生成”、“运行时库”到“多线程 (\MT)”
测试平台 构建机器：Windows XP SP2 上的 Visual Studio 2005 客户端机器：Window XP SP2（未安装 VS2005）
【讨论】：