On 3/4/19 3:03 PM, Paul Gofman wrote:
Hello Jacek,
so far I grepped the source tree for the WriteFile. This was supposed to show me WriteFileEx and NtWriteFile calls too. If LPOVERLAPPED (the last parameter to WriteFile) is NULL, WriteFile is going to fail with async file handles (at least for regular / serial / device files) regardless of actual sync or async.
Why would WriteFile with NULL overlapped fail? It will wait on provided handle, which is suboptimal, but it should work. Anyway, it's fine to skip those cases in your case.
After skipping the calls which supply NULL (or 0, or FALSE like source in programs/ often does) for overlapped structure, here is what left:
- ole32/rpc.c, local_server_thread(): works on pipe, passes overlapped
structure and calls GetOverlappedResult() uncodintionally after;
- user.exe16/comm.c, COMM16_WriteFile(): passes OV structure, calls
GetOverlappedResult() if GetLastError()==ERROR_IO_PENDING
- programs/services/rpc.c, process_send_command(): passes OV
structure, then processes GetLastError()==ERROR_IO_PENDING.
Sounds good, thanks.
Do you think it makes sense if I proceed to change ntdll tests as described before (marking pre-Vista behaviour as invalid) and then resend the patch concerning NtWriteFile() with the async return for regular files only?
Mostly yes. I'm not sure about doing this only for regular files, through. I know it addresses my concern, but your testing seems to indicate that it's pipes that are unusual and, as far as I understand, all other tested types return STATUS_PENDING. If that's the case, maybe we should return STATUS_PENDING without depending on handle type?
Thanks,
Jacek