From: Eli Zaretskii <eliz@gnu.org>
To: "Elias Mårtenson" <lokedhs@gmail.com>
Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, perry@piermont.com
Subject: Re: Windows emacs-25.1 i686 vs x86_64?
Date: Tue, 08 Nov 2016 17:32:54 +0200 [thread overview]
Message-ID: <83d1i6gf6h.fsf@gnu.org> (raw)
In-Reply-To: <CADtN0WLuV70OJdk+7rcNpXarV4d=bx+kcGoBTc+Ma9b=n6vjDQ@mail.gmail.com> (message from Elias Mårtenson on Tue, 8 Nov 2016 11:48:18 +0800)
> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Tue, 8 Nov 2016 11:48:18 +0800
> Cc: "Perry E. Metzger" <perry@piermont.com>, Stefan Monnier <monnier@iro.umontreal.ca>,
> emacs-devel <emacs-devel@gnu.org>
>
> 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).
next prev parent reply other threads:[~2016-11-08 15:32 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-03 15:32 Windows emacs-25.1 i686 vs x86_64? David M. Miller
2016-11-03 15:39 ` tomas
2016-11-03 16:00 ` David M. Miller
2016-11-03 16:26 ` John Mastro
2016-11-03 16:28 ` Phillip Lord
2016-11-03 17:44 ` David M. Miller
2016-11-03 22:21 ` Phillip Lord
2016-11-03 17:58 ` Eli Zaretskii
2016-11-03 22:25 ` Phillip Lord
2016-11-04 7:19 ` Eli Zaretskii
2016-11-04 10:19 ` Phillip Lord
2016-11-05 8:16 ` Eli Zaretskii
2016-11-05 22:26 ` Phillip Lord
2016-11-06 3:43 ` Eli Zaretskii
2016-11-06 8:10 ` Paul Eggert
2016-11-06 15:48 ` Eli Zaretskii
2016-11-06 16:13 ` Óscar Fuentes
2016-11-06 16:43 ` Eli Zaretskii
2016-11-06 17:01 ` Óscar Fuentes
2016-11-06 17:24 ` Eli Zaretskii
2016-11-06 18:26 ` Óscar Fuentes
2016-11-06 18:42 ` Eli Zaretskii
2016-11-06 19:17 ` Eli Zaretskii
2016-11-06 20:15 ` Óscar Fuentes
2016-11-07 14:40 ` Richard Stallman
2016-11-07 15:16 ` Phillip Lord
2016-11-08 13:53 ` Richard Stallman
2016-11-06 16:51 ` Stefan Monnier
2016-11-06 18:50 ` John Wiegley
2016-11-07 14:42 ` Richard Stallman
2016-11-06 21:54 ` Paul Eggert
2016-11-06 21:57 ` Daniel Colascione
2016-11-07 14:43 ` Richard Stallman
2016-11-07 15:15 ` Daniel Colascione
2016-11-07 15:26 ` Phillip Lord
2016-11-08 13:53 ` Richard Stallman
2016-11-08 14:52 ` Phillip Lord
2016-11-08 15:31 ` Eli Zaretskii
2016-11-09 16:50 ` Phillip Lord
2016-11-09 17:15 ` Eli Zaretskii
2016-11-09 17:18 ` Stefan Monnier
2016-11-10 15:19 ` Phillip Lord
2016-11-09 7:00 ` martin rudalics
2016-11-15 10:26 ` Phillip Lord
2016-11-07 16:34 ` Paul Eggert
2016-11-07 18:07 ` Eli Zaretskii
2016-11-07 19:02 ` Perry E. Metzger
2016-11-07 19:29 ` Eli Zaretskii
2016-11-07 21:54 ` Phillip Lord
2016-11-07 19:39 ` Stefan Monnier
2016-11-07 20:02 ` Perry E. Metzger
2016-11-07 20:10 ` Stefan Monnier
2016-11-07 20:22 ` Perry E. Metzger
2016-11-07 20:27 ` Eli Zaretskii
2016-11-08 3:48 ` Elias Mårtenson
2016-11-08 15:32 ` Eli Zaretskii [this message]
2016-11-07 18:49 ` Perry E. Metzger
2016-11-08 13:55 ` Richard Stallman
2016-11-08 14:34 ` Perry E. Metzger
2016-11-06 21:50 ` Phillip Lord
2016-11-06 4:13 ` Noam Postavsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83d1i6gf6h.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lokedhs@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=perry@piermont.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.