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

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

---
Kien