Re: MPS: Win64 testers?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 28 Jul 2024 20:22:40 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: emacs-devel@gnu.org, rms@gnu.org
> 
> On Sunday, July 28th, 2024 at 15:20, Eli Zaretskii <eliz@gnu.org> wrote:
> > > 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.

Thanks, but this is just a first small step in the right direction.
We need this verified with Emacs, not a small separate test program,
and we need then some serious testing of whatever solution we decide
to implement.  All of that requires a volunteer who will take upon
him/herself to implement and test the possible solutions on the actual
platform, and then maintaining that and the rest of UCRT-specific
stuff for some reasonably observable future.  IOW, this needs a
dedicated support person.

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

The community of Emacs developers cannot allocate resources that don't
exist.  And even when they do exist, the ability of the community to
redirect those resources is limited by the opinions and limitations of
the people whose resources need to be redirected.

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

I'm around for enough time to know that it is almost never a resource
we can control.  And the effectiveness of such guidance is severely
limited even in easier cases, see the recent arguments about naming
packages and similar stuff.

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

I'm using MinGW and don't intend to install MinGW64 any time soon.
And, as I said earlier on the list, even supporting the MSVCRT build
is becoming too much if I have to do that alone, together with my main
responsibilities here.