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.