[Bug 42982] Bayonetta can`t save settings

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=42982

--- Comment #22 from mrdeathjr28 at 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

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.