Yang Tse wrote:
> 2007/3/15, Jonathan Arnold wrote:
>
>> Yes, there is no doubt that mixing and matching MS C runtimes is a
>> recipe for
>> disaster. But that doesn't really have anything to do with *using* a
>> DLL, as
>> long as its C runtime is the same. In fact, it has to be the same. So
>> if my
>> program uses static libs, I must have a DLL that uses static libs.
>> Again, just
>> because I want to use curl as a DLL doesn't mean that my entire app
>> needs to
>> be dynamic (we ran into a similar problem on Mac OSX, trying to not
>> require
>> dynamic libraries to be delivered).
>
> If you build a DLL named first.dll with the static MS C runtime, the
> static MS C runtime library gets linked _into_ the DLL This might even
> be the desired thing if you don't want or cannot provide the dynamic
> MS C runtime libraries.
>
> If you build another DLL named second.dll with the static MS C
> runtime, the static MS C runtime library also gets linked _into_ the
> second DLL.
>
> 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.
>
> 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.
>
> On the other hand, if you have full control of which libraries are
> used with your program you might chose to violate some rules, after
> all its your responsibility. But watch out, with DLLs having full
> control means that you build all of them, and that you build them with
> names that don't match DLL names that could be found in the wild,
> otherwise you are in big trouble.
>
> libcurl is not an inshop library, it is more like third.dll mentioned
> above.

But anyone who would assume that a DLL would be able to free up a pointer
that you've alloc'd would be crazy anyway. And while sharing stream buffer
pointers isn't beyond the realm of sanity, it's approaching the country line
for sure. Someone who is writing a simple app using libcurl might want to
keep it as a DLL without shipping the entire MS runtime DLLs.

So basically I don't think it is necessarily encouraging bad practices and
there are some very compelling reasons for having a staticaly linked DLL. There
could even been a warning in the README, but as libcurl doesn't free up
pointers and doesn't share the errno and doesn't really work very well in
a Windows app with FILE pointers anyway, I don't see the problem. There are
reasons to do it, very good ones IMHO, and curl shouln't be putting roadblocks
in the way.

>> That's why, for ease of use, there needs to be 8 targets. The OpenSSL
>> folks deliver
>> 8 libraries too, so you can create all the versions of the DLL you
>> might want
>> to use
>
> 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.
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;94248

Well, I guess we'll just have to agree to disagree. Using mismatched runtime
linking is a more certain death than using static linked DLLs in my opinion. And
forcing a particular linking scheme on someone also isn't very friendly.

-- 
Jonathan Arnold           Software Engineer
inSORS Integrated Communications, Inc
jarnold_at_insors.com Office/fax: 781.391.2818