vc6.0工程转成vs2008出现的问题及解决办法（转）

直接用 Visual Studio 2008 的打开 VC6 的工作区文件和项目文件（ dsw 和 dsp ），并将其升级为 VS2008 的解决方案格式和项目格式（ sln 和 vcproj ）， VC9 的编译器相对于 VC6 有了很大的变化，一些编译参数和链接参数被废弃（比如 /map:line ），有一些改变了名称 , 还有新增的选项，不过不用担心，升级过程会自动对其进行转换，最终都会得到一个正确的解决方案和 VC 项目文件，这个过程不会遇到太多的麻烦，问题都出在随后的编译过程中，下面就将我在移植的过程中遇到的问题和我的解决方法总结一下，希望对还在用 VC6 维护代码的朋友有所帮助。   

一、 _WIN32_WINNT  与  _WIN32_IE  设置冲突  

    _WIN32_WINNT  与  _WIN32_IE 设置不兼容会导致如下 C1189 致命错误：  

StdAfx.cpp
c:\program files\microsoft sdks\windows\v6.0a\include\sdkddkver.h(217) : fatal error C1189: #error :  _WIN32_WINNT settings conflicts with _WIN32_IE setting

StdAfx.cpp 通常是项目中第一个编译的文件，这个错误将导致编译无法继续进行。产生这个错误的原因是原因是 _WIN32_WINNT 的版本定义太老，老的 VC 代码对 _WIN32_WINNT 的典型设置是：  

#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0400
#endif

0x0400 相对于 VS2008 所带的 Plarform SDK （在文件 sdkddkver.h 中）中 _WIN32_IE 的定义来说太老了，导致不兼容，可以将其改成 0x0501 或更高的版本避免这个问题，如下所示：  

#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0501
#endif

也可以将这三行 _WIN32_WINNT 定义删除，这样就会使用 Plarform SDK 中的 _WIN32_WINNT 定义，自然就不存在不兼容问题了。不过出于对老版本 VC 的兼容考虑（毕竟以后可能还要使用 VC6 编译代码），最好这样修改：  

#if _MSC_VER <= 1200 // MFC 6.0 or earlier
    #ifndef _WIN32_WINNT
    #define _WIN32_WINNT 0x0400
    #endif
#endif

二、 afximpl.h 文件中的语法错误  

    MFC 出现的时候 STL 还没有成为 C++ 的标准，所以 MFC 使用一套自己的模版库，比如 CArray 、 CList 、 CMap 等等，这些类型声明都在 afximpl.h 文件中。原来在 VC6 编译器适用的模版语法可能不适用 VC9 ，特别是当以下四个环境变量设置不兼容时，就会出现这个编译错误，大致情况如下：  

e:\software\microsoft visual studio 9.0\vc\atlmfc\src\mfc\afximpl.h(625) : error C2059: syntax error : '<L_TYPE_raw>'
e:\software\microsoft visual studio 9.0\vc\atlmfc\src\mfc\afximpl.h(625) : error C2238: unexpected token(s) preceding ';'
e:\software\microsoft visual studio 9.0\vc\atlmfc\src\mfc\afximpl.h(629) : error C2059: syntax error : '<L_TYPE_raw>'
e:\software\microsoft visual studio 9.0\vc\atlmfc\src\mfc\afximpl.h(629) : error C2238: unexpected token(s) preceding ';'

合理调整 stdafx.h 中 WINVER 、 _WIN32_WINNT 、 _WIN32_WINDOWS 和 _WIN32_IE 的设置可以避免这个问题，将三个与 Windows 版本有关的环境变量设置为 0x0501 或更高版本，将 IE 版本的环境变量设置为 0x0500 以后的版本就可以解决这个问题。当然，考虑到与旧的 VC6 代码兼容，可以采用上一个问题中提到的最后一个解决办法，用 _MSC_VER 进行隔离。  

三、 旧的 CRT 库和新的安全 CRT 库引起的 C4996 告警  

     解决了环境变量设置不匹配导致的问题后，编译过程就真正开始了，不过首先映入眼帘的应该是成堆的 C4996 编译告警，对每个使用了含字符串参数的 CRT 库函数都会有 C4996 编译告警，一个典型的输出如下所示：  

