In September-October 2006 i went through the process of getting the VTP software to build and run with VC8, also known as "Microsoft Visual C++ Studio 2005 [Express] Edition 8.0". Here are some of the steps.
My assumption (my hope) was that it should be possible to build just the VTP code with VC8, and use all the dependency library binaries as-is, even though they are built with older compiler versions. As it turns out, that isn't quite possible..
I created a separate set of .vcproj files, by copying the VC7 files, renaming them with "-vc8" in their filename, and letting VC8 convert them.
It built well, until link time. Many link errors
involving methods with wchar_t parameters. It turns
out that VC8 changed wchar_t to a built-in type, which
links differently. To make VC8's output backward-compatible, you need
to set "Project Settings: C/C++: Language: Treat wchar_t as built-in
type: No".
Next link errors involved some of the Win32 standard libraries. Perhaps because i'm using the "free" Express Edition, these libraries were not included by default. It was a simple matter of consulting MSDN to find the names of the Win32 libraries used by each missing function, e.g. Advapi32.lib User32.lib Gdi32.lib, and adding them to the Link Input.
Next link errors involved a method with a
time_t argument. It used to be 32-bit, now in VC8 it's 64-bit.
To make VC8's output backward-compatible, i set the _USE_32BIT_TIME_T
preprocessor definition.
It was also useful to set the _CRT_SECURE_NO_DEPRECATE preprocessor definition to turn off all those obnoxious errors about "security" which tell you to "fix" your code by using non-portable Microsoft extensions.
I found that one dependent library, ZipArchive, caused lots of difficult link errors. Rather than try to fix them, i found a much smaller, simpler zip library called unzip which had no trouble working with VC8, and switched to using it instead.
By this point, VTBuilder actually builds and runs (almost) successfully. A crash on startup was traced to the zlib library, specifically the gzdopen function, which uses a file descriptor (with C standard library function fdopen). File descriptors are (apparently) not compatible between the VC7.1 and VC8 runtime libraries. I solved the problem by creating a set of zlib .lib/.dll files which are built with VC8, and linking with those. Now, VTBuilder runs! On to the 3D applications..
I tried wxSimple, which is built with vtosg and OSG. It builds and runs, then rapidly encounters a crash, traced to vtImage::Create. vtImage is a subclass of osg::Image (via multiple inheritance), yet after calling osg::Image::allocateImage, the VC8 debugger shows very different values when looking at the object as a vtImage, vs. looking at it as an osg::Image. This strongly indicates binary incompatibility. Hence, i now suspect that OSG needs to be completely re-built with VC8.
I finally determined that is was essential to re-build
all the following libraries with VC8:
OSG, wxWidgets, zlib
With those rebuilt, i was able to revert the wchar_t
option to the VC8 default (undoing steps 2 and 4 above), and link and run cleanly.
The "Express" version of VC8 does not include MFC, so i was not able to test BExtractor, mfcEnviro, or mfcSimple.
After all this, i built a new installer, hoping the MSVC
distributable runtime DLLs are as simple as before.
With VC7.1, it needs the following DLLS:
msvcp71.dll, msvcr71.dll
I hoped it is as simple as replacing them with VC8 equivalents:
msvcp80.dll, msvcr80.dll
Sent the installer out to users for testing. Result: It does not work. With the tragic introduction of 'manifests' in VC8, the process of an application finding its common runtime DLL is far more complex and likely to fail. The only semi-reliable way is to run the installer VC 2005 SP1 Redistributable Package on the target machine.