https://bugs.winehq.org/show_bug.cgi?id=42982
--- Comment #22 from mrdeathjr28@yahoo.es --- (In reply to Chebanenko Igor from comment #21)
(In reply to mrdeathjr28 from comment #20)
Hi and thanks for your patch
I can test but until julliard approve patch
Test your game in Wine 4.3
Sadly two keystones patchs dont stay:
https://source.winehq.org/patches/data/158920
https://source.winehq.org/patches/data/158921
This is discussion between paul gofman and jacek kaban respect this patch:
On 2/26/19 7:45 PM, Paul Gofman wrote:
Hello Jacek,
On 2/26/19 17:23, Jacek Caban wrote:
While it generally looks like Vista+ indeed returns STATUS_PENDING in quite a lot of situations, doing it always in all cases is probably not the right thing. For example, read()/write() on overlapped named pipes does not return STATUS_PENDING if the request may be completed immediately. Although named pipe read/write use different code path in Wine, the general concern remains: we can't assume that Windows does that unconditionally for all all overlapped requests.
Do you think this can be considered for regular files?
I don't know, is STATUS_PENDING specific to regular files?
Ignoring fd type in my patch is definitely a mistake. The motivation under this are applications which now sometimes strictly expect async status when reading / writing regular files asynchronously (they are not XP compatible of course). Is it absolutely no go to make this behaviour dependant on defined win version?
If it can be avoided, yes. I think we should carefully change it to STATUS_PENDING because we have an evidence that some applications need it. We don't know if anything will break.
Also note that such change may need throughout review of Wine to make sure that we don't depend on pre-Vista behaviour in our code. read()/write() should be safer, but I've seen STATUS_PENDING returned from ioctl()s as well (even on pipes), and changing that would surely break kernel32 code.
I can search for it. Hopefully this is not so common case to request an overlapped file IO and then always expect sync results.
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.
Jacek