[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GnuTLS for W32

From: Óscar Fuentes
Subject: Re: GnuTLS for W32
Date: Wed, 04 Jan 2012 23:34:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

> You are describing a situation that existed on Windows 9X, it no
> longer exists on modern machines.  DLLs are either versioned in their
> names or use the SxS mechanism.

Before putting too much hope into SxS I encourage you to read the
wikipedia page about it that you linked on a previous post.

> Take the GnuTLS example: the previous DLL of version 2.x was named
> libgnutls-26.dll, while the new 3.x one is libgnutls-28.dll.

The 3.x version is named -28 ?

> Use your friendly depends.exe program, and you will see that programs
> that depend on one of them (were linked with its import library) will
> refuse to load the other.  The same is true of libintl, libiconv, and
> all the other libraries many Windows ports of GNU software need.

Appending a number to a name doesn't solve the problem.

> Poof! the problem doesn't exist.

A simple experiment: put a libgnutls-26.dll on the system32
directory. It is shared, right? Now install cygwin or msys, or any of
multiple standalone applications which are cygwin-based, and put its
binary directory before system32 on PATH. See it?

Another experiment: build an application such as Emacs with VC++ 6 or
MinGW with the default settings. Now make it to use a dll (GnuTLS, an
image library...)  compiled with a modern release of VS. Unless such
library follows a very strict policy about resource handling (and
possibly other aspects) you are asking for problems. I'm sure that I
don't need to explain the dangers of mixing different major versions of
the C runtime library.

Think on a user that discovers that sending mail with Emacs just works
because some other package installed GnuTLS on some directory listed on
PATH. Time later he decides to uninstall the application and afterwards
tries to send an e-mail, just to notice to his dismay that it doesn't
work anymore. Confusing, isn't it?

And then there is the issue with security fixes... If Emacs enters the
bussiness of secure protocols provide a mechanism for notifying the user
about updates, and make the upate process a no-brainer. Do you think it
is serious to let the user with a broken GnuTLS for years? Either take
full responsability or dismiss it completely: "Emacs supports StartTLS
through GnuTLS. The library usually can be downloaded <here>. Such
library is not part of Emacs and no effort is made related to checking
its suitability, correctness, etc."

> Please stop spreading this FUD, you are tripping people like Ted who
> don't know better into wrong conclusions based on what hurt you (and
> me) several years ago.  THERE'S NO SUCH PROBLEM ANYMORE!

Please stop using inflamatory language and offensive assertions. I could
say that your real-world experience distributing, installing and
supporting software across heterogenous environments looks quite
limited, but I'll rather suppose that you were very lucky so far.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]