Jamie Lokier wrote:
> > 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.

Having just read this excellent FAQ, I'm changing my mind again:

    http://www.zlib.net/DLL_FAQ.txt

The section on Visual C++ >= 7.0 and .NET is especially interesting:
the zlib folks recommend _not using_ the distributed zlib DLL with
Visual C++ 7.0 and later, due to clashes of run-time C libraries.
That is, unless the application is linked with Visual C++ 6.0
libraries, which would be unusual if you have the 7.0 compiler.

I'm beginning to understand what is meant by "dll hell"...

-- Jamie
Received on 2007-03-16