gettimeofday.c windows version?

gettimeofday.c windows version?

[Roger Pack]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

I received some complaints saying in mingw it was"requiring windows 8" for
a certain library.

"Entry point not found, GetSystemTimePreciseAsFileTime could not be located
in the dynamic link library KERNEL32.dll".

mingw appears to have the following:

#define _WIN32_WINNT 0x502
#define _WIN32_WINNT_WIN8 0x0602

Perhaps the following patch?  Thanks! :)

diff --git a/lib/gettimeofday.c b/lib/gettimeofday.c
index 36c7920af..428cc4f30 100644
--- a/lib/gettimeofday.c
+++ b/lib/gettimeofday.c
@@ -35,7 +35,7 @@
 # undef LoadLibrary
 # define LoadLibrary LoadLibraryA

-# if !(_WIN32_WINNT >= _WIN32_WINNT_WIN8)
+# if (_WIN32_WINNT >= _WIN32_WINNT_WIN8)

 /* Avoid warnings from gcc -Wcast-function-type.  */
 #  define GetProcAddress \

[-- Attachment #2: Type: text/html, Size: 1546 bytes --]

Re: gettimeofday.c windows version?

[Roger Pack]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On Sat, Dec 10, 2022 at 11:01 PM Roger Pack <rogerdpack@gmail.com> wrote:

> I received some complaints saying in mingw it was"requiring windows 8" for
> a certain library.
>
> "Entry point not found, GetSystemTimePreciseAsFileTime could not be
> located in the dynamic link library KERNEL32.dll".
>
> mingw appears to have the following:
>
> #define _WIN32_WINNT 0x502
> #define _WIN32_WINNT_WIN8 0x0602
>
> Perhaps the following patch?  Thanks! :)
>
> diff --git a/lib/gettimeofday.c b/lib/gettimeofday.c
> index 36c7920af..428cc4f30 100644
> --- a/lib/gettimeofday.c
> +++ b/lib/gettimeofday.c
> @@ -35,7 +35,7 @@
>  # undef LoadLibrary
>  # define LoadLibrary LoadLibraryA
>
> -# if !(_WIN32_WINNT >= _WIN32_WINNT_WIN8)
> +# if (_WIN32_WINNT >= _WIN32_WINNT_WIN8)
>
>  /* Avoid warnings from gcc -Wcast-function-type.  */
>  #  define GetProcAddress \
>

Oops looks like it might be more like the following. Thanks.

diff --git a/lib/gettimeofday.c b/lib/gettimeofday.c
index 36c7920af..fdc236883 100644
--- a/lib/gettimeofday.c
+++ b/lib/gettimeofday.c
@@ -35,7 +35,7 @@
 # undef LoadLibrary
 # define LoadLibrary LoadLibraryA

-# if !(_WIN32_WINNT >= _WIN32_WINNT_WIN8)
+# if (_WIN32_WINNT >= _WIN32_WINNT_WIN8)

 /* Avoid warnings from gcc -Wcast-function-type.  */
 #  define GetProcAddress \
@@ -94,7 +94,7 @@ gettimeofday (struct timeval *restrict tv, void *restrict
tz)
      <http://www.windowstimestamp.com/description>.  */
   FILETIME current_time;

-# if !(_WIN32_WINNT >= _WIN32_WINNT_WIN8)
+# if (_WIN32_WINNT >= _WIN32_WINNT_WIN8)
   if (!initialized)
     initialize ();
 # endif

[-- Attachment #2: Type: text/html, Size: 2878 bytes --]

Re: gettimeofday.c windows version?

[Bruno Haible]

Roger Pack wrote:
> I received some complaints saying in mingw it was"requiring windows 8" for
> a certain library.
> 
> "Entry point not found, GetSystemTimePreciseAsFileTime could not be located
> in the dynamic link library KERNEL32.dll".

Indeed, according to <https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime>
the function GetSystemTimePreciseAsFileTime is not present in Windows 7 and
older.

Looking at the table at
<https://en.wikipedia.org/wiki/Microsoft_Windows#Timeline_of_releases> I see
that Windows 7 is out of "extended support" already for more than 2 years.
That means, users with such machines (connected to the internet) live very
dangerously.

Eli: What are the current support statements of Emacs regarding Windows
XP/Vista/7 ?
And should Gnulib declare that the minimum supported version of Windows
is Windows 8?

> Perhaps the following patch?  Thanks! :)
> 
> diff --git a/lib/gettimeofday.c b/lib/gettimeofday.c
> index 36c7920af..428cc4f30 100644
> --- a/lib/gettimeofday.c
> +++ b/lib/gettimeofday.c
> @@ -35,7 +35,7 @@
>  # undef LoadLibrary
>  # define LoadLibrary LoadLibraryA
> 
> -# if !(_WIN32_WINNT >= _WIN32_WINNT_WIN8)
> +# if (_WIN32_WINNT >= _WIN32_WINNT_WIN8)
> 
>  /* Avoid warnings from gcc -Wcast-function-type.  */
>  #  define GetProcAddress \
> 

