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: Tue, 03 Jan 2012 15:07:02 +0100 Message-ID: <87aa64ubg9.fsf@wanadoo.es> References: <87ty4fbje8.fsf@lifelogs.com> <83ehvjs8t5.fsf@gnu.org> <87pqf3bcom.fsf@lifelogs.com> <83boqns68o.fsf@gnu.org> <87liprazr1.fsf@lifelogs.com> <83wr9bqez3.fsf@gnu.org> <87y5tr9dwv.fsf_-_@lifelogs.com> <87k45alwgb.fsf@wanadoo.es> <87fwfyltm1.fsf@wanadoo.es> <87boqmlrma.fsf@wanadoo.es> <87ty4e9j19.fsf@lifelogs.com> <83obumqa0v.fsf@gnu.org> <87ipktag2e.fsf@lifelogs.com> <87fwfxtxuz.fsf@wanadoo.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1325599657 7619 80.91.229.12 (3 Jan 2012 14:07:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2012 14:07:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 03 15:07:33 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 1Ri51X-0001gF-EO for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2012 15:07:31 +0100 Original-Received: from localhost ([::1]:42255 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri51W-0007tk-Th for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2012 09:07:30 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:37625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri51R-0007tT-2r for emacs-devel@gnu.org; Tue, 03 Jan 2012 09:07:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ri51N-00019S-HN for emacs-devel@gnu.org; Tue, 03 Jan 2012 09:07:25 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:53764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri51N-00019G-3f for emacs-devel@gnu.org; Tue, 03 Jan 2012 09:07:21 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ri51J-0001Y4-N5 for emacs-devel@gnu.org; Tue, 03 Jan 2012 15:07:17 +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 ; Tue, 03 Jan 2012 15:07:17 +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 ; Tue, 03 Jan 2012 15:07:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 43 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:QY1dy72uVt7CgVX+BShY6QPWE00= 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:147210 Archived-At: Eli Zaretskii writes: >> > Can Emacs modify the DLL search path on W32 so it can install some DLL >> > from ELPA and then activate it dynamically? Or does it require a >> > restart and modifying the global PATH? Either way, can the process be >> > automated? >> >> The relevant MS Windows API function (LoadLibrary) accepts a full >> pathname > > That's a factual truth, but it would be a grave mistake on our part to > use absolute file names for loading dynamic libraries, because it will > mean a major inconvenience to users. It is hard on Windows to pick up > a fixed directory where every user could easily put the library: the > only directories that are guaranteed to exist on every Windows system > are frequently locked up by security policies, the only disk drive > guaranteed to exist can be a remote drive or even a read-only drive, > etc. It would be a step in the wrong direction. You are providing reasons for the package approach: if it is hard for the user to put the dll in the correct directory, let Emacs do it. > Besides, even if we did follow this path, it wouldn't solve the > problem, because: > >> so no need for restarts nor changing PATH. > > There's much more to loading a new DLL in the middle of a session than > just the location of the new DLL. I will address that in a separate > message. I was not proposing to unload the old dll and load the new one on the fly (BTW, I was not prososing anything at all, just providing technical info). I know very well that that is unfeasible in general. What is possible: if GnuTLS is absent and the user wants it, download the dll and start using it right away. If GnuTLS needs to be upgraded, advertise the fact to the user, ask for his permission, and proceed to download(*), with an Emacs restart at the end (or some variation of this sequence of actions). * DLLs which are in use are not file-writable. Either the dll must be unloaded first (which may be unfeasible) or the new version must be downloaded to a temporary location and moved to the final place later.