Re: GnuTLS for W32

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Stephen J. Turnbull" <stephen@xemacs.org>
>> Cc: ofv@wanadoo.es,
>>     emacs-devel@gnu.org
>> Date: Wed, 04 Jan 2012 20:21:07 +0900
>> 
>> Eli Zaretskii writes:
>> 
>>  > For this reason, I think we should give Emacs users an option to put
>>  > the downloaded DLL in some directory that is not Emacs-specific, so
>>  > that other programs could use it.
>> 
>> Well, as you know I'm not a Windows person, but my understanding is
>> that one reason that DLL hell is called "DLL hell"
>
> An aside: the "DLL hell"s flames are much lower now than they used to
> be, see
>
>    http://en.wikipedia.org/wiki/Side-by-side_assembly

That requires an installer that follows MS guidelines. It's not as easy
as unzipping a file on a directory.

On the topic of how hard is to load a dll from an arbitrary location,
that is what I found on the Emacs sources:

/* The argument LIBRARIES is an alist that associates a symbol
   LIBRARY_ID, identifying an external DLL library known to Emacs, to
   a list of filenames under which the library is usually found.  In
   most cases, the argument passed as LIBRARIES is the variable
   `dynamic-library-alist', which is initialized to a list of common
   library names.  If the function loads the library successfully, it
   returns the handle of the DLL, and records the filename in the
   property :loaded-from of LIBRARY_ID; it returns NULL if the library
   could not be found, or when it was already loaded (because the
   handle is not recorded anywhere, and so is lost after use).  It
   would be trivial to save the handle too in :loaded-from, but
   currently there's no use case for it.  */
HMODULE
w32_delayed_load (Lisp_Object libraries, Lisp_Object library_id)
{
  HMODULE library_dll = NULL;

  CHECK_SYMBOL (library_id);

  if (CONSP (libraries) && NILP (Fassq (library_id, Vlibrary_cache)))
    {
      Lisp_Object found = Qnil;
      Lisp_Object dlls = Fassq (library_id, libraries);

      if (CONSP (dlls))
        for (dlls = XCDR (dlls); CONSP (dlls); dlls = XCDR (dlls))
          {
            CHECK_STRING_CAR (dlls);
            if ((library_dll = LoadLibrary (SDATA (XCAR (dlls)))))
              {
                found = XCAR (dlls);
                break;
              }
          }

      Fput (library_id, QCloaded_from, found);
    }

  return library_dll;
}


I think that Emacs is right now capable of loading a dll from an
arbitrary place. Just set dynamic-library-alist as it contains ('gnutls
. "/path/to/gnutls/gnutls.dll") (or whatever are the right names). In
any case, creating a new function that loads a .dll by name seems quite
straightforward, once we have seem how w32_delayed_load is implemented.

> FWIW, I didn't have a single problem for years on my XP boxes.  YMMV,
> of course.

On the last 5 years I the only occurrences of the dll hell I had were
related to Free software which uses naive installers. Cygwin, MSYS and
GnuWin32 does not get along very well, and even updating some of their
component may create havoc due to incompatibilities of the new dlls with
some of the old tools. The safe method is to update the whole lot.

Installing a dll intended to be used by Emacs on a shared place is
asking for trouble.

[snip]