Re: MPS: Win64 testers?

[Eli Zaretskii]

> From: Quang Kien Nguyen <kien.n.quang@gmail.com>
> Date: Wed, 7 Aug 2024 11:32:23 -0700
> Cc: emacs-devel@gnu.org, pipcet@protonmail.com
> 
> > This is not what I think we need.  First, there's no need to change
> > anything in the MSVCRT build, because AFAIK the current code "just
> > works" in such a build, both in 32-bit builds and in 64-bit builds.
> > The problem happens only in UCRT builds.
> 
> Okay, put a new patch.

Thanks, this patch LGTM.  Given sufficient testing (see below), I
think we can install it.

> By the way, the code of using `pfn_SetHandleInformation` has been using by
> `init_winsock` as well for the same purpose of making the handle not
> inheritable.  So I think we should be pretty safe with this change.

Contrary to what happens on Posix platforms, winsock handles are
similar, but different from file handles.  So much so that using
socket handles and respective file descriptors in Posix-style calls
like 'write' cannot be done without some non-trivial jumping through
hoops.

So the fact that we use SetHandleInformation for sockets doesn't
necessarily mean we should copy the code to file handles just because
we can.

In general, Windows support code in Emacs is tricky and there's more
in it than meets the eye, so based on long and hard-won experience I
submit that we should only change it if and when it breaks, and
preferably only for situations in which it breaks.

> > To test that, one would need to demonstrate that the parent Emacs
> > process can do something with its standard handles without affecting
> > the same handles of the child process.  For example, moving the file
> > pointer in one process doesn't move it in the other.  As another
> > example, if Emacs's standard output is redirected to a file, and
> > writing to stdout in the child process writes to that same file, then
> > the standard output handle _was_ inherited.  Yet another possibility
> > is to use a tool such as ProcessExplorer to show the target of each
> > handle, in both parent Emacs and its child sub-process, and verify the
> > target is different.
> 
> I'm not sure how to redirect Emacs output in Windows.

?? As usual: you invoke Emacs from a cmd window with redirection.  For
example:

    c:\>emacs > output.txt
or
    c:\>emacs 2> error.txt

You can then launch a child process which writes to stdout/stderr and
see that Emacs and the child process do not write to the same file.

> And using ProcExp64, I can confirm that the standard handles
> (\Device\ConDrv\Input ...) is not refereed by its child processes.
> Let me know if you want me test other scenarios.

What ProcExp64 shows is a good sign, but I'd prefer to test also some
redirection like above, with Emacs and the sub-process both writing to
the same stdout/stderr stream, which would allow to verify positively
that they write to different places.

Thanks.