[geeks] Win32 malloc/free internals, and a unix question.

[Joshua D Boyd]

On Thu, Aug 08, 2002 at 05:42:16PM -0400, Tom Borton wrote:
> Here's the link to the article Joshua was refering to, I think.  He's free to
> correct me, of course.
> http://www.wd-mag.com/articles/2000/0004/0004c/0004c.htm?topic=articles

That looks like the article I was referring to.
 
> The gist is basically that, since the .DLL is linked independently of
> the executable, there is absolutely guarantee that the .DLL gets

Don't you mean "absolutely no guarantee"?

> linked against the same library - be it static or dynamic - as any
> executable that might choose to link to the .DLL.  If the application
> is statically linked, fuhgetaboutit, unless the debug symbols were
> included so that the .DLL could look for the right function.  If they
> both use the same dynamically linked malloc, you're fine, but
> otherwise you're in serious trouble. 

Well, it doesn't say anything about malloc and new using different
mallocs, so I must have remembered that part incorrectly.  But otherwise,
what I said pretty much agrees with that article.  Which is good because
it means my memory from reading the article is decent.  However, the
other thing I forgot is that when using the exact same compiler for both
DLL and executable, and the exact same malloc does mean that things will
work correctly because the compiler makes two copies of the malloc
function, and they will probably have different internal variables.

The short of it is, when writing Win32 C programs, use the DLL to free
the resources it gave you.  And hope that the DLL writer isn't doing
anything naughty with resources you hand it.  And it also points out
other things that can be done to prevent problems.  But nothing is a
panacea. 

So, uhm, how does the Unix world keep this from being a problem?  Is it
just buy all applications calling the C runtime rather than having their
own malloc/free?



-- 
Joshua D. Boyd