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: Thu, 05 Jan 2012 03:00:15 +0100 Message-ID: <87d3ayrjrk.fsf@wanadoo.es> References: <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> <87fwfvsgfv.fsf@wanadoo.es> <877h17scdo.fsf@wanadoo.es> <87hb0b77nr.fsf@lifelogs.com> <8739bvs27m.fsf@wanadoo.es> <87lipnqdhy.fsf@wanadoo.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1325728843 32594 80.91.229.12 (5 Jan 2012 02:00:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Jan 2012 02:00:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 05 03:00:40 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 1RicdD-0006E7-QM for ged-emacs-devel@m.gmane.org; Thu, 05 Jan 2012 03:00:40 +0100 Original-Received: from localhost ([::1]:56309 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RicdD-0001sQ-1J for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2012 21:00:39 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:49691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ricd8-0001sL-NX for emacs-devel@gnu.org; Wed, 04 Jan 2012 21:00:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ricd7-0000uU-EF for emacs-devel@gnu.org; Wed, 04 Jan 2012 21:00:34 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:35312) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ricd7-0000uO-3H for emacs-devel@gnu.org; Wed, 04 Jan 2012 21:00:33 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ricd5-0006AH-5t for emacs-devel@gnu.org; Thu, 05 Jan 2012 03:00:31 +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 ; Thu, 05 Jan 2012 03:00:31 +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 ; Thu, 05 Jan 2012 03:00:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 67 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:M/4x4CyQVbSQFmwNfUPWyt2UUNs= 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:147306 Archived-At: Juanma Barranquero writes: > On Thu, Jan 5, 2012 at 00:00, Óscar Fuentes wrote: > >> It took me >> months to discover the problem for one of the users: a mass storage >> device driver and accompanying backup utility installed their own >> custom-modified MSVCRT.DLL on system32, which somehow caused my app to >> freeze when certain gui action was performed. They didn't bothered to >> use a different version string or id on the resources of the library, so >> it reported itself as one of the "good" dlls. > > That just means that someone should be hit in the head with a printed > copy of the full MSDN site. Repeatedly. It *also* means that depending on unknown third parties is asking for trouble. >> Then I started to put my >> runtime dlls on the same directory as the rest of my binaries, and the >> problems of those users disappeared. > > Wonderful. But GnuTLS is not "our" runtime DLL, not more than msvcrt.dll is. > > Please understand: I'm not really arguing against installing the > GnuTLS DLL along the emacs.exe binary (though, as a separate project, > I still think it's better to install it on its own). I'm arguing > against, and will continue to fight, *distributing* it in the first > place with Emacs. We *are* *not* a binary distribution project, and we > only do it for Windows because most Windows users do not have a > building environment. Going that route means less programming > resources and more administrivia. AFAIK Windows binaries are distributed from the GNU servers just because someone volunteers to do the job, not because it is a requisite for the release. So it should be up to those volunteers to decide if they want to include those libraries (GnuTLS, image support, etc) on the binary package. And if someone volunteers for maintaining a system that updates those libraries, it is the job he picked. A slightly different issue is to decide if changes to Emacs sources are allowed to do that chore on certain way, but then it is up to the volunteers again and solid reasons should be given to reject those contributions. >> I think that's more or less what Lennart is already doing, isn't it? > > Sort of. IMHO, Lennart's EmacsW32 is a fork, because he includes some > changes that aren't just customizations (emacsclient is a prime > example). IIRC Lennart also distributes an unpatched Emacs. >> OTOH an installer that could act as an update tool for the dlls could be >> interesting. > > Yes, definitely. As long as developing it and maintaining it is > anybody else's (= "not the Emacs w32 people") responsibility :-) Ah, yes, the Emacs w32 people. Now I understand your stance better (and maybe Eli's). I think it would be unfair and unreasonable to make you responsible of doing the job related to those libraries, but I also think that you are not obliged in any way to provide binaries of anything. Keeping the sources on a ready state is enough, thank you. (Not saying that you are *obliged* to do that either.)