From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 32902@debbugs.gnu.org
Subject: bug#32902: Add support for (TIMESTAMP . RESOLUTION) Lisp timestamps
Date: Tue, 09 Oct 2018 18:09:31 +0300 [thread overview]
Message-ID: <838t37yx5g.fsf@gnu.org> (raw)
In-Reply-To: <cb076958-3b90-7e4c-89f6-60fee2999f4b@cs.ucla.edu> (message from Paul Eggert on Sun, 7 Oct 2018 22:18:12 -0700)
> Cc: 32902@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 7 Oct 2018 22:18:12 -0700
>
> > Microsoft made an incompatible change in its runtime libraries
> > around Windows Vista, and switched to 64-bit time_t even on 32-bit
> > systems. Since we still try to support older Windows versions, we
> > must use that kludge, and we must limit ourselves to 32-bit time_t in
> > 32-bit builds.
>
> Here are some possible suggestions:
>
> 1. Redefine 'struct timespec' and 'clock_gettime' on 32-bit MinGW so that they
> use 32-bit time_t only. The redefinitions would be visible only within Emacs;
> you wouldn't actually change MinGW.
>
> 2. Have Emacs w32*.c detect the width of the MS-Windows API's time_t at runtime,
> and if necessary convert between any 32-bit time_t on the MS-Windows side and
> the 64-bit time_t visible to the rest of the Emacs C code.
>
> 3. Build one Emacs executable for 32-bit MS-Windows Vista and later (with 64-bit
> time_t), and another one for 32-bit MS-Windows XP and older (with 32-bit time_t).
>
> Any of these would insulate the rest of Emacs from this glitch.
The last two are undesirable, since it is generally expected of a
single Windows binary to run on all supported systems; having 2
separate binaries is possible, but complicates the matters.
I will try to look into the first alternative, not sure if its
feasible.
> > drop support for older Windows systems.
>
> Microsoft itself has dropped support for the older MS-Windows systems in
> question, and it would be fine if Emacs dropped support too. We routinely drop
> support for obsolete and no-longer-maintained operating system versions like
> RHEL 5 and Irix 6.5.
I don't think we should follow Microsoft in their decisions. Last
time this came up, we decided not to drop support even for Windows 9X,
and here we are talking about XP and older. We still have a few years
to make that decision.
next prev parent reply other threads:[~2018-10-09 15:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-02 1:00 bug#32902: Add support for (TIMESTAMP . RESOLUTION) Lisp timestamps Paul Eggert
2018-10-02 3:04 ` Eli Zaretskii
2018-10-03 18:45 ` Paul Eggert
2018-10-04 16:08 ` Eli Zaretskii
2018-10-07 6:32 ` Paul Eggert
2018-10-07 17:55 ` Eli Zaretskii
2018-10-07 20:05 ` Paul Eggert
2018-10-08 2:44 ` Eli Zaretskii
2018-10-08 5:18 ` Paul Eggert
2018-10-09 15:09 ` Eli Zaretskii [this message]
[not found] ` <3f0bcf06-83f2-a0e9-c9ab-b06d65417afe@cs.ucla.edu>
2018-10-10 3:49 ` Eli Zaretskii
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=838t37yx5g.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=32902@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
/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.