[PATCH v3 4/5] ntdll: Return STATUS_PENDING from NtWriteFile() for async write.
gofmanp at gmail.com
Tue Feb 26 12:45:42 CST 2019
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? 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?
> That said, I think it needs more investigation. I know that our tests
> may not be great to check that as they accept both pre-Vista and
> Vista+ behaviour as valid, but maybe marking pre-Vista results as
> broken() would be a good start so that we can see an evidence that
> it's a correct thing to do (depending on outcome, those broken()s are
> may or may not be something we want in Wine, but it would surely be
> useful for investigation).
Yes, sure, I can mark those tests.
> 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 information about the wine-devel