https://bugs.winehq.org/show_bug.cgi?id=31954
--- Comment #39 from Chebanenko Igor chebanenkoigor93@gmail.com --- (In reply to Paul Gofman from comment #38)
I've got some more details now after more testing, it looks like sync or async result for read and write differs between Windows versions and preconditions (likely by the data availability in cache). But when the file is created with FILE_FLAG_NO_BUFFERING (which I checked is actually the case for Second Sight demo), it looks like async return is consistent. I refined my patch this way and going to suggest it upstream with the test.
The patch "Alternative 1" from Bug 42982 looks incorrect to me in a sense that non-zero overlapped parameter in kernel32.ReadFile() does not imply async read. Really "overlapped" read is requested by FILE_FLAG_OVERLAPPED given to CreateFile(), otherwise this parameter can be just used to specify position for sync read. Regarding doing the read really asynchronous, I suppose it is completely distinct change which most likely would benefit from some heuristics when it is worth doing.
Looks like it will help:
https://support.microsoft.com/ru-ru/help/156932/asynchronous-disk-i-o-appear...