bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: bug-gnulib@gnu.org, rogerdpack@gmail.com
Subject: Re: gettimeofday.c windows version?
Date: Sun, 11 Dec 2022 19:25:12 +0100	[thread overview]
Message-ID: <6145386.axxuzLQ8MY@nimes> (raw)
In-Reply-To: <83fsdlua2u.fsf@gnu.org>

Eli Zaretskii wrote:
> > From: Bruno Haible <bruno@clisp.org>
> > Cc: bug-gnulib@gnu.org, rogerdpack@gmail.com
> > Date: Sun, 11 Dec 2022 17:20:07 +0100
> > 
> > > I think the code should use a run-time check regardless of the version
> > > of Windows on which the program was compiled.
> > 
> > But the value of _WIN32_WINNT is not the version *on* which the program was
> > compiled. It is the minimum version *for* which the program was compiled.
> > Both the INSTALL.windows of some GNU packages, as well as
> >  <https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt>,
> > say so. Maybe we should emphasize this in the install documentation even more?
> 
> I know all that.  But the issue here is different: if this file is
> compiled with _WIN32_WINNT lower than Windows 8, ...

We agree about this case.

The case here is (apparently) that someone compiled this file with
_WIN32_WINNT being ≥ _WIN32_WINNT_WIN8, and what to do then.

I have understood that your proposal is to still provide the ability to
run the binaries on older versions.

Whereas I continue to think that I'll better follow _WIN32_WINNT in the
sense that Microsoft specified ("which versions of Windows your code can
run on"). So that
  - The person who builds binaries has the choice between slim, optimized
    binaries and backward-compatible binaries,
  - It's clear which code to remove, when the time has come,
  - We have the same treatment than with other old cruft (e.g. HP-UX/m68k
    or DolphinOS) which I removed in 2020.

> My point is that there's a difference between when you stop
> _testing_ your code on some old platform, as opposed to when you
> deliberately break the build for that platform.  You want to do the
> latter; I'm saying do the former, and let people who use the old
> platform, such as they exist, test it for you and report problems.

I asked for the *right moment* to deliberately break supporting Windows 7.
I now know that your answer is "never", and hope I won't forget it for a
while.

> Why remove it?  Just because Microsoft decided to EOL those
> old systems?

- In order to reduce testing.
- In order to be honest about what we support vs. don't support.

Doing a web search, I now see from
<https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide>
that 10% of Windows users are still using Window 7. Whereas Windows XP
is below 1%.

Based on these numbers, I now think it's useful to continue supporting
Windows 7 — in the way you say, by replying to bug reports only —, whereas
removing support for Windows XP can be done earlier, as needed for maintenance.

Bruno





  reply	other threads:[~2022-12-11 18:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-11  6:01 gettimeofday.c windows version? Roger Pack
2022-12-11  7:05 ` Roger Pack
2022-12-11 14:22 ` Bruno Haible
2022-12-11 15:09   ` Eli Zaretskii
2022-12-11 16:20     ` Bruno Haible
2022-12-11 16:56       ` Eli Zaretskii
2022-12-11 17:25         ` Eli Zaretskii
2022-12-11 18:25           ` Bruno Haible [this message]
2022-12-11 18:55             ` Eli Zaretskii
2022-12-12  7:17               ` Paul Eggert
2022-12-12 12:19                 ` Bruno Haible
2022-12-12 13:06                 ` Eli Zaretskii
2022-12-12 14:25                   ` Bruno Haible
2022-12-12 14:40                     ` Eli Zaretskii
2022-12-12 19:44                       ` Paul Eggert
2022-12-12 20:37                         ` Eli Zaretskii
2022-12-16 23:35                           ` Paul Eggert
2022-12-17  8:09                             ` Eli Zaretskii
2022-12-12 19:14                     ` Gisle Vanem
2022-12-23  8:38   ` Roger Pack
2022-12-23  8:46     ` Eli Zaretskii
2022-12-23 23:47     ` Paul Eggert
2022-12-24  6:46       ` Eli Zaretskii
2022-12-24  7:42         ` Paul Eggert
2022-12-24  8:34           ` 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

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6145386.axxuzLQ8MY@nimes \
    --to=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=eliz@gnu.org \
    --cc=rogerdpack@gmail.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).