Re: MPS: Win64 testers?

[Pip Cet <pipcet@protonmail.com>]

On Monday, July 29th, 2024 at 11:25, Eli Zaretskii <eliz@gnu.org> wrote:
> > 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.

I think the bar is slightly lower than that: the code in Emacs is clearly buggy, because it relies on strange and peculiar implementation details that go far beyond anything guaranteed by the API (and that may break at any point on new systems). Replacing it is necessary.

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

This isn't UCRT-specific, and, as far as I'm concerned, "the actual platform" is Wine, not Microsoft Windows. If a UCRT build works on wine, it's quite likely to work on Microsoft Windows machines, too.

> IOW, this needs a
> dedicated support person.

That's desirable, yes, but hardly necessary. There's a difference between fixing obvious bugs that will prevent builds from ever working and deciding a platform is "officially" supported.

FWIW, I've tested my UCRT build on Microsoft's proprietary Windows, briefly, and it starts up and appears to work. However, I cannot do so on a regular basis.

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

One thing we can certainly stop doing is to discourage people from even looking at stuff. Closing actual bugs as "wontfix" without a sensible explanation, for example, seems counterproductive to me.

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

Maybe it's time to make that port unofficial, or at least to stop directing people to it rather than the MinGW64 port.

Pip