Re: GnuTLS for W32

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 04 Jan 2012 20:21:49 +0100
> 
> This is a common scenario on MS Windows: multiple providers of binary
> packages, multiple installers with different install policies even for
> the same installer, lots of directories on PATH (each application lives
> on its own directory and often wants to be listed on PATH), varying
> policies about where a non-privileged user is allowed to put binaries,
> multiple incompatible binary macropackages that provides the same
> executables and libraries with the same names (Cygwin, MSYS, GnuWin32
> and what-not), a lack of culture of system administration, a growing
> tendency to rely on self-updating packages... and the list goes on.
> 
> If a user is informed about the need to fix GnuTLS (through the local
> newspaper, I guess) his first reaction would be "GnuWhat? Is it on my
> machine?" Next, as every desktop computer user would do, he performs a
> full HD file search for the library ("and BTW, how is it named,
> exactly?") After locating the instance (or multiple instances) he needs
> to figure out the correct procedure to update it ("Was this installed
> along something else? Has this be put here by an installer of some sort?
> Does that installer offer an update method? What depends on this dll?
> What's the installed version, and what's the compatible update? Is it
> available somewhere? If I use this newer version which I found with a
> Google search, can something break apart?")
> 
> Sure, for us it all looks very easy, but I suffered DLL hell a few times
> and it is very frustrating. Can't imagine how can it be for a novice or
> a less computer-savvy user.

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.

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.  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.
Poof! the problem doesn't exist.

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!

> For a Windows binary package to be robust, it must be as self-contained
> as possible.

True, but irrelevant.