f:\project\.....\commonfunc.cpp(280) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
e:\software\microsoft visual studio 9.0\vc\include\string.h(74) : see declaration of 'strcpy'

    MSDN online  是这样解释的：为了显著增加 CRT 库的安全性，许多 CRT 函数都有了一个更安全的新版本，新版本和旧版本的区别就是新版本函数名多了一个 _s 后缀。只要一个 CRT 函数有新的安全版本，编译器就会产生一个 C4996 告警，不过，出现这个告警的目的并不是说旧版本的 CRT 函数将淡出 CRT 库，告警出现只是为了提醒程序员这个函数有更安全的版本存在。一种安全的或者是被鼓励的做法是用安全版本的函数替换现有的 CRT 函数，不过对于一个有相当代码量的项目，替换工作量也是巨大的，这可不是用名称查找、替换就能简单解决的问题，因为许多安全版本的 CRT 函数参数个数也发生了变化。也可以用预处理指令消除这个告警：  
#pragma warning( disable : 4996 )
或者定义  _CRT_SECURE_NO_WARNINGS  压制这个告警（在 stdafx.h 中 define 或在项目属性中设置预处理符号 ,PreProcessor Definitions ）。  

     除了 C 语言的 CRT 函数外， POSIX  兼容函数也存在这个告警，解决方法是用 POSIX 标准名称替换（比如 access 换成 _access ）或者是定义  _CRT_NONSTDC_NO_WARNINGS  压制这个告警（方法同上）。  

四、 “CWinApp::Enable3dControls” 引起的 C4996 告警  

     这个是编译使用了老的向导生成的 MFC 代码时遇到的问题，一个典型的告警信息输出如下所示：  

CrpFileCrack.cpp
f:\project\.....\crpfilecrack.cpp(52) : warning C4996: 'CWinApp::Enable3dControls': CWinApp::Enable3dControls is no longer needed. You should remove this call.
        e:\software\microsoft visual studio 9.0\vc\atlmfc\include\afxwin.h(4818) : see declaration of 'CWinApp::Enable3dControls'

通常向导生成的代码是：  

#ifdef _AFXDLL
    Enable3dControls();            // Call this when using MFC in a shared DLL
#else
    Enable3dControlsStatic();    // Call this when linking to MFC statically
#endif

这两个函数的调用是旧的 MFC 版本对新版本的操作系统特性的支持，在新的（那个时候是新的） Windows 95 平台上要这样调用一下才能使用新的 Windows 3D 样式的控件，否则就是老的 Win 3.2 样子的控件。想当初喜欢 OWL 就是因为感觉它的控件比较 “ 酷 ” ，比如那个带底纹的对话框，菱形的 checkbox ，还有带图标的 “OK” 按钮，看到 MFC 作出来的灰灰的界面就觉得土，不过后来就知道 MFC 做界面也是很漂亮的，比如我做的。。。。，再打住。对于新的 MFC 版本来说已经不需要再调用这两个函数了，参考前面的方法，用 _MSC_VER 对其隔离就行了：  

#if _MSC_VER <= 1200 // MFC 6.0 or earlier
    #ifdef _AFXDLL
        Enable3dControls();            // Call this when using MFC in a shared DLL
    #else
        Enable3dControlsStatic();    // Call this when linking to MFC statically
    #endif
#endif

五、 .def 文件引起的连接告警  

     对于普通的 DLL 项目中使用的 .def 文件通常会引起 LNK4017 链接告警，如下所示：  

.\ComFunc.def(4) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored
   Creating library .\..\Debug/ComFunc.lib and object .\..\Debug/ComFunc.exp

一个典型的 .def 文件通常有以下内容：  

LIBRARY      "XorCryptor"
DESCRIPTION  'XorCryptor Windows Dynamic Link Library'

EXPORTS
    ; Explicit exports can go here
    ..................
消除这个连接告警的方法就是从 .def 文件中删除 DESCRIPTION 描述信息，不过这个告警也不是什么大问题，不删也可以。另一个可能产生的连接告警是 LNK4222 ，通常出现在 ocx 控件和 com 组件的项目中，一个典型输出是：  

Linking...
.\PlusInModule.def : warning LNK4222: exported symbol 'DllCanUnloadNow' should not be assigned an ordinal
.\PlusInModule.def : warning LNK4222: exported symbol 'DllGetClassObject' should not be assigned an ordinal
.\PlusInModule.def : warning LNK4222: exported symbol 'DllRegisterServer' should not be assigned an ordinal
.\PlusInModule.def : warning LNK4222: exported symbol 'DllUnregisterServer' should not be assigned an ordinal

