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
