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

[Jacek Caban]

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