出现这个告警的原因是旧的项目的 .def 文件通常这样定义 ocx 和 com 必需的四个导出函数：  
EXPORTS
    DllCanUnloadNow     @1 PRIVATE
    DllGetClassObject   @2 PRIVATE
    DllRegisterServer   @3 PRIVATE
    DllUnregisterServer    @4 PRIVATE

其中为这四个重要的导出函数指定了四个顺序号。 Windows 平台上通常用两种方式定位 DLL 文件中的导出函数，一种是根据导出函数名称，一种是根据顺序号，上学时曾经写过一个显示图片的程序，能处理大多数当时流行的图像格式文件，唯独 jpeg 格式的搞不定，有一次看到一个图像处理软件中包含了一个 LoadJpeg.dll ，很显然这个 DLL 是处理 jpeg 格式的图像文件的嘛，于是赶快用 depends look 了一下，顿时高喊：鬼啊～～～。原来这个 depends 竟然查不到导出函数的名字，后来才知道还有 NONAME 参数强制用顺序号定位导出函数，于是就常常弄个没有导出函数名字的 DLL 到处 show 。。。。嗯，又扯远了。话说为什么旧的系统要以此指定这四个导出函数的顺序号我就没有研究了，反正现在不需要指定了，只要将 @1 ， @2 之类的删除就行了，不过不删好像也没什么问题，它们会被自动忽略。  

六、使用 MFC 的消息映射宏引起的编译错误  

     错误现象之一：  

f:\project\.....\plusmaindlg.cpp(220) : error C2440: 'static_cast' : cannot convert from 'void (__thiscall CPlusMainDlg::* )(int,BOOL)' to 'LRESULT (__thiscall CWnd::* )(WPARAM,LPARAM)'
        None of the functions with this name in scope match the target type

     错误现象之二：  
f:\project\.....\crpfileopavdlg.cpp(87) : error C2440: 'static_cast' : cannot convert from 'LRESULT (__thiscall CCrpFileOpavDlg::* )(LPCTSTR,int)' to 'LRESULT (__thiscall CWnd::* )(WPARAM,LPARAM)'
        None of the functions with this name in scope match the target type

     以上两个编译错误产生是因为新旧版本的 MFC  中对 ON_MESSAGE 消息映射宏定义不同引起的，先看看老版本的 MFC 的 ON_MESSAGE 消息宏定义：  

#define ON_MESSAGE(message, memberFxn) \
    { message, 0, 0, 0, AfxSig_lwl, \
        (AFX_PMSG)(AFX_PMSGW)(LRESULT (AFX_MSG_CALL CWnd::*)(WPARAM, LPARAM))&memberFxn },

再看看新版本的 ON_MESSAGE 定义：  

#define ON_MESSAGE(message, memberFxn) \
    { message, 0, 0, 0, AfxSig_lwl, \
        (AFX_PMSG)(AFX_PMSGW) \
        (static_cast< LRESULT (AFX_MSG_CALL CWnd::*)(WPARAM, LPARAM) > \
        (memberFxn)) },

注意，函数类型没有变化，都是：  
LRESULT (AFX_MSG_CALL CWnd::*)(WPARAM, LPARAM);
类型的函数指针（ CWnd 以及派生类的类成员函数指针），区别之处是新的 ON_MESSAGE 宏使用 C++ 的  static_cast  操作符代替了 C 类型的强制转换。产生这两个错误其实是因为用户没有按照 ON_MESSAGE 宏的约定声明和定义消息响应函数造成的，比如，对于某些不需要处理返回值的消息响应函数，用户通常这样声明和定义消息响应函数：  

在头文件中声明：  
afx_msg void OnFileProcess(WPARAM wParam,LPARAM lParam);

在源文件中实现：  
void CCrpFileOpavDlg::OnFileProcess(WPARAM wParam, LPARAM lParam)
{
.......
}

或者更过分一些，直接指定为实际参数类型 :

在头文件中声明：  
afx_msg void OnFileProcess(LPCTSTR lpszMessage, int nPercent);

在源文件中实现：  
void CCrpFileOpavDlg::OnFileProcess(LPCTSTR lpszMessage, int nPercent)
{
.......
}

旧版本的 ON_MESSAGE 使用了 C 类型的强制转换，宏解开后的代码后不会产生错误信息，但是改成对类型检查很严格的 static_cast  操作符时就出问题了，因为通不过 static_cast  操作符的检查。解决方法就是修改代码，同时吸取教训，普遍使用的方法并不一定就能约定俗成，一切还是要按照规矩来。  

     错误现象之三：  

