Build for Windows NT 4.0 using Visual Studio 2005?

Question

An MFC application that I'm trying to migrate uses afxext.h, which causes _AFXDLL to get set, which causes this error if I set /MT:

Please use the /MD switch for _AFXDLL builds

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 true? Are there any workarounds available?

Expunction

Someone please protect this. – Aitch

Answer 1

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.

Nisa

What makes this issue confusing is that if you static link, only the object files needed for the symbols you use are actually pulled in, which is why it appears to work on NT4 most of the time. – Wharf

Answer 2

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.

Hewie

Answer 3

The workaround is to fix the multi-threaded DLL. Simple instructions. Short summary:

The shipping 8.0 C Runtime Library DLL (MSVCR80.DLL) does not support NT 4.0 SP6 for one reason and one reason only: someone at Microsoft added a function call to GetLongPathNameW which does not exist in kernel32.dll on NT 4.0.

CRTLIB.C On line 577, there is a call to GetLongPathNameW. simply replace it with: ret = 0; only use this build of MSVCR80.DLL on NT 4.0.

Once you've got those working, coming up with a more generic solution should be trivial.

Blistery

Answer 4

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.

Halfwit

Answer 5

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)

Themistocles