I kind of answered this in a long post I just made so see that one. But
basically, the deal is that yes, you can possibly have multiple versions of
the runtime installed. And, as long as everyone knows exactly what they are
doing, you can make it work. But, from our perspective, if we are trying to
help people who we aren't sure know exactly what they are doing, it helps to
know exactly what they've going going on. If the tool gives a hierarchical
kind of dump, it might even tell us that the other runtime was brought in by
some other DLL or by your exe, which could diagnose the problem. If it just
gives a raw list of DLLs loaded, then it might not help much if you
legitmately have some other DLL bringing in a different runtime.
Overall though, its best to have everyone share the same runtime. This gets
tricky wrt to the system DLLs, which you cannot have multiple versions of.
If any of those uses the non-debug runtime, and you are building all of your
stuff for debug, then there's little you can do. But, as long as all of your
stuff uses the debug runtime, then its safe enough and there's not much more
you can do anyway.
Another option is to not ever use the debug versions of the runtime, then
there isn't an issue. Instead, use third party debugging tools like
BoundChecker or Purify and be done with the whole issue. If you always build
everything to use the production runtime, then none of this comes up because
any other DLL that brings in a runtime is likely (actually it definitely
better) be bringing in the production versions. There is a difference
between building your code for debug, which is just a code and symbol
generation issue) and using the debug/production runtime, which is just the
selection of a version of that DLL with or without some error checking
turned on. You can very easily use the non-debug runtime when your code is
built for debug mode.
Personally, if MS would put in the effort, I think much of this could be
done away with. For one, at least on NT/2000, they should only have one
runtime, which is multithreaded/DLL. On a system of that type, there isn't
any excuse IMHO to do otherwise. Its a complex, multi-threaded and
multi-process machine, and we just don't need the extra complexity. And they
are putting some stuff into the next OS release which is well... not really
intended to fix the issues related to DLLs, but at least make it safer to
deal with when you have to do something hacky.
--------------
Dean Roddey
Software Geek Extraordinaire
Portal, Inc
[EMAIL PROTECTED]
-----Original Message-----
From: Jesse Pelton [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 20, 2001 9:45 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Deleting char* returned from DOMString.transcode() in VC++
6. 0
Yes. I'm trying to understand something that has come up in the past. Dean
has suggested that people should look at the list of DLLs brought in by
their program to see if the wrong runtime is getting brought in. (I just did
the same thing, but I'm trying to figure out whether that was helpful in
this case.) It seems to me that having two versions of the runtime shouldn't
be a problem as long as the code that frees the memory allocated by
transcode() is linked against the same version of the runtime as Xerces.
So, if my_processor.exe links against the debug version of Xerces and the
multithreaded debug DLL version of the runtime, everything should be cool,
even if (say) ws2_32.dll brings in the retail runtime.
If that's the case, I don't understand the usefulness of inspecting the list
of DLLs used (with Depends, chkmod32, or some other utility). I guess this
is really a question for Dean, in whose hallowed footsteps I blindly (that
is to say, ignorantly) trod. But if someone else can open my eyes, I'd be
equally grateful.
> Doesn't the problem only occur when memory is allocated in one runtime and
> freed by another? Many libraries intentionally force memory to be
> allocated and deallocated in the same place (either by the caller or the
> callee).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
