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

[Paul Gofman]

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

     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?

Thanks,
     Paul.

On 2/27/19 23:16, Paul Gofman wrote:
> On 2/27/19 21:28, Jacek Caban wrote:
>>
>>
>> I don't know, is STATUS_PENDING specific to regular files?
>>
> No, it is not specific. ntdll read / write can aleady return either 
> _PENDING or _SUCCESS for special files, depending on whether the 
> operation is actually performed asynchronously. But regular file 
> operations are currently never queued asynchronously in Wine. In the 
> bugs I am aware of the application expects _PENDING just for regular 
> files. I suppose it is not something to be unified across different 
> file handle types. If you agree with that it is probably much easier 
> to deal with regular files without relation to other cases.
>>
>>
>> More like a code that calls ReadFile on a handle passed from an 
>> application that happens to be overlapped. Or overlapped file handle 
>> is created by accident, since with current code it doesn't matter for 
>> file handles. Anyway, it doesn't seem likely.
>>
>>
>>
> I think I can grep for read / write file calls and check cases which 
> seem suspicious in this regard. The amount of read / write calls must 
> be huge but hopefully there are limited number of places where 
> _OVERLAPPED is used explicitly or read / write on app provided handle 
> is used.
>
>