Windows: Prefer `ntdll` named pipe APIs over `kernel32`

[The-King-of-Toasters]

CreatePipe and CreateNamedPipe are used by child_process to... create anonymous and named pipes for redirecting i/o. From my research, these are abstractions around NtCreateNamedPipeFile and NtOpenFile for the writing end. As per #1840, we should prefer using these APIs over kernel32 ones.

CreatePipe

Here is wine's implementation. Using NtTrace we see the same calls being made, just out of order:

Example Program

```zig var in: HANDLE = undefined; var out: HANDLE = undefined; const res = CreatePipe(&in, &out, null, 1024); if (res == 0) std.debug.panic("huh, {}", .{kernel32.GetLastError()}); defer { std.os.close(in); std.os.close(out); } ```

NtOpenFile( FileHandle=0x7ff8c4c2b114 [0x00841f0fc32ecdcc], DesiredAccess=READ_CONTROL|WRITE_OWNER|SYNCHRONIZE|GENERIC_READ|GENERIC_WRITE|0x800258, ObjectAttributes="\Device\NamedPipe\", IoStatusBlock=0x153fcb0 [0/1], ShareAccess=3, OpenOptions=0x20 ) => 0
NtCreateNamedPipeFile( NamedPipeHandle=0x7ff8c4c2c1d4 [0x00841f0fc32ecdcc], DesiredAccess=READ_CONTROL|WRITE_OWNER|SYNCHRONIZE|GENERIC_READ|GENERIC_WRITE|0x800434, ObjectAttributes=0xf4:"", IoStatusBlock=0x153fcb0 [0/2], ShareAccess=3, CreateDisposition=2, CreateOptions=0x20, MessageType=false, MessageRead=false, NonBlocking=false, MaxInstances=1, InBufferSize=0x400, OutBufferSize=0x400, Timeout=0x153fca0 [-1.2e+09] ) => 0
NtOpenFile( FileHandle=0x7ff8c4c2b114 [0x00841f0fc32ecdcc], DesiredAccess=READ_CONTROL|WRITE_OWNER|SYNCHRONIZE|GENERIC_READ|GENERIC_WRITE|0x800258, ObjectAttributes=0xf8:"", IoStatusBlock=0x153fcb0 [0/1], ShareAccess=3, OpenOptions=0x60 ) => 0
NtClose( Handle=0x00007ff8c4c2ac94 ) => 0
NtClose( Handle=0x00007ff8c4c2ac94 ) => 0

Some improvements we could make:

• Use an atomic int for the pipe number; Removes the need for looping.
• Replace FALSE/0 with proper constants (e.g. FILE_PIPE_BYTE_STREAM_MODE).

Not that I cannot find these pipes under the pipe device directory (ls \\.\pipe\ in powershell), unlike proper named pipes.

CreateNamedPipe

Again, here is Wine's impl and a trace log.

Sample

```zig const file = std.unicode.utf8ToUtf16LeStringLiteral("\\\\.\\pipe\\my_pipe"); const read_handle = windows.kernel32.CreateNamedPipeW( file.ptr, windows.PIPE_ACCESS_INBOUND | windows.FILE_FLAG_OVERLAPPED, windows.PIPE_TYPE_BYTE, 1, 4096, 4096, 0, null, ); defer std.os.close(read_handle); ```

NtCreateNamedPipeFile( NamedPipeHandle=0x7ff8c4c2c1d4 [0x00841f0fc32ecdcc], DesiredAccess=READ_CONTROL|WRITE_OWNER|SYNCHRONIZE|GENERIC_READ|GENERIC_WRITE|0x800434, ObjectAttributes="\??\pipe\my_pipe", IoStatusBlock=0x14cfc78 [0/2], ShareAccess=2, CreateDisposition=3, CreateOptions=0, MessageType=false, MessageRead=false, NonBlocking=false, MaxInstances=1, InBufferSize=0x1000, OutBufferSize=0x1000, Timeout=0x14cfc20 [-500000] ) => 0
NtClose( Handle=0x00007ff8c4c2ac94 ) => 0

Pretty close to the real thing.

[The-King-of-Toasters]

I have a prototype of a CreatePipe impl that uses the Native API, works great when single-threaded. Unfortunately everything fails hard when using it via the zig build runner. I'll put it up on a draft PR and hopefully I can crack this case; my windbg-foo is failing me.

Edit: I'm silly and passed the wrong flags.