VC6转VS2008

首先可以直接用 Visual Studio 2008的打开 VC6的工作区文件和项目文件(dsw 和 dsp)，并将其升级为 VS2008的解决方案格式和项目格式(sln 和 vcproj)，VC9的编译器相对于 VC6有了很大的变化，一些编译参 数和链接参数被废弃(比如/map:line)，有一些改变了名称,还有新增的选项，不过不用担心，升级过程会自 动对其进行转换，最终都会得到一个正确的解决方案和 VC 项目文件，这个过程不会遇到太多的麻烦，问 题都出在随后的编译过程中，下面就将我在移植的过程中遇到的问题和我的解决 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 总结一下，希望对还 在用 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++的 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 ，所以 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 : '' 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 : '' 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 #include #endif #include 根据提示删除#include 和#include 两行代码就行了，不过更好的办法是这样改： #ifdef _ATL_STATIC_REGISTRY #include #if _MSC_VER <= 1200 // MFC 6.0 or earlier #include #endif #endif #if _MSC_VER <= 1200 // MFC 6.0 or earlier #include #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) *字符串，那么就 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 示它不希望修改字符 串的内容，但是调用 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(_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 强制转换，当然也可以在项目属性设 置中关闭前面提到的那个选项(这个偶美试过，不知道会不会有其它问题)。