[PATCH v3 4/5] ntdll: Return STATUS_PENDING from NtWriteFile() for async write.

[Jacek Caban]

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