f:\project\.....\WzButton.cpp(74) : error C2440: 'static_cast' : cannot convert from 'UINT (__thiscall CWzButton::* )(CPoint)' to 'LRESULT (__thiscall CWnd::* )(CPoint)'
        Cast from base to derived requires dynamic_cast or static_cast

     出现这个错误的原因可是 “ 人力不可抗拒 ” 之原因造成的，因为旧版本的  ON_WM_NCHITTEST  宏使用了  
UINT (__thiscall CWzButton::* )(CPoint);
类型的类成员函数指针，其定义如下：  

#define ON_WM_NCHITTEST() \
    { WM_NCHITTEST, 0, 0, 0, AfxSig_wp, \
        (AFX_PMSG)(AFX_PMSGW)(UINT (AFX_MSG_CALL CWnd::*)(CPoint))&OnNcHitTest },

但是新版本变成了：  

#define ON_WM_NCHITTEST() \
    { WM_NCHITTEST, 0, 0, 0, AfxSig_l_p, \
        (AFX_PMSG)(AFX_PMSGW) \
        (static_cast< LRESULT (AFX_MSG_CALL CWnd::*)(CPoint) > (&ThisClass :: OnNcHitTest)) },

注意返回值类型由 UINT 改成了 LRESULT ，再加上 static_cast 的严格检查，所以就出错了。修改的方法就是将你的 OnNcHitTest 函数由：  

afx_msg UINT OnNcHitTest(CPoint point);

改成：  

afx_msg LRESULT OnNcHitTest(CPoint point);

不必太在意，这个不是你的错，不过，如果你要维护一个老的界面库（通常很多控件的 subclass 都会用到 ON_WM_NCHITTEST ），改起来还是很痛苦地，不扯了，继续下一个。  

七、 statreg.cpp  和  atlimpl.cpp  的废弃（ obsolete ）问题  

     在编译老的 ATL 向导生成的代码时，会遇到下面的编译输出：  

StdAfx.cpp
statreg.cpp is obsolete. Please remove it from your project.
atlimpl.cpp is obsolete. Please remove it from your project.

因为老的 ATL 向导生成的代码通常在 stdafx.cpp 文件中添加以下代码：  

#ifdef _ATL_STATIC_REGISTRY
#include <statreg.h>
#include <statreg.cpp>
#endif

#include <atlimpl.cpp>

根据提示删除 #include <statreg.cpp> 和 #include <atlimpl.cpp> 两行代码就行了，不过更好的办法是这样改：  

#ifdef _ATL_STATIC_REGISTRY
#include <statreg.h>
#if _MSC_VER <= 1200 // MFC 6.0 or earlier
#include <statreg.cpp>
#endif
#endif

#if _MSC_VER <= 1200 // MFC 6.0 or earlier
#include <atlimpl.cpp>
#endif

八、新的 C++ 编译器不再支持默认类型的变量定义  

错误现象是：  

f:\project\.....\WzCheckBox.cpp(464) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

产生这个错误的原因是程序中出现了这样的代码：  

const some_const_var = 10;

或  

static some_static_bool = FALSE;

新的 C++ 编译器严格按照 C++ 标准，不再支持默认类型的变量定义方式，必须严格指定变量类型，如下使用：  

const int some_const_var = 10;

或  

static BOOL some_static_bool = FALSE;

九、 for  语句的变量作用域问题  

     考察下面的代码：  

for(int i = 0; i < 120; i++)
{
    if(something_happen)
    {
         break;
    }
.............
}

if(i < 120)
{
    //something happen
}

在 VC6 的编译器中，这样的代码是没有问题的，因为 VC6 的编译器为了兼容旧的 Microsoft C/C++ 编译器，没有严格按照 C++ 标准执行，但是从 VC7 开始， VC 的编译器开始遵守 C++ 标准，所以就会出现 “ 变量 i 没有定义的错误 ” 。解决的方法也很简单，按照 Jim Hyslop  和  Herb Sutter 的经典对话系列的第四篇中的方法，改成如下就可以了：  
int i;
for(i = 0; i < 120; i++)

