Converting VC++6/Win32 project to VS2010 C++/Win32 project: Known issues

Do you know of any resources highlighting known or possible issues during conv开发者_如何学编程ersion of a VC++6/Win32 project to VS2010 C++/Win32 project type? I'm interested in all kinds of issues:

• Compiler options compatibility
• Compile-time issues
• Link-time issues
• Runtime issues
• MFC issues

Otherwise, if you already performed that kind of migration, what issues have you encountered?

Thank you

---

VC++6 has non-standard exception handling. We hit a few problems because our code contain this:

try { 
  //Some code
} 
catch (...) {
  //Handle error
}

Some developers had relied on this broken behaviour and our application crash badly after being compiled in VS2008.

This article explains it well and how to solve the issue.

---

1. First of all, these issues are highly dependent on code quality and how the ancient code has been adapted to fit the VC++6 compiler's "features".

2. It's not possible to convert .dsp to the VS 2010 format directly (at least with the express editions), you'll have to pass through 2008 to be able to convert.

3. The conversion wizards should warn and inform you of any issues there might be. I haven't been through this process, but I would think compiler switches are the least of your worries. In general, I would expect bad code to produce a lot more errors you need to worry about instead.

As to your specific queries:

• See 3.
• VS2010 will take longer.
• VS2010 linker will take longer, especially if you enable link-time optimization (introduced in VS 2005)
• only if you made non-standard assumptions or if VC++6 has non-standard functions. As long as you recompile the complete project with VS2010 (and thus link it to the latest VC(++) runtime), no runtime issues should occur.

sidenote: I'm not saying the old code is bad, just that a lot of questions on SO regarding VC++6 are caused by bad code quality/conformance.

---

Heh, vs6 allowed you to use loop variables outside the scope of the loop. ie:

for ( int i=0; i<10; i++ )
{
   if( i == 5 )
     break;
}

int iVal = i;

This will fail in anything > vs6 :) fails in 2005 and 2010 - although there is a compiler setting that will allow you to force this behavior again (I would suggest just fixing it, don't force it, its noncompliant anyhow), at least in vs2005. I haven't made the dive to 2010 yet, as I do a lot of embedded development, and it seems switching compilers for the embedded stuff is usually a major pain. So, I can't say too much for 2010, but I know that carries through!

---

Did the move, two painful issues I'm aware of:
- The exception handling default was changed between VC6 and later versions. I believe /Eh was the default and that has changed.
- VC6 runtime (msvcrt DLL) is included in any Windows OS since Win2k, while for any other version you need to install it with your software for almost any OS.

---

You will have a lot of problems because VC6 was notoriously non-conformant, and your code (especially if you used templates) will likely be full of hacks to make it work that no longer are necessary, as MS did a lot of conformance work for more recent compiler versions, and the VC10 compiler will probably barf on them.

---

If you have a commercial edition of Visual C++:

Find devenv within your Visual C++ install directory (should be %VS90COMNTOOLS%\..\IDE\devenv.exe

    > devenv /upgrade project.sln

    > msbuild.exe project.sln  /t:Build  /p:Configuration=Release /p:Platform=Win32

Check the compilation

but If you have a free edition of Visual C++:

Find vcbuild.exe within your Visual C++ install directory (should be %PROGRAMFILES%\Microsoft Visual Studio 9.0\VC\vcpackages\vcbuild.exe)

    > vcbuild.exe /upgrade   project.sln
      /msbuild:Configuration=Release
      /msbuild:Platform=Win32

For future builds which don’t need conversion, type:

> msbuild.exe project.sln /t:Build /p:Configuration=Release /p:Platform=Win32

---

When moving from VS2005 to VS2010, we ran into a problem with a 3rd party library causing one of our programs to crash every time it was loaded. The problem turned out to be caused by Microsoft reversing the default setting for the /NXCOMPAT switch in the linker. That switch controls whether or not Data Execution Prevention (DEP) is enabled or not. Prior to VS2010, the default setting for that switch was NO and the DLL we were using apparently relied upon that setting to function correctly.

I'm not sure how far back the NXCOMPAT linker switch goes. It wasn't listed in any of the settings available in the VS2005 dialogs but it was listed when link /help was run from the command line. I've never been able to find a list of changes such as this from Microsoft, so this kind of bug is VERY tricky to track down.

---

If you're migrating from VC++ 6 to VS2015 with CLR, existing min and max functions are no longer found, add

#define NOMINMAX
#include <algorithm>
namespace Gdiplus
{
  using std::min;
  using std::max;
};

Secondly, NAN float changed to nan