DLL Hell

  • Thread starter Thread starter bikerider7
  • Start date Start date
B

bikerider7

Hello,
I have a .DLL compiled on VC++ 6.0 and is being linked into an
application built using 7.0. For reasons that are too stupid to go
into, migrating the .dll to 7.0 isn't possible for the time being.

On my development PC (Windows XP), the application runs fine; i.e.
the DLL calls work great. But when we copy the application over to
any other PC (also running Windows XP), it crashes whenever a DLL call
is made. It seems like calls to DLL library routines are going to a bad
address.

I've made sure that the .dll and .exe are in the same
directory, and we've run the app with the current directory set
to the app directory. I also went through to see if there were
any missing system DLL's on the other PC's but no such luck.
Is there something that I'm missing?
 
Only if you are extremely careful will you be able to make an application
consisting of objects built against different versions of the same C++
library work. For C libraries it is somewhat more possible, but you still
need to be very careful. E.g. in the case of multiple versions of the C
runtime library, you need to be aware that you now have different memory
allocators so you can't pass something allocated in the dll and free it in
its client, nor can you pass any global handles (like for I/O) across the
boundary and expect it to work.

As to why it works on one machine and not on another is somewhat hard to
guess at. Seeing whether all the dependencies are exactly the same versions
could be a start, but unless the code obeys the rules above (and another
whole set of related ones) it probably is more an academic exercise than
something that will ever work reliably.

Ronald Laeremans
Visual C++ team
 
Ronald Laeremans said:
Only if you are extremely careful will you be able to make an application
consisting of objects built against different versions of the same C++
library work. For C libraries it is somewhat more possible, but you still
need to be very careful. E.g. in the case of multiple versions of the C
runtime library, you need to be aware that you now have different memory
allocators so you can't pass something allocated in the dll and free it in
its client, nor can you pass any global handles (like for I/O) across the
boundary and expect it to work.
Click to expand...

Yes, I'm aware of the restrictions on microsoft shared libraries.
However, the DLL in question did not rely on standard C memory allocators,
etc. so this was not an issue.

And in any case, we just spent 2 days porting most of the DLL to 7.0 and
are still seeing the same problem. So the problem is not due to
mismatching compilers. Indeed, as a test I had the App call
this very simple DLL routine immediately in main:

BOOL DllLib::Test() { return TRUE; }

and it crashes (except on my PC which still runs fine). As long
as we don't make calls to the DLL, everything runs fine, but
that is obviously not an option....
 
Using a debugger to try and step through the call looks like the sanest bet
to me. That is after verifying that you are loading the same version of
everything with a tool like depends.

Ronald
 
Back
Top