The DLL that is at issue here is the runtime,
because of the fact that it provides the heap management code. If everyone
doesn't share the same runtime, then they will be allocating from different
heaps. If they never pass any memory out of themselves, then it won't matter.
But, except for DLLs that are designed to be kind of black boxes, there is often
a desire to allocate something and return it back to the calling client code,
and let them be responsible for cleaning it up. In any kind of sane, modern C++
environment, then should be a no-brainer because its a completely natural thing
to do. Unfortunately, unless you understand the issues and do the right thing,
Win32 is not a sane, modern C++ environment.
Of
course, other issues could always possible arise, its just the heap management
issue that's the big one. But, for instance, if a runtime DLL assigned ids
to some resource, such as say files, and you got one of their file ids back, and
you then tried to close it from your code, the same issue would arise, because
you have two different versions of the DLL. In that case though, you'd be less
likely to catch it, because its quite reaosnable that the id would also
represent a valid file id in your runtime as well, and it would just silently
close the wrong file, and leave the other one open.
This
is just a generic issue that arises when you have the ability to load code
dynamically, and you load two different versions of it (which therefore causes
multiple versions of the DLL's static/global data to be created.) Dealing with
it requires careful thought, and would be helped if the OS and tools were
smarter. For instance, MS should have just started from the beginning on NT at
least with a single runtime, which was multi-threaded and DLL based. And if they
would provide a little more smarts wrt DLL management, which evidentally is
finally now planned for the next OS version, the versioning issues would be
dealt with much easier.
Also
of course, if we were all actually doing software *engineering*, as apposed to
desparately hacking to get stuff out the door, many of these issues wouldn't
arise either. But, unfortunately, that's the world we live in I guess.
Dynamically loadable code is a powerful tool, and like any powerful tool, it
works best if its use is well understood and planned. But its clear that many,
many people don't even know that there is a problem to be worried about, so they
never plan to deal with it at all, which is just one more reason why software is
in the state that its in.
But
I'm not cynical about it or anything :-)
--------------
Dean Roddey
Software Geek
Extraordinaire
Portal, Inc
[EMAIL PROTECTED]
-----Original Message-----
From: Jesse Pelton [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 20, 2001 5:31 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Deleting char* returned from DOMString.transcode() in VC++ 6. 0You appear to be doing The Right Thing, but if you're using other libraries, it's possible that one of them is bringing in the wrong runtime. Try using Depends.exe (http://www.dependencywalker.com/) to inspect the list of DLLs that your program will load.This raises a question for me. The runtime DLL issue has never come up for me, because we link statically. I just ran Depends.exe against our program, and discovered that ws2_32.dll brings in msvcrt.dll. As far as I'm aware, Xerces needs Winsock (at least in some circumstances), and I can't find a debug version of ws2_32. Would this cause problems for programs that link Xerces dynamically, at least in some cases? If so, what can be done about it?-----Original Message-----
From: Gary Marsh [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 19, 2001 4:55 PM
To: [EMAIL PROTECTED]
Subject: RE: Deleting char* returned from DOMString.transcode() in VC++ 6.0Jesse;This brings up a good question - Xerces' debug version generates a .dll and a .lib but in theVC++ "Setting options C/C++ tab; Code Generation; Use run-time library option" I selected"Debug Multithreaded DLL". Is this the correct selection or should it be "Debug Multithreaded"?Gary