Nope, this patch is not right.

> "Entry point not found, GetSystemTimePreciseAsFileTime could not be located
> in the dynamic link library KERNEL32.dll".

It looks like some code links directly to GetSystemTimePreciseAsFileTime, and
your user is running it under Windows 7 or older.

Which object file is it that links to GetSystemTimePreciseAsFileTime?
 - If it's not gettimeofday.c, it's not in Gnulib's responsibility.
 - If it is gettimeofday.c, this file must have been compiled with a
   _WIN32_WINNT value >= _WIN32_WINNT_WIN8. You need to look in your
   build files where this value come from. Maybe it is even the default
   with your compiler version; if that version is new enough, that would
   make sense.

Bruno

Re: gettimeofday.c windows version?

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: Roger Pack <rogerdpack@gmail.com>, Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 11 Dec 2022 15:22:23 +0100
> 
> Eli: What are the current support statements of Emacs regarding Windows
> XP/Vista/7 ?

Emacs still supports even Windows 9X.  And mingw.org's MinGW does the
same.  Which is why Emacs avoids using Gnulib functions that use APIs
which aren't available on older Windows versions.

> And should Gnulib declare that the minimum supported version of Windows
> is Windows 8?

I hope you won't, but it's your decision.

> > -# if !(_WIN32_WINNT >= _WIN32_WINNT_WIN8)
> > +# if (_WIN32_WINNT >= _WIN32_WINNT_WIN8)
> > 
> >  /* Avoid warnings from gcc -Wcast-function-type.  */
> >  #  define GetProcAddress \
> > 
> 
> Nope, this patch is not right.

Agreed.

> > "Entry point not found, GetSystemTimePreciseAsFileTime could not be located
> > in the dynamic link library KERNEL32.dll".
> 
> It looks like some code links directly to GetSystemTimePreciseAsFileTime, and
> your user is running it under Windows 7 or older.

Yes, most probably.  But doing so is common on Windows.

> Which object file is it that links to GetSystemTimePreciseAsFileTime?
>  - If it's not gettimeofday.c, it's not in Gnulib's responsibility.
>  - If it is gettimeofday.c, this file must have been compiled with a
>    _WIN32_WINNT value >= _WIN32_WINNT_WIN8. You need to look in your
>    build files where this value come from. Maybe it is even the default
>    with your compiler version; if that version is new enough, that would
>    make sense.

I think the code should use a run-time check regardless of the version
of Windows on which the program was compiled.  It makes little sense
to me to require GetSystemTimePreciseAsFileTime because the program
was compiled on a new Windows version when you already have code that
is capable of coping with the lack of that API at run time.

So IMO only the prototype of GetSystemTimePreciseAsFileTime should be
conditioned by the value of _WIN32_WINNT, but the 'initialize'
function should be run on all versions of Windows.

Re: gettimeofday.c windows version?

[Bruno Haible]

Hi Eli,

> Emacs still supports even Windows 9X.  And mingw.org's MinGW does the
> same.  Which is why Emacs avoids using Gnulib functions that use APIs
> which aren't available on older Windows versions.
> 
> > And should Gnulib declare that the minimum supported version of Windows
> > is Windows 8?
> 
> I hope you won't, but it's your decision.

Thanks for your answers.

Well, it's a trade-off regarding the test efforts. I don't want to spend
time, testing things on 5 different Windows VMs. Testing things with
3 different Windows toolchains in 2 different bitnesses is already work
enough.

> 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?

