My research to date indicates that it is impossible to build an application for execution on Windows NT 4.0 using Visual Studio (C++, in this case) 2005. Is this really true? Is there any workaround available?
+4
A:
No, there are many applications built with VS2005 that have to support Windows XP, 2000, NT, the whole stack. The issue is that (by default) VS2005 wants to use libraries/exports not present on NT.
See this thread for some background.
Then start limiting your dependencies via preprocessor macros, and avoiding APIs which aren't supported on NT.
James D
2008-08-03 16:54:12
A:
CodingTheWheel,
Thanks for your response and for that link. The only solution suggested and not shot down in that thread is:
Change the CRT linkage in "Configuration Properties", "C\C++", "Code Generation", "Runtime Library" to "Multi-Threaded (\MT)" from "multi-threaded DLL (\MD)". Your binary will be bigger ofcourse, but the static library does not use GetLongPathNameW so your problem should go away.
Unfortunately, when I tried that, the compiler complained:
Please use the /MD switch for _AFXDLL builds
The application that I'm trying to migrate uses afxext.h, which causes _AFXDLL to get set, which causes this error if I set \MT.
Any other ideas?
MOE37x3
2008-08-04 14:01:20
+1
A:
To get rid of the _AFXDLL error, have you tried changing to the settings to use MFC as a static lib instead of a DLL? This is similar to what you're already doing in changing the runtime libs to static instead of DLL.
Adam Mitz
2008-08-23 01:16:26
A:
Although I'm not familiar with afxext.h, I am wondering what about it makes it incompatible with Windows NT4....
However, to answer the original question: "My research to date indicates that it is impossible to build an application for execution on Windows NT 4.0 using Visual Studio (C++, in this case) 2005."
The answer should be yes especially if the application was originally written or running on NT4! With the afxext.h thing aside, this should be an easy YES.
The other thing I am finding trouble with is the loose nature in which people are throwing out the NT term. Granted most people think of 'NT' as Windows NT4 but it's still ambiguous because 'most people' is not equal to 'all people.'
In reality the term 'NT' is equal to the NT series. The NT series is NT3, NT4, NT5 (2000, XP, 2003) and NT6 (Vista).
Win32 is a subsystem which you target your C/C++ code too. So I see no reason why one should not be able target this NT4 platform & subsystem or, if this is a platform porting excercise, remove the MFC dependencies that VC is possibly imposing.
Adding the afxext.h to the mix, it sounds to me like a subsystem compatibility issue. It's part of MFC from my Google research. The afxext.h appears to be the MFC (Microsoft Foundation Class) extensions.
Can you remove your dependency on MFC? What type of application is this? (CLR, service, GUI interface?) Can you convert project to an unmanaged C++ project in VC 8.0?
Hopefully some of this will help you along.
Eric M
2008-09-18 16:18:02
+1
A:
The workaround is to fix the multi-threaded DLL. Simple instructions
Once you've got those working, coming up with a more generic solution should be trivial.
MSalters
2008-10-14 12:32:59
A:
The idea is that the exe is needed to link to the static library.
Please try this "Configuration Properties", "General", "Use of MFC" to "Use MFC in a Static Library" "Configuration Properties", "General", "Use of ATL" to "Static Link to ATL"
"Configuration Properties", "C\C++", "Code Generation", "Runtime Library" to "Multi-Threaded (\MT)"
Test Platform Build Machine: Visual Studio 2005 on Window XP SP2 Client Machine: Window XP SP2 (no VS2005 installed)