十、字符串函数的返回值问题  

    strchr(_tcschr) 、 strpbrk(_tcspbrk ??) 、 strrchr(_tcsrchr) 和 strstr(_tcsstr) 这四个函数在 VC6 的 CRT 库中定义的返回值都是 char *(TCHAR *) ，所以以前的代码通常是这样使用的：  

TCHAR *cp = _tcschr( pszPath, _T('\\') );
// 使用 *cp ，可以通过 cp 指针修改 pszPath 的内容  

这其实是一个 “ 漏洞 ” ，因为如果 pszPath 是 const char(TCHAR) * 字符串，那么就表示它不希望修改字符串的内容，但是调用 strchr(_tcschr) 函数后就可以通过 cp 指针修改其内容了，这岂不荒谬？所有在新版本的 CRT 库中，这几个函数的返回值都改成 const char * ，这就会导致上面的代码产生编译错误。建议的修改方式是改成如下方式：  

const TCHAR *cp = _tcschr( pszPath, _T('\\') );
// 不能再通过 cp 指针修改 pszPath 的内容  

但是这样修改可能对代码的影响比较大，比如下面的代码：  
TCHAR buf[256]; // 局部缓冲区  
......
TCHAR *cp = _tcschr( buf, _T('\\') );
// 作为局部缓冲区（非 const ），希望通过 cp 修改 buf 的内容  

这种情况怎么办呢？对了， C++ 还有个 const_cast 操作符，这时就可以排上用场了：  

TCHAR *cp = const_char<TCHAR *>(_tcschr( buf, _T('\\') ));

不过上面的方法要慎用，除非确定 buf 是非 const 的，否则最好老老实实地修改代码。  

十一、类成员函数指针做为函数参数的 “C3867” 错误  

     考察下面的代码， CWzWindowsHook 类的构造函数使用一个该类的成员函数指针，这样构造对象时可以选择消息过滤的 handler ，可以是 MouseMsgFilter ，也可以是 KeyboardMsgFilter ：  

typedef  BOOL (CWzWindowsHook::*FILTERPROC)(WPARAM wParam, LPARAM lParam);

// A hook used in customization sheet to filter keyboard/mouse events
class CWzWindowsHook
{
private:
    FILTERPROC m_pFilter;
    BOOL MouseMsgFilter(WPARAM wParam, LPARAM lParam);
    BOOL KeyboardMsgFilter(WPARAM wParam, LPARAM lParam);
public:
    CWzWindowsHook(FILTERPROC pFilter) : m_pFilter(pFilter)
旧的遗留代码存在这样的用法：  

CWzWindowsHook mouseHooker(CWzWindowsHook::MouseMsgFilter);

在 VC6 的编译器下编译可能没有问题，但是在 VC9 的编译器下编译会有如下报错：  

f:\project\.....\WzWindowsHook.cpp(272) : error C3867: 'CWzWindowsHook::MouseMsgFilter': function call missing argument list; use '&CWzWindowsHook::MouseMsgFilter' to create a pointer to member

虽然 C++ 从 C 继承来了函数名即是函数地址的语法规则，但是根据 C++ 的标准，类成员函数的指针仍然需要一个取地址符 “&” 。解决方法很简单，按照提示改成如下代码即可：  

CWzWindowsHook mouseHooker(&CWzWindowsHook::MouseMsgFilter);
十二、 wchar_t * 类型与 USHORT * 的转换错误  

    VC6 的编译器不支持 wchar_t 数据类型， wchar_t 实际上被定义成 unsigned short ， VC9 的编译器已经支持 wchar_t 为内置数据类型，但是由一个编译选项控制，这个选项默认是打开的，也就是将 wchar_t 作为编译器的内置数据类型。但是 OLECHAR 和 WCHAR 的定义仍然是 unsigned short ，在 VC6 的编译环境中，两者的指针都是 USHORT * ，相互赋值和做为函数参数传递没有问题，但是如果 wchar_t 作为编译器的内置数据类型，那就意味着 wchar_t * 与 OLECHAR * 或 WCHAR * 是两种不同类型的指针，相互赋值就会报编译错误，下面的信息就是一个典型的错误输出：  

f:\project\.....\shellpidl.cpp(290) : error C2664: 'MultiByteToWideChar' : cannot convert parameter 5 from 'USHORT *' to 'LPWSTR'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

解决的方法就是使用 C++ 的 reinterpret_cast 操作符或使用 C-style 强制转换，当然也可以在项目属性设置中关闭前面提到的那个选项（这个偶美试过，不知道会不会有其它问题）。