> So IMO only the prototype of GetSystemTimePreciseAsFileTime should be
> conditioned by the value of _WIN32_WINNT, but the 'initialize'
> function should be run on all versions of Windows.

As some point, I want to get rid of the initialize() function and assume
a new enough version of the OS.

For decades we had old cruft in our source code, that tested whether <stdlib.h>
was available, whether 'long long' was available, and so on. This bloats the
code, and with the day this cruft can be removed, the maintenance becomes
simpler. The same holds for backward-compatibility code that does LoadLibrary
and GetProcAddress.

Bruno

Re: gettimeofday.c windows version?

[Eli Zaretskii]

> 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, the prototype of
GetSystemTimePreciseAsFileTime will not be visible, because the
Windows headers hide it.  And since your code already copes with
GetSystemTimePreciseAsFileTime being unavailable, the minimum Windows
version for your code is way lower than Windows 8, it's somewhere in
the Windows 9X area.

> > So IMO only the prototype of GetSystemTimePreciseAsFileTime should be
> > conditioned by the value of _WIN32_WINNT, but the 'initialize'
> > function should be run on all versions of Windows.
> 
> As some point, I want to get rid of the initialize() function and assume
> a new enough version of the OS.

When that happens, Emacs will not be able to use Gnulib's gettime.c
module, sadly.

Re: gettimeofday.c windows version?

[Eli Zaretskii]

> Date: Sun, 11 Dec 2022 18:56:00 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: bug-gnulib@gnu.org, rogerdpack@gmail.com
> 
> > As some point, I want to get rid of the initialize() function and assume
> > a new enough version of the OS.
> 
> When that happens, Emacs will not be able to use Gnulib's gettime.c
> module, sadly.     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I meant on Windows, of course.

Look, this is an old argument, and we've disagreed about it more than
once.  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.

There's no "cruft" in the code we are talking about.  It's valid code,
it is simple, easily understood, and doesn't present any maintenance
burdens.  Why remove it?  Just because Microsoft decided to EOL those
old systems?  The GNU project is supposed to have its own set of
values and considerations about that.  For example, we could consider
the many installations of those old versions in Third World countries
as being important enough for not dropping those systems.  That's what
Emacs does, and I urge Gnulib to do the same.

Re: gettimeofday.c windows version?

[Bruno Haible]

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

Re: gettimeofday.c windows version?

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: bug-gnulib@gnu.org, rogerdpack@gmail.com
> Date: Sun, 11 Dec 2022 19:25:12 +0100
> 
> 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%.

Now consider how many people is that 1% out of India.

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

As one more data point, my main development machine runs Windows XP.
That's where I maintain and develop Emacs, that's where all the
ezwinports ports are produced, that's where I build GDB and Make and
Guile and Texinfo and Gawk -- all of them (and more) available from
the ezwinports site.  Until now I had no problems with compiling any
project which uses Gnulib.  I guess this is about to change.

Re: gettimeofday.c windows version?

[Paul Eggert]

On 2022-12-11 10:55, Eli Zaretskii wrote:
> my main development machine runs Windows XP.

Yeah, it's sort of like the UCLA CS Dept. still operates a Solaris 10 
sparc server that was long the central platform, and I still keep 
porting to it. I expect MS-Windows XP has more users than Solaris 10 
sparc, even though the Solaris 10 is still commercially supported (by 
Oracle) whereas MS-Windows XP is not (by Microsoft). Although few if any 
ordinary users will run Emacs 30+ on either platform, Emacs still keeps 
being ported to them if only to keep the greybeards happy. :-)


That being said, I'm not quite understanding the underlying issue here. 
Is it that MinGW has "#define _WIN32_WINNT 0x502", which as I understand 
from [1] means MinGW says it assumes MS-Windows Server 2003 and later, 
whereas Eli wants Emacs 30+ to be portable even further back to 
MS-Windows XP (i.e., _WIN32_WINNT == 0x0501)? Or is it more complicated 
than that?

