I have recently found myself working on a C++ MFC application written in MSVC 6.0 . After my initial despair about not being able to port it to VS2012, due to some legal issues – it is based on a third party product, and whilst we have the source code, and the changes required to get it to compile are minor we are required to engage the third party to make ANY code changes to their source code.
Anyway, I though the least I could do was upgrade the compiler to VS6SP6. This was mostly painless, just a few small code changes.
The most interesting compiler bug that was uncovered is illustrated below:
class foo
{
public:
foo() {}
static void bar();
protected:
bool m_var;
};
void foo::bar()
{
char * message;
message = m_var ? "foo" : "bar";
printf( message );
}
public:
foo() {}
static void bar();
protected:
bool m_var;
};
void foo::bar()
{
char * message;
message = m_var ? "foo" : "bar";
printf( message );
}
Note that a static function is able to reference an instance variable of a class so the above code should not compile... in fact, in this case it only compiles when used with the ternary operator - ? as
if( m_var )
printf("foo");
else
printf("bar");
produces the compiler error. This bug was fixed in one of the service packs.
Anyway, after upgrading my machine to VS6SP6 I found that I would encounter COM registration errors with DEBUG code built on other machines without SP6... and bizarrely even code built with SP6. Code built on my machine was okay.
These errors manifested as debug asserts such as:
"File: Ctlreg.cpp Line:520"
"File: Olecli3.cpp Line:502”
"File: Olelink.cpp Line:288”
"File: Olelink.cpp Line:291”
As the code was written to link dynamically with MFC and the c runtime library – I suspected I was in DLL hell- I had the wrong versions of some obscure dll. The best way to diagnose this is with dependency walker –also known as depends.exe. This will load an executable or dll and tell you exactly what other dll files it depends on.
In this case I found:
MFC42D.DLL
MFCO42D.DLL
MFCD42D.DLL
MSVCP60D.DLL
MSVCRTD.DLL
When I replaced these DLLs with versions from machines without the problem, the problem resolved on my machine. The question was, which DLL was the culprit? I was suspicious of the MFC dlls, as the asserts were in MFC code. It turned out to be MFCO42D.dll – the version on my machine was dated 1998 version 6.0.8168.0. The SP6 version was dated 2004 and had version 6.0.9782.0.
For some reason, VS6SP6 failed to update this DLL when installed on my machine.
Anyway, the upshot is that the MFC debug DLLs are NOT binary compatible between versions of the compiler.
Anyway, the upshot is that the MFC debug DLLs are NOT binary compatible between versions of the compiler.
Plenty of people have stumbled across this problem in my google searches, so I thought I would post this for the next person! Hope it helps you
