Yang Tse wrote:
> Now you build a program that uses the above first.dll and second.dll.
> Now you have a nice program which is granted to be using at least TWO
> _different_ copies of the static MS C runtime each of it with separate
> copies of all C Run-time functions and global variables.
>
> Among other things this means that if a buffer is allocated in
> first.dll the program will misbehave if you try to free the buffer in
> second.dll.

Correct.

> This is reason enough to mostly _NEVER_ build a DLL linked with the
> static MS C runtime.
>
> If we are speaking of a DLL, let's call it third.dll, of wide and
> uncontrolled distribution which might be used no one knows how and
> which might be used in a program which is using other DLLs the only
> safe way of building third.dll so that it does not misbehave is
> linking it at creation time with the MS dynamic C runtime, and not
> with the static one.

That isn't reliable. As the page you reference points out:

   http://support.microsoft.com/default.aspx?scid=kb;en-us;94248

there are _different_ MS dynamic C run-time libraries, CRTDLL.DLL and
MSVCRT.DLL (or MSVCRT10, MSVCRT20, MSVCRT40).

To share C library resources between third.dll and other DLLs and/or
the application, they have to all use the same run-time library.
Which one would it be? Some applications link with CRTDLL, some with
MSVCRT. Third party DLLs also vary. Nowadays most things link with
MSVCRT, but not all.

It seems to me the only _really_ safe way to compile third.dll on
Windows is to ensure that its API doesn't expose resources in a way
which could break.

That means not allocating buffers in third.dll which are freed
elsewhere, and vice versa. If the application needs to free a buffer
allocated by third.dll, it should call a function third_free() _in_
third.dll to free it. Similarly a function third_malloc().

Other things include not exposing file descriptors or FILE * handles,
as those are also C run-time library resources.

> They can do whatever they want. If something is wrong, it is wrong no
> matter who, when or where it is done. A Dll built with a static MS C
> runtime is just something that should be avoided by _ALL_ means in a
> library of wide use, uncontrolled distribution and free support.

I came to the opposite conclusion: for _maximum_ portability among
Windows versions, a DLL must be built either with static MS C run-time
(and threads enabled), or linked with CRTDLL.DLL(*), and provide APIs
for alloc/free and not expose file descriptors or handles. That's
because you cannot depend on the application, or other DLLs, using a
particular C run-time library, so you cannot assume allocating buffers
in one DLL can be safely freed in another.

(*) - if you don't mind failing to work on early Windows 95 versions,
or earlier Windows, link with MSVCRT.DLL instead.

-- Jamie
Received on 2007-03-16