If it's merely the abovementioned issue, Gnulib already in some cases 
ports to _WIN32_WINNT <= 0x501 in some cases, so would it be painful for 
it to do so here too? (But then, I haven't seen a specific patch 
proposed that meets Eli's concerns - perhaps I missed it?)

[1]: 
https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt

Re: gettimeofday.c windows version?

[Bruno Haible]

Paul Eggert wrote:
> That being said, I'm not quite understanding the underlying issue here. 
> Is it that MinGW has "#define _WIN32_WINNT 0x502"

As far as I understand it — the reporter has not given much details —, either
he used mingw and set _WIN32_WINNT to 0x602 or newer, or he used MSVC or clang,
not really mingw [1].

Bruno

[1] https://stackoverflow.com/questions/37668692/

Re: gettimeofday.c windows version?

[Eli Zaretskii]

> Date: Sun, 11 Dec 2022 23:17:32 -0800
> Cc: bug-gnulib@gnu.org, rogerdpack@gmail.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> That being said, I'm not quite understanding the underlying issue here. 

I'll try to explain.

> Is it that MinGW has "#define _WIN32_WINNT 0x502", which as I understand 
> from [1] means MinGW says it assumes MS-Windows Server 2003 and later, 
> whereas Eli wants Emacs 30+ to be portable even further back to 
> MS-Windows XP (i.e., _WIN32_WINNT == 0x0501)? Or is it more complicated 
> than that?

First, some background (and please forgive me, you and others, if what
I say is well known).

The Windows system headers that declare Windows specific APIs
(a.k.a. "Win32 APIs") have some of their parts guarded by the likes of

  #if _WIN32_WINNT >= NNNN
  ...
  #endif

These guard the prototypes of the APIs which are only supported in
Windows versions NNNN or higher, and the struct's and macros which
support them.  Thus, compiling a program while _WIN32_WINNT is defined
to a lower value will not see those parts of the system headers, and
at best you will get compilation warnings.  But usually, you can also
link-time errors, because Win32 API functions use the Pascal calling
convention, and the linker cannot resolve the external calls unless it
sees the prototype.  (This is no longer a problem for 64-bit Windows
programs, AFAIK, but 32-bit programs still need the prototype to
successfully link.)

The next piece of this puzzle is that programs which are supposed to
be able to run on a wide variety of Windows versions, some of which do
not support a particular API (because it was introduced starting from
Windows version X), don't call these APIs directly, because calling
them directly will cause the program to refuse to start on older
Windows.  This failure to start happens because dynamic linking on
Windows records in the binary that it must import a given symbol from
a certain shared library, and if that shared library lacks that
symbol, the Windows program loader fails to load the program.  So
instead such programs call these APIs through function pointers, and
populate the pointer at run time by the moral equivalent of
dlopen+dlsym.  If dlsym fails, the program knows that the API is
unavailable, and falls back to other methods, or even flatly rejects
the requests for functionality based on those APIs.  But it does run
and can be functional, albeit only partially so.

However, even these programs with run-time test for the API
availability need the proper prototypes and struct/macro definitions
in order to compile.  So one technique is to temporarily set
_WIN32_WINNT to a higher value than needed during compilation, just to
have the system headers reveal the necessary declarations, and then
still use the "call through function pointer" technique.
Alternatively, the guarded prototypes and macros are manually added to
the program source (this is what gettimeofday.c does).

Paul, you should be able to see this technique in many places in
Emacs, in the w32*.c files, where we call many APIs that are only
available on recent Windows systems.

Now, mingw.org's MinGW has _WIN32_WINNT set to the Windows 9X version
by default, because that's the base target system of that environment.
MinGW64, by contrast, uses Vista or Windows 7 as its base, and doesn't
support older systems.  Moreover, programs that have good reasons
could set _WIN32_WINNT to higher or lower values, as they please.
Thus, the value of _WIN32_WINNT in effect when compiling Gnulib is not
known in advance.  In gettimeofday.c we see code which assumes that a
program that sets _WIN32_WINNT to Windows 8 means that the binary will
only run on Windows 8 and later, so it links directly to an API which
is unavailable on older systems.  If _WIN32_WINNT is set to a lower
value than Windows 8, gettimeofday.c falls back to the technique I
described above: it probes the availability at run time, and prefers
the modern API if it can use it, but uses an older, less accurate API
if the more modern one is unavailable.

Now, to answer your question: my suggestion is not to deliberately
break gettimeofday.c for older systems.  Gnulib already has there what
I consider a superior technique: check the availability of an API at
run time, and use fallback if it is not available.  So forcing
programs which happened to have _WIN32_WINNT defined to Windows 8 or
higher when Gnulib was compiled (which could be for a reason utterly
unrelated to the intended target system of the entire program) to fail
to start on older Windows systems is IMO gratuitous and error-prone.
It is error-prone because the fact that _WIN32_WINNT is set to some
value could be for a reason other than the target system.  And Gnulib
is a library, so it is IMO wrong for it to decide for the applications
on what OS they can and cannot run.

> If it's merely the abovementioned issue, Gnulib already in some cases 
> ports to _WIN32_WINNT <= 0x501 in some cases, so would it be painful for 
> it to do so here too?

As I tried to explain above, just setting _WIN32_WINNT could be due to
reasons other than forcing the lowest version of the target OS.

> (But then, I haven't seen a specific patch 
> proposed that meets Eli's concerns - perhaps I missed it?)

I didn't post a patch, but my suggestion is to remove the #else branch
of this part:

  # if !(_WIN32_WINNT >= _WIN32_WINNT_WIN8)

  /* Avoid warnings from gcc -Wcast-function-type.  */
  #  define GetProcAddress \
      (void *) GetProcAddress

  /* GetSystemTimePreciseAsFileTime was introduced only in Windows 8.  */
  typedef void (WINAPI * GetSystemTimePreciseAsFileTimeFuncType) (FILETIME *lpTime);
  static GetSystemTimePreciseAsFileTimeFuncType GetSystemTimePreciseAsFileTimeFunc = NULL;
  static BOOL initialized = FALSE;

  static void
  initialize (void)
  {
    HMODULE kernel32 = LoadLibrary ("kernel32.dll");
    if (kernel32 != NULL)
      {
	GetSystemTimePreciseAsFileTimeFunc =
	  (GetSystemTimePreciseAsFileTimeFuncType) GetProcAddress (kernel32, "GetSystemTimePreciseAsFileTime");
      }
    initialized = TRUE;
  }

  # else

  #  define GetSystemTimePreciseAsFileTimeFunc GetSystemTimePreciseAsFileTime

  # endif

and make this part unconditional:

  # if !(_WIN32_WINNT >= _WIN32_WINNT_WIN8)
    if (!initialized)
      initialize ();
  # endif

IOW, I suggest to use the cautious run-time test on all versions of
Windows, not only on those older than Windows 8.

Re: gettimeofday.c windows version?

[Bruno Haible]

Eli Zaretskii wrote:
> And Gnulib
> is a library, so it is IMO wrong for it to decide for the applications
> on what OS they can and cannot run.

But Gnulib is a *source-code* library. No one compiles Gnulib binaries
separately from the application binaries. So, the setting of _WIN32_WINNT
that Gnulib source code sees is the same as the one that the surrounding
application sees.

Bruno

Re: gettimeofday.c windows version?

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: bug-gnulib@gnu.org, rogerdpack@gmail.com
> Date: Mon, 12 Dec 2022 15:25:58 +0100
> 
> Eli Zaretskii wrote:
> > And Gnulib
> > is a library, so it is IMO wrong for it to decide for the applications
> > on what OS they can and cannot run.
> 
> But Gnulib is a *source-code* library. No one compiles Gnulib binaries
> separately from the application binaries. So, the setting of _WIN32_WINNT
> that Gnulib source code sees is the same as the one that the surrounding
> application sees.

A program's build could use certain cpp switches for some of its
sources, and other switches for the other sources.  When Gnulib is
compiled, the value could be unrelated to Gnulib, or unrelated to a
particular Gnulib module that is compiled (perhaps some other Gnulib
module needs that for some reason).

(This is one reason why _WIN32_WINNT is in general not a good idea,
IMO.)

Re: gettimeofday.c windows version?

[Gisle Vanem]

Bruno Haible wrote:

> But Gnulib is a *source-code* library. No one compiles Gnulib binaries
> separately from the application binaries.

I build it as a Gnulib.DLL. I know, not supported, but
it can be done. Much better for me in how I use it
in e.g. Wget, etc.

-- 
--gv

Re: gettimeofday.c windows version?

[Paul Eggert]

On 12/12/22 06:40, Eli Zaretskii wrote:
> A program's build could use certain cpp switches for some of its
> sources, and other switches for the other sources.

It should be easy to arrange for Emacs to compile Gnulib source code 
with whatever value of _WIN32_WINNT is appropriate for Gnulib, by 
modifying emacs/lib/Makefile.in appropriately. For example, we could 
leave gettimeofday.c alone add a line like this to Makefile.in:

    ALL_CFLAGS += -D_WIN32_WINNT=_WIN32_WINNT_WINXP

Would something like this address the issue you're thinking of?

> (This is one reason why _WIN32_WINNT is in general not a good idea,

Yes, I see several instances of "#define _WIN32_WINNT 0x..." in Emacs, 
including some temporary ones where _WIN32_WINNT is temporarily set to 
one value and then restored to its original value. I'm hoping similar 
complexity isn't needed in Gnulib.

Currently Gnulib #defines _WIN32_WINNT in three source code files: 
lib/ftruncate.c, lib/sethostname.c, and lib/stat-w32.c. Emacs doesn't 
use any of these files, so they aren't a problem for Emacs. Still, from 
what you say it might make sense for these three files to not #define 
_WIN32_WINNT (not that I know what's going on there, as I don't use 
MS-Windows).

Re: gettimeofday.c windows version?

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 11:44:43 -0800
> Cc: bug-gnulib@gnu.org, rogerdpack@gmail.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 12/12/22 06:40, Eli Zaretskii wrote:
> > A program's build could use certain cpp switches for some of its
> > sources, and other switches for the other sources.
> 
> It should be easy to arrange for Emacs to compile Gnulib source code 
> with whatever value of _WIN32_WINNT is appropriate for Gnulib, by 
> modifying emacs/lib/Makefile.in appropriately. For example, we could 
> leave gettimeofday.c alone add a line like this to Makefile.in:
> 
>     ALL_CFLAGS += -D_WIN32_WINNT=_WIN32_WINNT_WINXP
> 
> Would something like this address the issue you're thinking of?

In this case, yes.

> Currently Gnulib #defines _WIN32_WINNT in three source code files: 
> lib/ftruncate.c, lib/sethostname.c, and lib/stat-w32.c. Emacs doesn't 
> use any of these files, so they aren't a problem for Emacs. Still, from 
> what you say it might make sense for these three files to not #define 
> _WIN32_WINNT (not that I know what's going on there, as I don't use 
> MS-Windows).

The first two indeed want to use APIs that exist only on Windows 2K
and later, although less capable APIs exist on older versions and
could be used.  The last one does something similar to gettimeofday.c,
so it can be made to behave like you suggested above.

Re: gettimeofday.c windows version?

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On 12/12/22 12:37, Eli Zaretskii wrote:
>> It should be easy to arrange for Emacs to compile Gnulib source code
>> with whatever value of _WIN32_WINNT is appropriate for Gnulib, by
>> modifying emacs/lib/Makefile.in appropriately. For example, we could
>> leave gettimeofday.c alone add a line like this to Makefile.in:
>>
>>      ALL_CFLAGS += -D_WIN32_WINNT=_WIN32_WINNT_WINXP
>>
>> Would something like this address the issue you're thinking of?
> In this case, yes.

I looked into doing that in the Emacs source, but discovered that 
emacs/nt/inc/ms-w32.h already does "# define _WIN32_WINNT 0x0400" for 
MinGW so I guess we're OK already as that's even older than 
_WIN32_WINNT_WINXP which is 0x0501. Of course I don't know MS-Windows 
well and so may have missed something.

[-- Attachment #2: Type: text/html, Size: 1224 bytes --]

Re: gettimeofday.c windows version?

[Eli Zaretskii]

> Date: Fri, 16 Dec 2022 15:35:27 -0800
> Cc: bruno@clisp.org, bug-gnulib@gnu.org, rogerdpack@gmail.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 12/12/22 12:37, Eli Zaretskii wrote:
> 
>  It should be easy to arrange for Emacs to compile Gnulib source code 
> with whatever value of _WIN32_WINNT is appropriate for Gnulib, by 
> modifying emacs/lib/Makefile.in appropriately. For example, we could 
> leave gettimeofday.c alone add a line like this to Makefile.in:
> 
>     ALL_CFLAGS += -D_WIN32_WINNT=_WIN32_WINNT_WINXP
> 
> Would something like this address the issue you're thinking of?
> 
> In this case, yes.
> 
> I looked into doing that in the Emacs source, but discovered that emacs/nt/inc/ms-w32.h already does "#
> define _WIN32_WINNT 0x0400" for MinGW so I guess we're OK already as that's even older than
> _WIN32_WINNT_WINXP which is 0x0501. Of course I don't know MS-Windows well and so may have missed
> something.

No, you haven't missed anything.  We are still trying to support
Windows 9X, which is why the low setting of _WIN32_WINNT.

Note that we don't use this low setting for MinGW64, which tossed
support for XP and older versions several years ago anyway.  We only
use this when Emacs is built with mingw.org's MinGW.

Re: gettimeofday.c windows version?

[Roger Pack]

[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]

On Sun, Dec 11, 2022 at 7:22 AM Bruno Haible <bruno@clisp.org> wrote:

> Roger Pack wrote:
> > I received some complaints saying in mingw it was"requiring windows 8"
> for
> > a certain library.
> >
> > "Entry point not found, GetSystemTimePreciseAsFileTime could not be
> located
> > in the dynamic link library KERNEL32.dll".
>
> Indeed, according to <
> https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime
> >
> the function GetSystemTimePreciseAsFileTime is not present in Windows 7 and
> older.
>
> Looking at the table at
> <https://en.wikipedia.org/wiki/Microsoft_Windows#Timeline_of_releases> I
> see
> that Windows 7 is out of "extended support" already for more than 2 years.
> That means, users with such machines (connected to the internet) live very
> dangerously.
>
> Eli: What are the current support statements of Emacs regarding Windows
> XP/Vista/7 ?
> And should Gnulib declare that the minimum supported version of Windows
> is Windows 8?
>
> > Perhaps the following patch?  Thanks! :)
> >
> > diff --git a/lib/gettimeofday.c b/lib/gettimeofday.c
> > index 36c7920af..428cc4f30 100644
> > --- a/lib/gettimeofday.c
> > +++ b/lib/gettimeofday.c
> > @@ -35,7 +35,7 @@
> >  # undef LoadLibrary
> >  # define LoadLibrary LoadLibraryA
> >
> > -# if !(_WIN32_WINNT >= _WIN32_WINNT_WIN8)
> > +# if (_WIN32_WINNT >= _WIN32_WINNT_WIN8)
> >
> >  /* Avoid warnings from gcc -Wcast-function-type.  */
> >  #  define GetProcAddress \
> >
>
> Nope, this patch is not right.
>
> > "Entry point not found, GetSystemTimePreciseAsFileTime could not be
> located
> > in the dynamic link library KERNEL32.dll".
>
> It looks like some code links directly to GetSystemTimePreciseAsFileTime,
> and
> your user is running it under Windows 7 or older.
>
> Which object file is it that links to GetSystemTimePreciseAsFileTime?
>  - If it's not gettimeofday.c, it's not in Gnulib's responsibility.
>  - If it is gettimeofday.c, this file must have been compiled with a
>    _WIN32_WINNT value >= _WIN32_WINNT_WIN8. You need to look in your
>    build files where this value come from. Maybe it is even the default
>    with your compiler version; if that version is new enough, that would
>    make sense.
>

OK it appears newer mingw have a default target of windows 10 for some
reason.  gnutls embedded in this case:
$ x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../..   -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=0  -mtune=generic -O3 -MT gettimeofday.o -MD -MP -MF
$depbase.Tpo -c -o - -dM -E gettimeofday.c | grep WIN32_WINNT
#define _WIN32_WINNT 0xa00
https://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg18212.html

Maybe instead it could always call initialize and "prefer"
GetSystemTimePreciseAsFileTime, then be compatible with < windows 8 without
having to manually set _WIN32_WINNT.
Basically everything using Gnulib gettimeofday + mingw today might
"accidentally" lose windows 7 compat without realizing it.  Though I guess
you could call that Mingw's fault, it was a bit confusing.
Thanks, Merry Christmas!

[-- Attachment #2: Type: text/html, Size: 4255 bytes --]

Re: gettimeofday.c windows version?

[Eli Zaretskii]

> From: Roger Pack <rogerdpack@gmail.com>
> Date: Fri, 23 Dec 2022 01:38:01 -0700
> Cc: bug-gnulib@gnu.org, Eli Zaretskii <eliz@gnu.org>
> 
> OK it appears newer mingw have a default target of windows 10 for some reason.  gnutls embedded in this
> case:
> $ x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../..   -U_FORTIFY_SOURCE
> -D_FORTIFY_SOURCE=0  -mtune=generic -O3 -MT gettimeofday.o -MD -MP -MF $depbase.Tpo -c -o - -dM
> -E gettimeofday.c | grep WIN32_WINNT
> #define _WIN32_WINNT 0xa00
> https://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg18212.html
> 
> Maybe instead it could always call initialize and "prefer" GetSystemTimePreciseAsFileTime, then be
> compatible with < windows 8 without having to manually set _WIN32_WINNT.

That's what I suggested: to remove the compile-time test, and always
call GetSystemTimePreciseAsFileTime via a function pointer, testing
whether it's supported at run time.  I'm not sure Bruno agreed,
though.

> Basically everything using Gnulib gettimeofday + mingw today might "accidentally" lose windows 7 compat
> without realizing it.  Though I guess you could call that Mingw's fault, it was a bit confusing.

I guess MinGW64 and MSYS2 are following Cygwin or Microsoft in
dropping old Windows version too quickly.  You are welcome to lobby
those two to be less radical, although I'm unsure what are the chances
of that to succeed.

Re: gettimeofday.c windows version?

[Paul Eggert]

On 12/23/22 00:38, Roger Pack wrote:
> $ x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../..   -U_FORTIFY_SOURCE
> -D_FORTIFY_SOURCE=0  -mtune=generic -O3 -MT gettimeofday.o -MD -MP -MF
> $depbase.Tpo -c -o - -dM -E gettimeofday.c | grep WIN32_WINNT
> #define _WIN32_WINNT 0xa00
> https://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg18212.html

If this is from a build of vanilla Gnulib, that's OK: Gnulib is merely 
following MingW's lead and if MingW defaults to MS-Windows 10 then 
that'll be the default in Gnulib too.

If this is from an Emacs build then I suggest tracking down why Emacs 
isn't defining _WIN32_WINNT to a value appropriate for Emacs and MingW. 
nt/inc/ms-w32.h has a "#define _WIN32_WINNT 0x0400" that should be 
overriding the MingW default.

Re: gettimeofday.c windows version?

[Eli Zaretskii]

> Date: Fri, 23 Dec 2022 15:47:27 -0800
> Cc: bug-gnulib@gnu.org, Eli Zaretskii <eliz@gnu.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> nt/inc/ms-w32.h has a "#define _WIN32_WINNT 0x0400" that should be 
> overriding the MingW default.

We do this only for mingw.org's MinGW, not for MinGW64 (where we don't
change the default value).

Re: gettimeofday.c windows version?

[Paul Eggert]

On 12/23/22 22:46, Eli Zaretskii wrote:
> We do this only for mingw.org's MinGW, not for MinGW64 (where we don't
> change the default value).

Oh. How about if we do it for MinGW64 too? Wouldn't that support 64-bit 
Emacs builds on obsolete MS-Windows platforms? Not being an MS-Windows 
expert I'm hesitant to propose an exact patch, but the general idea 
should work.

Another option would be to say that if you want to run Emacs on 
MS-Windows no longer supported by Microsoft, you need to do a 32-bit build.

Re: gettimeofday.c windows version?

[Eli Zaretskii]

> Date: Fri, 23 Dec 2022 23:42:52 -0800
> Cc: rogerdpack@gmail.com, bruno@clisp.org, bug-gnulib@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 12/23/22 22:46, Eli Zaretskii wrote:
> > We do this only for mingw.org's MinGW, not for MinGW64 (where we don't
> > change the default value).
> 
> Oh. How about if we do it for MinGW64 too? Wouldn't that support 64-bit 
> Emacs builds on obsolete MS-Windows platforms? Not being an MS-Windows 
> expert I'm hesitant to propose an exact patch, but the general idea 
> should work.

It's AFAIK meaningless to do that for MinGW64, since they dropped
support of all versions of Windows older than 8, and I hear they will
drop Windows 8 as well soon (or already did?).

> Another option would be to say that if you want to run Emacs on 
> MS-Windows no longer supported by Microsoft, you need to do a 32-bit build.

That is indeed the best alternative, since it is being constantly
tested (by yours truly).