From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: GnuTLS for W32 Date: Thu, 05 Jan 2012 01:34:21 -0500 Message-ID: References: <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> <87fwfvsgfv.fsf@wanadoo.es> <877h17scdo.fsf@wanadoo.es> <87hb0b77nr.fsf@lifelogs.com> <8739bvs27m.fsf@wanadoo.es> <83k457p3fg.fsf@gnu.org> <87pqezqeph.fsf@wanadoo.es> Reply-To: Eli Zaretskii 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 1325745276 19930 80.91.229.12 (5 Jan 2012 06:34:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Jan 2012 06:34:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 05 07:34:31 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 1RiguE-0001qJ-AD for ged-emacs-devel@m.gmane.org; Thu, 05 Jan 2012 07:34:30 +0100 Original-Received: from localhost ([::1]:48582 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiguD-0004WA-RG for ged-emacs-devel@m.gmane.org; Thu, 05 Jan 2012 01:34:29 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiguA-0004W4-3d for emacs-devel@gnu.org; Thu, 05 Jan 2012 01:34:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rigu8-0005ZN-IR for emacs-devel@gnu.org; Thu, 05 Jan 2012 01:34:26 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:41418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rigu8-0005ZG-D6 for emacs-devel@gnu.org; Thu, 05 Jan 2012 01:34:24 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Rigu5-0004nQ-Il; Thu, 05 Jan 2012 01:34:21 -0500 In-reply-to: <87pqezqeph.fsf@wanadoo.es> (message from =?utf-8?Q?=C3=93sca?= =?utf-8?Q?r?= Fuentes on Wed, 04 Jan 2012 23:34:50 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:147319 Archived-At: > From: Óscar Fuentes > Date: Wed, 04 Jan 2012 23:34:50 +0100 > > Eli Zaretskii writes: > > > 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. > > Before putting too much hope into SxS I encourage you to read the > wikipedia page about it that you linked on a previous post. Believe me, I have. With today's PC ("on the one hand .... but on the other hand") stance, you can no longer have articles with definitive opinions. Articles need to be "balanced", so they will dig any minor problem to show "objectivity". Building evidence on that is silly. All I can say that "it works for me" on no less than 4 different XP systems used for 4 different purposes, for 7 years, with not a single problem that I can remember. > > 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. > > The 3.x version is named -28 ? Yes. The number comes from the build. GnuTLS has some weird scheme for numbering the releases, take a look at their configure script. But that's not really relevant here. > > 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. > > Appending a number to a name doesn't solve the problem. It does solve most of it, because programs look only for DLLs they were linked against. > A simple experiment: put a libgnutls-26.dll on the system32 > directory. It is shared, right? Now install cygwin or msys, or any of > multiple standalone applications which are cygwin-based, and put its > binary directory before system32 on PATH. See it? People who install both MinGW and MSYS/Cygwin on the same system have a lot of rope to hang themselves, if they act stupidly. Putting a non-system DLL in system32 is one such stupid act; having MSYS on your PATH is another. MSYS installer has an option to stay away of PATH (I think it's the default); if you read the installation instructions carefully during installation, you won't get into this trouble. I know, because I have MSYS installed on one of my machines, and have no trouble at all, although the amount of overlap in DLLs is considerable. In addition, MSYS names most (if not all) of its DLLs differently, msys-FOO-NN.dll, which also alleviates this problem. Finally, for the umpteenth time: the default should be to put the DLL where emacs.exe lives. Putting it elsewhere is a bonus option for experts. So I have no idea why you keep hitting on this subject; it's a side track, as far as getting GnuTLS and its updates to Emacs is concerned. > Another experiment: build an application such as Emacs with VC++ 6 or > MinGW with the default settings. Now make it to use a dll (GnuTLS, an > image library...) compiled with a modern release of VS. Unless such > library follows a very strict policy about resource handling (and > possibly other aspects) you are asking for problems. These problems are theoretical, we never heard about them here. dynamic-library-alist is carefully constructed to accept only names of DLLs that we know are safe, which solves at least part of the potential for trouble. And again, if someone mixes MinGW with MSVC, they are in trouble already and need a lot of discipline to avoid shooting themselves in the foot. We were talking about the majority of the users, but your examples are all from the expert land. I think it's not a coincidence: there simply are no such problems in the vast majority of installations nowadays, in practice. > Think on a user that discovers that sending mail with Emacs just works > because some other package installed GnuTLS on some directory listed on > PATH. Time later he decides to uninstall the application and afterwards > tries to send an e-mail, just to notice to his dismay that it doesn't > work anymore. Confusing, isn't it? It isn't confusing if Emacs displays a clear error message. Again, this use case is for experts; by default the DLL should be with emacs.exe. Experts will know how to avoid that; most uninstallers ask for an explicit permission to remove DLLs from public directories, and experts know better than blindly clicking OK. > > 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! > > Please stop using inflamatory language and offensive assertions. Sorry, I cannot watch indifferently as people are talked into wrong conclusions based on information that is several years obsolete. It is ridiculous to base design decision for a _future_ feature on problems that last happened on Windows 2000, a system whose use today is marginal at best. Windows XP was released in 2001, and is already obsolete, so any version prior to it is definitely so. > I could say that your real-world experience distributing, installing > and supporting software across heterogenous environments looks quite > limited, but I'll rather suppose that you were very lucky so far. You can call 7 years of safe use on 4 different machines luck if you want. I call it discipline and following safe practices.