Re: MPS: Win64 testers?

[pipcet]

"Eli Zaretskii" <eliz@gnu.org> writes:

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

Thank you. I think I finally understand your position.

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

Oh, I see. You're right, I should have said "marked as wontfix". Thanks
for correcting me.

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

I think a typical user will look at INSTALL first, which directs them to
nt/INSTALL, which finally directs them to the file they were looking for
in the first place, if they know enough to realize that MinGW and
MinGW64 are different things. I think skipping one of those files would
be a good thing, and increase the probability of successful builds.

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

What I meant was that building according to the nt/INSTALL instructions
will produce something people won't be happy with, with very rare
exceptions, because it uses an entirely different toolchain, produces a
32-bit binary, and doesn't support as many features for a naive build
(such as native compilation).

As for the test person issue, would it be possible to start a new thread
on emacs-devel with a detailed call for volunteers for testing Emacs on
64-bit versions of Microsoft Windows? I think it would be great if we
could make it clear to people that support for such systems is dependent
on someone volunteering to test a provided ZIP file once in a while
(maybe we can limit ourselves to one test per week or so), running a few
lines of elisp but mostly reporting back on whether bin/emacs.exe
starts up at all.

Maybe it would also help to offer people the chance to respond by
private email rather than on the list?

What do you think?

Pip