Article ID: 320479
Article Last Modified on 1/17/2006
APPLIES TO
- Microsoft Visual C++ 2005 Express Edition
- Microsoft Visual C++ .NET 2003 Standard Edition
- Microsoft Visual C++ .NET 2002 Standard Edition
This article was previously published under Q320479
SYMPTOMS
When you port a Microsoft Foundation Classes (MFC) project that was created by using Microsoft Visual C++ 6.0 to Microsoft Visual C++ .NET or to Microsoft Visual C++ 2005 and then you rebuild the project in Microsoft Visual Studio .NET, the new binaries fail in different ways when you run the project on Microsoft Windows NT 4.0. When you build the project in Visual C++ 6.0, the same source files build binaries that run without error on Windows NT.
CAUSE
Code generated by wizards in previous versions of Visual C++ did not define a value for _WIN32_WINNT in Stdafx.h. New MFC projects in Visual Studio .NET explicitly define _WIN32_WINNT to the standard 0x0400 setting, which targets the Windows NT 4.0 and later operating systems.
Conversion does not change the source files, but the new project uses the new MFC header files for Visual C++ .NET or for Visual C++ 2005. If _WIN32_WINNT was not explicitly defined in the older Stdafx.h files, the included MFC headers define _WIN32_WINNT for you.
The statement
#include <afxwin.h>
eventually includes Afxv_w32.h. This header defines _WIN32_WINNT (if it is not already defined) to be equal to WINVER. In Visual C++ .NET or in Visual C++ 2005, WINVER is set explicitly in Windows.h to be 0x0501. This setting targets the Microsoft Windows 2000 operating system and Microsoft Windows XP operating system, and creates structure definitions that Windows NT 4.0 and earlier do not recognize.
RESOLUTION
To resolve this problem, add at least the following line of code at the beginning of the Stdafx.h file in the converted project:
#define _WIN32_WINNT 0x0400
Verify that this code is added before any MFC header files are included.
For a more complete solution, create a new default MFC project in your version of Visual C++ .NET or of Visual C++ 2005, and then paste the Stdafx.h code created by Visual C++ .NET or by Visual C++ 2005 in the default project before the following line of code:
#include <afxwin.h>
This resolution may help you to work around other issues. The following code was created by the most current version of Visual C++ .NET or of Visual C++ 2005 as of this writing:
// Stdafx.h : Include file for standard system include files,
// or project specific include files that are used frequently,
// but are changed infrequently.
#pragma once
#ifndef VC_EXTRALEAN
#define VC_EXTRALEAN // Exclude rarely-used items from Windows headers.
#endif
// Modify the following defines if you have to target an OS before the ones
// specified in the following code. See MSDN for the latest information
// about corresponding values for different operating systems.
#ifndef WINVER // Permit use of features specific to Windows 95 and Windows NT 4.0 or later.
#define WINVER 0x0400 // Change this to the appropriate value to target
#endif // Windows 98 and Windows 2000 or later.
#ifndef _WIN32_WINNT // Permit use of features specific to Windows NT 4.0 or later.
#define _WIN32_WINNT 0x0400 // Change this to the appropriate value to target
#endif // Windows 98 and Windows 2000 or later.
#ifndef _WIN32_WINDOWS // Permit use of features specific to Windows 98 or later.
#define _WIN32_WINDOWS 0x0410 // Change this to the appropriate value to target
#endif // Windows Millennium Edition or later.
#ifndef _WIN32_IE // Permit use of features specific to Internet Explorer 4.0 or later.
#define _WIN32_IE 0x0400 // Change this to the appropriate value to target
#endif // Internet Explorer 5.0 or later.
#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // Some CString constructors will be explicit.
// Turns off MFC feature that hides of some common warning messages
// that are frequently and safely ignored .
#define _AFX_ALL_WARNINGS
MORE INFORMATION
This behavior can cause problems for any API calls that take structures that may have newer features added for newer operating systems. A common example of this problem occurs when a common dialog box does not open. For example, the OPENFILENAME structure definition has members that are recognized on Windows 2000 and later, but are not recognized on Windows NT 4.0.
Steps to Reproduce the Behavior
To reproduce the problem, follow these steps:
- In Visual C++ 6.0, create a default MFC project.
- Open the About dialog box, and then double-click the OK button; accept the OnOK name.
Add the following sample code in the OnOK function:
CFileDialog Dlg(TRUE); Dlg.DoModal();- Build the project, then run the project on a computer running Windows NT 4.0.
- On the Help menu, click About, and then click OK.
- In Visual C++ .NET, open the same project. To accept the offer to convert the project, click Yes.
- Repeat steps 4 and 5 with the new binary.
The results are different for different operating systems.
- On a computer running Windows NT 4.0, when you start the program that includes the binary that was built in Visual C++ 6.0, and then you click Open on the File menu, the Open dialog box appears.
- When you start the program that includes the binary that was built in VC++ .NET from the same sources, the dialog box does not appear. However, this version of the program works as expected on computers running Windows 2000 and later.
REFERENCES
For more information, visit the following Microsoft Developer Network (MSDN) Web sites:
Using the SDK Headers
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdkintro/sdkintro/using_the_sdk_headers.asp
OPENFILENAME Structure
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/commondialogboxlibrary/commondialogboxreference/commondialogboxstructures/openfilename.asp
Common Dialog Classes
[1]
Additional query words: common dialog commondialog "common dialog" dialogs" fileopen filesave openfiledialog
Keywords: kbmigrate kbprb KB320479
