Upgrading from Visual C++ v7.1 (VS 2003) to Visual C++ v9 (VS 2008)

March 14th, 2008 by admin

VC6

Our applications are written primarily in Visual C++. We started with Visual C++ 6.0 back in 1998 and used it successfully for many years.

VC7

There was quite a bit of disappointment among C++ developers with the release of Visual Studio .NET (VC7) in 2002 and VS .NET 2003 (VC7.1) the following year because of so much emphasis placed on the new .NET Framework and VB.NET and C# languages. But with some trepidation and a moderate amount of pain, we finally migrated to VC7.1 in mid-2005. Other than some quirks in the resource editor that we managed to work around, that version worked well for us (with the requisite additions of Visual Assist and Fast Solution Build add-ins). It brought much-needed improvements to standards compliance, some library improvements, and was fairly stable, although compilation was a little slower and the executables slightly larger than VC6.

VC8

In early 2007, we experimented with upgrading to Visual Studio 2005 (VC8) but ran into a lot of problems attempting to get everything to compile and link properly. Microsoft also made some changes to how LIB files are handled, and one third-party library we use did not offer a VC8-compatible library at the time, so we shelved the conversion.

With Microsoft readying the release of Visual Studio 2008 (VC9) and the availability of VC8-compatible third-party libraries, we decided it was time to attempt migrating one more time. We thought it would be easier to convert to VC8 first and then try VC9 after that, but boy did that turn out to be a poor assumption.

VC8 didn’t do a great job of converting our project and solution files, requiring manual correction (Build checkboxes in the Configuration Manager and dependencies getting dropped). We also ran into several compilation and linker issues to work through, including:

  • Several code changes were required to eliminate warning messages related to using the new safe CRT functions calls, etc.
  • Had to increase the compiler limits (/Zm) on some projects
  • Warning for non-standard extension used in qualified name for enums
  • Disabled manifest generation and embedding (since our executables already include a manifest)

    Thanks to Visual Build’s built-in support for all Visual Studio releases, updating our builds was painless (only needing to append ‘|Win32′ to the solution configuration names).

    Once we finally got everything to compile and link, we ran into several runtime problems and had to make some more changes, primarily:

  • Avoid referencing &elem[0] of empty vectors (it’s safe to pass that to memcpy with a length of 0, for instance, but VC8 aborts the program just by referencing the element)
  • Make changes to bring STL iterator code (which assumes they are pointers) into compliance

    Most problems were identified quickly and corrected in the debug build, but even with these changes, we ran into two show-stoppers:

  • Choosing one feature in one of our applications resulted in the app just disappearing, and this only occurred in the release build on a Windows 2000 box.
  • Command-line builds worked fine, but compiling almost any file in any project within the Visual Studio IDE resulted in the dreaded internal compiler error (ICE), which made development and debugging unbearable.

    VC9

    We were about to give up and stick with VC7.1, but as a last-ditch effort, we decided to try migrating everything to VC9. We encountered a few more compilation issues:

  • Some of our projects defined a minimum Windows version of NT 4 (_WIN32_WINNT 0×0400), which now resulted in compile errors, but changing this to Windows 2000 (0×0500) fixed that and is safe since our applications require Windows 2000 anyway
  • The 64-bit portability check compiler flag is deprecated so we removed that directive from the project files
  • MFC no longer handles including of afximpl.h very nicely, so we just copied the few lines of code we used from that file into our own sources and removed the include

    After these changes, low and behold, we found that everything worked just great! No more crashing of the compiler when building in the IDE, and no more problems running our application on Windows 2000. Our executables are larger still (about 10%), which is acceptable considering all the improvements that have been added to make the code more secure in our connected world.

    It’s apparent that Microsoft has really put significant effort into improving their C++ tool chain with this release of Visual Studio, and there are many great IDE improvements as well:

  • The debugger, especially peering into STL containers, has improved tremendously
  • The resource editor is improved and now handles high color bitmaps
  • VS/MSBuild now supports parallel builds on multi-core and multi-CPU systems (and builds do appear to be noticeably faster on such systems)
  • New features like testing, optimization, code snippets, and property manager capabilities
  • Easy backup, restore, and sharing of IDE settings

    One caveat that bit us: Visual Studio 2008 requires Windows XP or later, and our build boxes were all Windows 2000, so we had to reconstruct the build machines. There is also a quirk with the Visual Studio 2008 Standard edition installer — it doesn’t install cl.exe and some ancillary files unless you perform a full installation.

    Overall, it took longer than expected to complete the migration, but fortunately it turned out to be worthwhile in the end.

    • Posted in Power tools |

    Leave a Comment

    Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.