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

[Paul Gofman]

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