Re: GnuTLS for W32

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Wed, 04 Jan 2012 23:34:50 +0100
> 
> 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.

Believe me, I have.  With today's PC ("on the one hand .... but on the
other hand") stance, you can no longer have articles with definitive
opinions.  Articles need to be "balanced", so they will dig any minor
problem to show "objectivity".  Building evidence on that is silly.

All I can say that "it works for me" on no less than 4 different XP
systems used for 4 different purposes, for 7 years, with not a single
problem that I can remember.

> > 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 ?

Yes.  The number comes from the build.  GnuTLS has some weird scheme
for numbering the releases, take a look at their configure script.
But that's not really relevant here.

> > 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.

It does solve most of it, because programs look only for DLLs they
were linked against.

> 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?

People who install both MinGW and MSYS/Cygwin on the same system have
a lot of rope to hang themselves, if they act stupidly.  Putting a
non-system DLL in system32 is one such stupid act; having MSYS on your
PATH is another.  MSYS installer has an option to stay away of PATH (I
think it's the default); if you read the installation instructions
carefully during installation, you won't get into this trouble.  I
know, because I have MSYS installed on one of my machines, and have no
trouble at all, although the amount of overlap in DLLs is
considerable.

In addition, MSYS names most (if not all) of its DLLs differently,
msys-FOO-NN.dll, which also alleviates this problem.

Finally, for the umpteenth time: the default should be to put the DLL
where emacs.exe lives.  Putting it elsewhere is a bonus option for
experts.  So I have no idea why you keep hitting on this subject; it's
a side track, as far as getting GnuTLS and its updates to Emacs is
concerned.

> 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.

These problems are theoretical, we never heard about them here.
dynamic-library-alist is carefully constructed to accept only names of
DLLs that we know are safe, which solves at least part of the
potential for trouble.

And again, if someone mixes MinGW with MSVC, they are in trouble
already and need a lot of discipline to avoid shooting themselves in
the foot.

We were talking about the majority of the users, but your examples are
all from the expert land.  I think it's not a coincidence: there
simply are no such problems in the vast majority of installations
nowadays, in practice.

> 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?

It isn't confusing if Emacs displays a clear error message.

Again, this use case is for experts; by default the DLL should be with
emacs.exe.  Experts will know how to avoid that; most uninstallers ask
for an explicit permission to remove DLLs from public directories, and
experts know better than blindly clicking OK.

> > 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.

Sorry, I cannot watch indifferently as people are talked into wrong
conclusions based on information that is several years obsolete.  It
is ridiculous to base design decision for a _future_ feature on
problems that last happened on Windows 2000, a system whose use today
is marginal at best.  Windows XP was released in 2001, and is already
obsolete, so any version prior to it is definitely so.

> 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.

You can call 7 years of safe use on 4 different machines luck if you
want.  I call it discipline and following safe practices.