Re: Windows emacs-25.1 i686 vs x86_64?

[Eli Zaretskii <eliz@gnu.org>]

> 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).