我尝试迁移的MFC应用程序使用afxext.h，这会导致_AFXDLL被设置，如果我设置/MT，则会导致以下错误：请将/MD开关用于_AFXDLL构建到目前为止，我的研究表明，不可能使用Visual Studio（在本例中为C++）2005构建在Windows NT 4.0上执行的应用程序。这是真的吗？是否有任何可用的变通方法？
afxext.h
_AFXDLL
/MT
dnph8jn41#
不，有许多用VS 2005构建的应用程序必须支持Windows XP、2000、NT和整个堆栈。问题是（默认情况下）VS 2005希望使用NT上不存在的库/导出。参见this thread了解一些背景。然后开始通过预处理器宏限制依赖项，并避免使用NT上不支持的API。
af7jpaap2#
为了消除_AFXDLL错误，您是否尝试更改设置以将MFC用作静态库而不是DLL？这类似于您已经在将运行时库更改为静态而不是DLL中所做的事情。
xbp102n03#
解决方法是修复多线程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的此版本。一旦你得到了这些工作，提出一个更通用的解决方案应该是微不足道的。
GetLongPathNameW
ret = 0;
dly7yett4#
虽然我不熟悉afxext.h，但我想知道是什么使它与Windows NT 4不兼容。然而，为了回答最初的问题：“我迄今为止的研究表明，不可能使用Visual Studio（在本例中为C++）2005构建在Windows NT 4.0上执行的应用程序。”答案应该是肯定的，特别是如果应用程序最初是在NT 4上编写或运行的！除了afxext.h之外，这应该是一个简单的YES。另一件事，我发现麻烦是松散的性质，其中人们正在抛出新台币任期。诚然，大多数人认为“NT”是Windows NT 4，但它仍然是模糊的，因为“大多数人”不等于“所有人”。实际上，术语“NT”等于NT系列。NT系列是NT 3、NT 4、NT 5（2000、XP、2003）和NT 6（Vista）。Win32是一个子系统，你的目标是你的C/C代码。因此，我认为没有理由不能针对这个NT 4平台和子系统，或者，如果这是一个平台移植练习，删除VC可能强加的MFC依赖项。将afxext. h添加到混合中，在我看来这是一个子系统兼容性问题。这是我在谷歌搜索中的MFC的一部分。afxext. h似乎是MFC（Microsoft Foundation Class）扩展。你能移除对MFC的依赖吗？这是什么类型的应用程序？（CLR、服务、GUI界面？你能在VC 8.0中将项目转换为非托管C项目吗？希望其中的一些能帮助你。
t5fffqht5#
这个想法是需要exe来链接到静态库。请尝试此“配置属性”，“常规”，“MFC的使用”到“在静态库中使用MFC”“配置属性”，“常规”，“ATL的使用”到“静态链接到ATL”“配置属性”、“C\C++”、“代码生成”、“运行时库”到“多线程（\MT）”测试平台构建机器：Windows XP SP2客户端计算机上的Visual Studio 2005：Windows XP SP2（未安装VS2005）
5条答案
按热度按时间dnph8jn41#
不，有许多用VS 2005构建的应用程序必须支持Windows XP、2000、NT和整个堆栈。问题是（默认情况下）VS 2005希望使用NT上不存在的库/导出。
参见this thread了解一些背景。
然后开始通过预处理器宏限制依赖项，并避免使用NT上不支持的API。
af7jpaap2#
为了消除_AFXDLL错误，您是否尝试更改设置以将MFC用作静态库而不是DLL？这类似于您已经在将运行时库更改为静态而不是DLL中所做的事情。
xbp102n03#
解决方法是修复多线程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的此版本。一旦你得到了这些工作，提出一个更通用的解决方案应该是微不足道的。
dly7yett4#
虽然我不熟悉afxext.h，但我想知道是什么使它与Windows NT 4不兼容。
然而，为了回答最初的问题：“我迄今为止的研究表明，不可能使用Visual Studio（在本例中为C++）2005构建在Windows NT 4.0上执行的应用程序。”
答案应该是肯定的，特别是如果应用程序最初是在NT 4上编写或运行的！除了afxext.h之外，这应该是一个简单的YES。
另一件事，我发现麻烦是松散的性质，其中人们正在抛出新台币任期。诚然，大多数人认为“NT”是Windows NT 4，但它仍然是模糊的，因为“大多数人”不等于“所有人”。
实际上，术语“NT”等于NT系列。NT系列是NT 3、NT 4、NT 5（2000、XP、2003）和NT 6（Vista）。
Win32是一个子系统，你的目标是你的C/C代码。因此，我认为没有理由不能针对这个NT 4平台和子系统，或者，如果这是一个平台移植练习，删除VC可能强加的MFC依赖项。
将afxext. h添加到混合中，在我看来这是一个子系统兼容性问题。这是我在谷歌搜索中的MFC的一部分。afxext. h似乎是MFC（Microsoft Foundation Class）扩展。
你能移除对MFC的依赖吗？这是什么类型的应用程序？（CLR、服务、GUI界面？你能在VC 8.0中将项目转换为非托管C项目吗？
希望其中的一些能帮助你。
t5fffqht5#
这个想法是需要exe来链接到静态库。
请尝试此“配置属性”，“常规”，“MFC的使用”到“在静态库中使用MFC”“配置属性”，“常规”，“ATL的使用”到“静态链接到ATL”
“配置属性”、“C\C++”、“代码生成”、“运行时库”到“多线程（\MT）”
测试平台构建机器：Windows XP SP2客户端计算机上的Visual Studio 2005：Windows XP SP2（未安装VS2005）