From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: GnuTLS for W32 Date: Wed, 04 Jan 2012 15:14:28 +0100 Message-ID: <87fwfvsgfv.fsf@wanadoo.es> References: <87boqmlrma.fsf@wanadoo.es> <87ty4e9j19.fsf@lifelogs.com> <83obumqa0v.fsf@gnu.org> <87ipktag2e.fsf@lifelogs.com> <87fwfxtxuz.fsf@wanadoo.es> <87aa64ubg9.fsf@wanadoo.es> <83boqkr9bp.fsf@gnu.org> <874nwcu17i.fsf@wanadoo.es> <834nwcr6un.fsf@gnu.org> <87vcosskhc.fsf@wanadoo.es> <831urgr2yr.fsf@gnu.org> <87r4zgsh2w.fsf@wanadoo.es> <87ipks3zbo.fsf@uwakimon.sk.tsukuba.ac.jp> <87boqk3q69.fsf@uwakimon.sk.tsukuba.ac.jp> <87aa634st8.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1325686517 19049 80.91.229.12 (4 Jan 2012 14:15:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2012 14:15:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 04 15:15:10 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RiRcT-00075h-9H for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2012 15:15:10 +0100 Original-Received: from localhost ([::1]:44584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiRcS-0004Lv-DS for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2012 09:15:08 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:41907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiRcG-00044Y-4F for emacs-devel@gnu.org; Wed, 04 Jan 2012 09:15:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiRc9-00022v-KO for emacs-devel@gnu.org; Wed, 04 Jan 2012 09:14:56 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:39464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiRc8-00022i-R3 for emacs-devel@gnu.org; Wed, 04 Jan 2012 09:14:49 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RiRc4-0006pY-7T for emacs-devel@gnu.org; Wed, 04 Jan 2012 15:14:44 +0100 Original-Received: from 225.red-79-147-11.dynamicip.rima-tde.net ([79.147.11.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jan 2012 15:14:44 +0100 Original-Received: from ofv by 225.red-79-147-11.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jan 2012 15:14:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 88 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 225.red-79-147-11.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) Cancel-Lock: sha1:QD6Ufq7A3DdevcIDXth03iVFw0c= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147270 Archived-At: Eli Zaretskii writes: >> From: "Stephen J. Turnbull" >> 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]