Wireshark-dev: Re: [Wireshark-dev] Microsoft Visual C Version 6 support is a bitoutdated ...
From: Ulf Lamping <[email protected]>
Date: Wed, 20 Dec 2006 11:31:13 +0100
Douglas Pratley wrote:
We went through upgrades from MSCV 6 -> 7.1 -> 8 in my last job. The
only real problem we ran into (apart from all the code tweaks in the C++
to make it compile 6 -> 7.1, which is not relevant here) was in passing
dynamically allocated memory across binary boundaries.
What do you mean by binary boundaries? DLLs I guess?

This should only be a problem if you alloc some memory in one DLL and free it in another (which is often a "hint" for a bad design anyway) - I would think that WS already do it that way (there might be some places left over to cleanup in this regard).
AFAIK, given the limitation from above, you can USE that memory in any 
DLL instances of the program you like.
If everyone has followed the guidelines and used the "g_" functions for
allocation and deallocation, then all memory should be being allocated
from one CRT, so it may well just all "work". Would it be worth checking
the code to make sure that it doesn't use other allocation functions
anywhere?
There are three mechanisms I know of:
- g_... throughout the "main" WS code
- emem uses g_ and VirtualAlloc
- some (generated?) dissectors uses malloc (at least a MSVC warning of a missing declaration seems to indicate this)
All WS code will hopefully free the memory in the way it was alloced, so 
this shouldn't be such a big problem.
Of course, any bugs that occur if it doesn't just work will be
intermittent, awkward to find and fatal (or a security risk) if they do
occur...
There's one thing even more annoying: FILE "handles" are not "portable" across DLL's as the CRT keeps some "private" information about the files state, which is not "spreaded" between different CRTs.
This was already discussed before on the list, maybe there are other CRT 
things to think about - the zlib is the biggest problem here.
Fortunately, if we use the GLib stuff everywhere, "only" the remaining 
native C runtime calls have to be thought about ;-)
Regards, ULFL