Re: MPS: Win64 testers?

[Eli Zaretskii]

> Date: Sat, 03 Aug 2024 07:50:21 +0000
> From: pipcet@protonmail.com
> Cc: emacs-devel@gnu.org, rms@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >> Date: Wed, 31 Jul 2024 06:18:16 +0000
> >> From: Pip Cet <pipcet@protonmail.com>
> >> Cc: emacs-devel@gnu.org, rms@gnu.org
> >>
> >> > 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.
> >
> > I disagree.
> 
> If you disagree that it relies on details that aren't guaranteed by the
> API, can you provide an API reference that backs you up?

I disagree that the bar is lower than what I described.  The existing
code relies on undocumented features, yes, but we have quite a lot of
that in the Windows and MSDOS ports, and there's nothing in particular
wrong with that.  When the undocumented features stop working in some
situations, we need to find a solution for those situations, and those
solutions must be tested within Emacs, not a toy test program, and
they must be tested thoroughly, including (in this case) the
verification that the handle is not inherited by Emacs sub-processes.

> >> 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.
> >
> > Which bugs where "closed as wontfix without a sensible explanation"?
> 
> 72335

That bug is not closed.

> >> > 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.
> >
> > We have been advertising MinGW64 (with MSVCRT) for a long time, see
> > nt/INSTALL.W64.  But since it doesn't support Windows versions older
> > than Vista (or maybe even that is not supported anymore), we also
> > advertise MinGW, which does.
> 
> Indeed, but people look at nt/INSTALL first, usually

If they read it, it tells them that those instructions are for older
versions of Windows.

> and that's about an entirely different port which hardly anyone
> considers usable at this point, as far as I can tell.

It isn't an entirely different port, no.  The code commonality between
the two is close to 100%, and so is the functionality, the only
difference is that one is 32-bit, the other 64-bit.