From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Windows emacs-25.1 i686 vs x86_64? Date: Tue, 08 Nov 2016 17:32:54 +0200 Message-ID: <83d1i6gf6h.fsf@gnu.org> References: <6e2cffe5-942b-48d4-9ed5-ef39803bcd30@googlegroups.com> <87mvhgsf21.fsf@russet.org.uk> <8360o4monq.fsf@gnu.org> <87vaw4gq0j.fsf@russet.org.uk> <83oa1vlnkk.fsf@gnu.org> <87d1iba6od.fsf@russet.org.uk> <83ins2jq88.fsf@gnu.org> <87eg2p8swx.fsf@russet.org.uk> <831sypjmst.fsf@gnu.org> <83wpggip8j.fsf@gnu.org> <05ba947a-970a-178c-8036-bcdf84485384@cs.ucla.edu> <83zilbgo4u.fsf@gnu.org> <20161107140228.0a60be57@jabberwock.cb.piermont.com> <20161107150232.0b10d24f@jabberwock.cb.piermont.com> <20161107152228.61e18b30@jabberwock.cb.piermont.com> <83k2cfghnp.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1478619249 5556 195.159.176.226 (8 Nov 2016 15:34:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 8 Nov 2016 15:34:09 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, perry@piermont.com To: Elias =?utf-8?Q?M=C3=A5rtenson?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 08 16:33:59 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c48P7-0006kP-DZ for ged-emacs-devel@m.gmane.org; Tue, 08 Nov 2016 16:33:41 +0100 Original-Received: from localhost ([::1]:33841 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c48P9-0003yz-G5 for ged-emacs-devel@m.gmane.org; Tue, 08 Nov 2016 10:33:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c48OU-0003w6-Pt for emacs-devel@gnu.org; Tue, 08 Nov 2016 10:33:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c48OQ-0005Ur-HB for emacs-devel@gnu.org; Tue, 08 Nov 2016 10:33:02 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c48OQ-0005Uk-DK; Tue, 08 Nov 2016 10:32:58 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2915 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c48OP-0002kS-JC; Tue, 08 Nov 2016 10:32:58 -0500 In-reply-to: (message from Elias =?utf-8?Q?M=C3=A5rtenson?= on Tue, 8 Nov 2016 11:48:18 +0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:209290 Archived-At: > From: Elias Mårtenson > Date: Tue, 8 Nov 2016 11:48:18 +0800 > Cc: "Perry E. Metzger" , Stefan Monnier , > emacs-devel > > I think deliberately breaking it seems like it would be antisocial, > > but going through substantial trouble (that is, say, holding back > > some sort of improved functionality) to make sure it keeps working > > also seems unreasonable. > > We never do the latter. If some functionality cannot work on old > Windows systems, there's a runtime test which disables the feature on > those systems, with some suitable return value or error message. > > This has been the Emacs practice for years. > > FWIW, my impression after reading this thread wasn't merely about the text in the README, but rather as to whether time should be spent even considering Windows 9x when working on Emacs. It started because I asked not to delete that text. Leaving that text alone would exactly mean we don't need to spend any time even considering Windows 9X, whereas this discussion does require us to consider it. > I took the liberty to search the archives, and found several instances this year alone where time was spent discussing whether or not to use one function or another because they weren't supposed on these older versions of Windows. During this year, I see just one discussion (in January) of a certain patch wrt how to adapt it to some older systems, and how to fix bugs and issues revealed on those systems (including, but not limited to, 9X). > At the risk of putting opinions into other people's mouths, I do think that those are the kinds of discussions no one really wants. Some of those discussions (usually, comments to patches) cannot be avoided, because some library functions and APIs aren't available on all OS versions. Failure to either use more widely available APIs or provide a run-time test for their availability will lead to an Emacs binary that will refuse to start on some versions of Windows, even though the offending API is not needed by that user in that session. The result will be that Emacs can only be trusted to run on the system where it was built. On Unix, these tests are done at configure time, and therefore the produced binary cannot be safely copied to another system. By contrast, on Windows, it is very customary for users to download binaries compiled on some other system, so configure-time testing cannot be used, and must be replaced with run-time testing, if and when the corresponding APIs are needed for some Emacs feature and alternative APIs don't exist. People who contribute code to Emacs aren't always aware of this issue, so it comes up in discussing patches. The code for these tests is boilerplate, but it must be there for each API that is not guaranteed to exist on all supported versions of the OS. And of course, this isn't limited to Windows 9X, since each new version of Windows introduces APIs that aren't available in previous versions. So providing bleeding-edge features in Emacs on Windows will always need to include run-time tests for availability of the required new APIs, because we do want Emacs to continue being able to run on older systems, even if those bleeding-edge features might not be available there. We already have a few features that are disabled, or fall back on simple replacements, on versions of Windows newer than 9X, sometimes much newer (e.g., creation and resolution of symbolic links aren't supported below Vista).