If so are there any good pointers on potential problems.

Thanks for any help you can offer

You shouldn't run into any problems other than new options if you
choose to take them.

Phil

1. The C++ compiler in VS2003 is much more standards-compliant and so
less forgiving of errors in C++ syntax than VC6. In fact, there are
places in which VC6 only accepts incorrect syntax and VC7.1/VS2003
only accepts correct syntax. There aren't many of these, but don't be
surprised if you have to correct a little code because VC7.1 picks up
errors that VC6 didn't.

2. The implementation of some standard classes has changed. In
particular the MFC CString class now uses the ATL CString definition.
This means that some ATL headers will be included in places that they
weren't before, and that can lead to symbol name clashes.

Also, CString implementation in VC6 used a Copy-On-Write mechanism to
avoid storing multiple copies of identical strings. COW causes
problems in multithreaded code, and so is not used in the new
CString. That can lead to an increase in memory use (on the other
hand the new CString uses the small string optimization, so may be
more efficient when storing many small strings).

To get the benefit of /RTC1 or /GZ runtime checking, link with the VC7
version of RunTmChk.lib.  Call _RTC_Initialize() and _RTC_Terminate.  (Use
lib.exe to remove the duplicate symbol __except_handler3 that clashes with
msvcrt.dll.)  You also need the VC7 version of delayimp.lib.

To get the benefit of VC7 stack overrun and buffer-overflow detection, add a
stub for __security_check_cookie.

With these changes you can write MFC apps using Visual Studio.NET that link
with the built-in MFC42.DLL.  You do not need to ship the bulky
MFC71xx.DLLs.

Phil

You won't be able to use the 64-bit compiler bundled with the PSDK on your
32-bit apps.  But you can use Visual Studio 2005's 32-bit compiler with the
new PSDK.  Just point Visual Studio IDE's INCLUDE folders at the PSSDK
folders: include\mfc, include\atl, and include\crt.   Point the LIB folder
to your original VC6 installation.  Now you can compile with Visual Studio
2005 and link correctly with MFC42.LIB and MSVCRT.LIB while enjoying all the
new IDE goodies and security checking.  (You still need the VS 2005 version
of RunTmChk.lib and sehprolg.obj, and write the __security_check_cookie
stub.)

Using the old libraries is especially handy when building lightweight ATL
ActiveX controls that download with minimal size.  Visual Studio 2005
normally requires you bundle several megabytes of DLLs with your application
(MFC80.DLL, MSVCR80.dll, MSVCP80.DLL, etc).  In contrast
MFC42.DLL/MSVCRT.DLL version 6 have been ubiquitious and stable since at
least Windows 2000 SP2 and Windows 98 SE.

This way you can enjoy the benefits of the newer compiler technology while
keeping your application small.  I recompiled over 100000 lines of legacy
MFC code from VC6 and it worked flawlessly.  In fact the new optimizer with
/W4 caught several latent bugs that were lurking in the code previously.

Regards,
Alan Klietz
Algin Technology LLC
alank-at-algintech-NOSPAM-dot-com