Re: MPS: Win64 testers?

[Pip Cet <pipcet@protonmail.com>]

On Sunday, July 28th, 2024 at 05:25, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Sat, 27 Jul 2024 20:22:34 +0000
> > From: Pip Cet pipcet@protonmail.com
> > Cc: emacs-devel@gnu.org
> > It's been that way since 2004, if the git history is to be believed.
> 
> I guess they have some unsolved issues with the standard streams,
> which is why they don't dare reusing their slots. Which means closing
> these standard streams is a no-no on Wine.

I don't know. I suspect they just never thought (20 years ago!) that anyone would want to close a standard stream. Any idea what UCRT does?

> But if this is what Wine does, then what do you get from the various
> fprintf debugging code in Emacs? For example, if you build with the
> "--enable-checking='yes,glyphs'" option, you get the trace-redisplay
> command which outputs debugging information about redisplay to stderr,
> and also the dump-glyph-matrix command which prints the glyph matrix
> to stderr. Do these print-outs still work although stderr was closed
> in init_ntproc?

I tried with GDB, and fprintf(stderr, ...) stops working in init_ntproc.

> Or maybe under Wine closing a standard stream has no effect, and the
> stream remains open? But then why does close_output_streams reports
> errors?

The FILE object remains assigned to its FD but loses its writable/readable flag, so fwrite returns -1/EBADF.  fclose() returns -1 (though it's spelled EOF in the source code) and doesn't set errno.

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);

The version information for availability of "SetHandleInformation" and "DuplicateHandle" is the same, so any idea why we're not just doing that, or is it just lost in history?

Pip