VC6到VS2008的变化

直接用VisualStudio 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) : fatalerror 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定义删除，这样就会使用PlarformSDK中的_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 functionor variable may be unsafe. Consider using strcpy_s instead. To disabledeprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
e:\software\microsoft visual studio 9.0\vc\include\string.h(74) : seedeclaration 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) : seedeclaration 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 thetarget 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' shouldnot 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格式的图像文件的嘛，于是赶快用dependslook了一下，顿时高喊：鬼啊～～～。原来这个depends竟然查不到导出函数的名字，后来才知道还有NONAME参数强制用顺序号定位导出函数，于是就常常弄个没有导出函数名字的DLL到处show。。。。嗯，又扯远了。话说为什么旧的系统要以此指定这四个导出函数的顺序号我就没有研究了，反正现在不需要指定了，只要将@1，@2之类的删除就行了，不过不删好像也没什么问题，它们会被自动忽略。

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

错误现象之一：

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

错误现象之二：
f:\project\.....\crpfileopavdlg.cpp(87) : error C2440: 'static_cast' : cannotconvert 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 convertfrom '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