我尝试迁移的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)