Conversation
lhecker
added
the
Product-Conpty
| __assume(overlapped->hEvent != nullptr); | ||
| __assume(bytesTransferred != nullptr); | ||
|
|
||
| if (overlapped->Internal == STATUS_PENDING) |
There was a problem hiding this comment.
Internal - is this documented anywhere?
There was a problem hiding this comment.
Yep: https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-overlapped
It does say "its behavior may change" but I think that's a minor concern for us, given that we're effectively a system component. It also hasn't changed since "Windows NT 1.0" (I honestly don't know but basically since forever). The reason it's unlikely to change is because the two Internal fields overlap with NT's IO_STATUS_BLOCK struct, whose 2 fields are publicly documented and don't mention this "its behavior may change".
| // API doesn't have a parameter where you could pass FILE_FLAG_OVERLAPPED! | ||
| // So, we'll simply use the underlying NT APIs instead. | ||
| // | ||
| // Most code on the internet suggests creating named pipes with a random name, |
There was a problem hiding this comment.
can you point to official docs explaining why we can do this safely and above-board?
There was a problem hiding this comment.
You mean why we can safely create a pipe without a name, now and in the future? Outside of the function description, there are no official docs about how NPFS works, both publicly and internally. It basically works "as designed". I believe it's safe to rely on it for 2 reasons:
- NPFS last changed in Windows Vista
- There are no filter driver events for the creation of anonymous pipes. The only way to know about them is by subscribing to
FO_NAMED_PIPEand testing for the name length. Anonymous pipes have an empty name. This effectively makes it a public contract.
Split off from microsoft#17510: * `HandleWantsOverlappedIo` can be used to check if a handle requires overlapped IO. This is important, as `ReadFile` and `WriteFile` are documented to not work correctly if an overlapped handle is used without overlapped IO and vice versa. In my tests with pipes, this appears to be true. * `CreatePipe` creates a synchronous, unidirectional pipe. * `CreateOverlappedPipe` does what it says on the tin, while allowing you to specify the direction of the pipe (in, out, duplex). * `GetOverlappedResultSameThread` is largely the same as `GetOverlappedResult`, but adds back a neat optimization from the time before Windows 7. I thought it was neat.
3 participants
Split off from #17510:
HandleWantsOverlappedIocan be used to check if a handle requiresoverlapped IO. This is important, as
ReadFileandWriteFilearedocumented to not work correctly if an overlapped handle is used
without overlapped IO and vice versa.
In my tests with pipes, this appears to be true.
CreatePipecreates a synchronous, unidirectional pipe.CreateOverlappedPipedoes what it says on the tin, while allowingyou to specify the direction of the pipe (in, out, duplex).
GetOverlappedResultSameThreadis largely the same asGetOverlappedResult, but adds back a neat optimization fromthe time before Windows 7. I thought it was neat.