从VC6到VC9移植代码问题总结

从VC6到VC9移植代码问题总结 
    当年在学校学习C编程的时候用的是TC2.0，后来学C++用TC3.0，有一天突然发现Borland C++ 3.1的IDE比较好用，于是改用BC31，然后是BC4，但是到了BC5(还有BC5.02)的时候就玩不下去了，因为我那台只有16M内存的P100实在是跑不动这个庞然大物，在OWL和MFC之间“痛苦地”抉择了一部电影的时间后，我决定放弃添加内存的计划，改用Visual C++试试。因为当时内存太贵了，不过电影很好看，我还记得名字是《西域雄狮》，讲的是黄飞鸿到北美开宝之林分号的故事，还收了一个洋徒。。。你看这思维跳跃的，打住，说正事儿吧。看完电影后装了一个Visual C++ 4.2，这Microsoft的东西就是争气，在我的破机器上跑得马溜的快，于是就用买内存的预算买了一本《Visual C++ 4.0从入门到精通》，那个时候的出版社就是效率低，这本书已经是所有关于VC的书中最新的了，好像还看到一本《Visual C++ 1.5-2.x 使用指南》，什么年代的事情了，还摆在书架上。哪像现在的出版社，简直就是“与时俱进”的典范，Microsoft那边 《Windows 7》 刚发布了个预览版，这边《下一代xxx揭密》就已经上架了，唉，又扯远了，打住。没多久VC5就出来了，好在这两个版本的用户界面变化不大（MFC的版本稳定在4.2），我就在《Visual C++ 4.0从入门到精通》这本书的指导下“精通”了VC5。1998年的时候Visual C++ 6.0推出了，但是我一直坚持用VC5，1999年我毕业设计还是选择用VC5，不为别的，就是因为当时盗版的VC6都没有帮助文件，就是缺少MSDN，没有这个还怎么写代码？毕业设计完成之后我从朋友那里弄到了传说中的两张MSDN光盘，于是开始用VC6，从此以后，VC6就一直存在于所有我用过的电脑中，后来VC7（7.1），VC8出来以后，VC6的地位也一直没有动摇过，用C++开发软件我首选VC6，我还为VC6开发了一个文件标签栏插件Tabbar，可以通过标签栏在打开的代码文件之间快速切换，除此之外还具有很多其它功能，比如自动打包压缩项目代码。。。唉，又跑题了，打住。

    做人要与时俱进，这不，今年VC9也随着Visual Studio 2008发布了，再不赶上就真的老套了。说是这么说，不过心里还是有些余悸的，2006年的时候我曾经试图将我的一个工具软件的代码升级到VC8，但是我低估了新的编译器的兼容性（当年从VC5到VC6可是没有那么多麻烦），上来就是一大堆编译错误，警告就更是牛毛，当时因为急着为工具软件开发一个新功能，没有时间解决这些问题，只好放下了，这一放就是两年。我这个人喜欢自己做工具软件，目的是为了方便自己，以前用VC6，觉得在代码源文件之间切换很麻烦，但是WndTab太占用资源，于是就借鉴WndTab的部分代码自己做了个标签栏插件Tabbar，还把从CodeProject上看到的好的创意都添加进去，后来用Source Insight，觉得它没有文件标签栏太土，就给它做了个标签栏外挂（TabSiPlus），就这样几年下来竟然有几百兆的工具代码，这个移植的工作量可是非同小可，想着都怕怕呀！不过也没办法，这两年主要用GCC做嵌入式开发了，没有时间维护这些工具，自己在使用过程中累计下来的BUG和新需求也有一大堆，需要进行升级了，适逢这次机会将其移植到VC9到也是个不错的选择。其实程序员自己给自己写工具很有好处，比如我喜欢边写代码边听音乐，于是我就把自己写的MP3播放器集成到VC开发环境中，这样就可以象操作VC的其它功能一样选择音乐文件，还比如。。。又扯远了，回到正题，讲讲移植过程中遇到的问题。

    首先可以直接用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强制转换，当然也可以在项目属性设置中关闭前面提到的那个选项（这个偶美试过，不知道会不会有其它问题）。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/orbit/archive/2008/11/28/3405309.aspx