Re: MPS: Win64 testers?

[Pip Cet <pipcet@protonmail.com>]

On Sunday, July 28th, 2024 at 15:20, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Sun, 28 Jul 2024 15:00:52 +0000
> 
> > From: Pip Cet pipcet@protonmail.com
> > Cc: emacs-devel@gnu.org, "rms@gnu.org" rms@gnu.org
> > 
> > > It seems to be doing the same as MSVCRT, at least if the UCRT sources
> > > available out there are to be believed.
> > 
> > By my reading of the source code I found, it's doing the same as Wine, not as MSVCRT.
> 
> If someone steps through that code in the UCRT build and reports that
> fdopen returns a different FILE pointer, I will believe you.

I've verified this by running a GitHub action (I won't provide a link because it's probably impossible to use without running proprietary GitHub JavaScript), though I couldn't work out how to make clang link against msvcrt rather than its own libraries.

The result of 

  printf("%p\n", stdin);
  fclose(stdin);
  int fd = _open ("nul", _O_RDWR);
  printf("%d = 0\n", fd);
  FILE *f = _fdopen (fd, "r");
  printf("%p = %p\n", stdin, f);
  return 0;

is, for a MINGW32-built msvcrt binary on windows-latest:

  761f7600
  0 = 0
  761f7600 = 761f7600

but, for a UCRT64-built ucrt binary on windows-latest:

  00007FF8E7E9E4A0
  0 = 0
  00007FF8E7E9E4A0 = 000001F74AFF5660

> > > Is there any way for a program running on Wine to detect that this is
> > > what happens? like some special version number or something? If so,
> > > I'd just avoid all that code in init_ntproc on Wine, since leaving the
> > > standard streams inheritable is a much smaller trouble than losing the
> > > standard streams.
> > 
> > I don't think we should have Wine-specific workarounds, particularly not for such questionable code. IIUC, Wine discourages attempts of programs to detect whether they're running on Wine or Microsoft Windows.
> 
> 
> We don't have to behave like Wine intends us to behave. We have our
> own considerations. So I don't really care whether Wine endorses
> detection of Wine, if we decide we need that.

Let's see whether the Wine people want to provide bug-for-bug compatibility in this case first?

> > > > As for the code in question, if I understand it correctly, the current Windows idiom would be simply (I assume _open_osfhandle clears the flag?):
> > > > 
> > > > SetHandleInformation (GetStdHandle (STD_INPUT_HANDLE), HANDLE_FLAG_INHERIT, 0);
> > > 
> > > I'm not sure you can do this without closing the stream, since the
> > > program has already started by that time. And SetHandleInformation is
> > > only available since Windows 2K, so we'd need to call it through a
> > > function pointer.
> > 
> > Thanks. Microsoft doesn't appear to provide version information pre-Windows-2000...
> 
> I use this resource to overcome the deficiencies of the official docs:
> 
> http://winapi.freetechsecrets.com/win32/

Thanks for the link!

> > > Not sure if that is justified just to support Wine
> > 
> > And UCRT, if and when the time comes.
> 
> If that's the same problem, which we are not yet sure.

Of course.

> And, as I
> said, support for UCRT will only become official if someone volunteers
> to come on board and handle that build.

That's what I meant by "if and when the time comes".

> > And any other implementation of the Windows API that doesn't provide bug-for-bug compatibility with MSVCRT.
>
> For now, only the MSVCRT support is official.

Of course, and I think it's more likely it will cease being official than other builds becoming official.

> > Wine is the only significant free implementation of the Windows API, so I disagree with the "just". If I understand RMS correctly, whether there is a free implementation of an OS is an important factor in deciding to redirect resources to supporting it in GNU software.
>  
> Such decisions can only be relevant if there are resources to allocate
> and redirect.

I think the community of Emacs developers decides by consensus (or bickering) what to work on. My understanding was that we're considering whether to stop working on at least some variants of the Windows port.

> Since we don't have them, this is entirely academic.

Well, I disagree. Official guidance by the GNU Emacs project does have some influence on what volunteers will work on. I consider that a resource.

> For now, the only person who actively works on the Windows port is
> myself, and I'm unable to support UCRT, for more than one reason.

Are you working on MINGW64 systems at all, or is it mingw exclusively?

Pip