August 2023 - wine-gitlab

Re: [PATCH v3 0/1] MR3504: ntdll: Handle invalid locks in ReleaseSRWLockExclusive.
by Yuxuan Shui (＠yshui) 03 Aug '23

03 Aug '23

On Thu Aug 3 16:09:52 2023 +0000, Zebediah Figura wrote: > > I feel that is a bit overkill for a single application, which is using > the lock in an invalid way anyway. > Maybe, but I don't like the way this patch basically feels like it's > hacking around the current behaviour. > I'd also assert that "invalid" is often not a very meaningful word when > it comes to Wine. There's documented API, sure, but programs making > assumptions about internals is commonplace, and something that's pretty > much always been within Wine's scope to fix. Yes, what you said makes sense. > something that's pretty much always been within Wine's scope to fix. I want to assure you I 100% understand that. After all, this MR is exactly trying to fix such a case. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_41253

1 0

Re: [PATCH v3 0/1] MR3504: ntdll: Handle invalid locks in ReleaseSRWLockExclusive.
by Zebediah Figura (＠zfigura) 03 Aug '23

03 Aug '23

> I feel that is a bit overkill for a single application, which is using the lock in an invalid way anyway. Maybe, but I don't like the way this patch basically feels like it's hacking around the current behaviour. I'd also assert that "invalid" is often not a very meaningful word when it comes to Wine. There's documented API, sure, but programs making assumptions about internals is commonplace, and something that's pretty much always been within Wine's scope to fix. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_41252

1 0

[PATCH v5 0/4] MR3351: mfmediaengine: Implement RemoveAllEffects().
by Bernhard Kölbl (＠besentv) 03 Aug '23

03 Aug '23

-- v5: mfmediaengine: Implement RemoveAllEffects(). mfmediaengine/tests: Add tests for RemoveAllEffects(). mfmediaengine/tests: Make ref checks more consistent. winegstreamer: Leave media source critical section before unlocking workqueue. https://gitlab.winehq.org/wine/wine/-/merge_requests/3351

3 8

Re: [PATCH v3 0/1] MR3504: ntdll: Handle invalid locks in ReleaseSRWLockExclusive.
by Yuxuan Shui (＠yshui) 03 Aug '23

03 Aug '23

On Thu Aug 3 15:49:48 2023 +0000, Yuxuan Shui wrote: > I feel that is a bit overkill for a single application, which is using > the lock in an invalid way anyway. Had some discussions with @huw and agreed we do need to do this properly. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_41250

1 0

Re: [PATCH v3 0/5] MR3103: server: Create and use a desktop shared mapping for GetCursorPos.
by Rémi Bernon (＠rbernon) 03 Aug '23

03 Aug '23

On Thu Aug 3 15:44:45 2023 +0000, Jinoh Kang wrote: > > ending up re-using the same mapping because it is created with the > desktop name. > Then I think we should unlink the mapping object (but keep it alive), > and create a *new* mapping object with the same. > Perhaps this was obvious at first, but there was some complication that > I failed to notice. Do you mind elaborating if this is the case? Sure, we should perhaps unlink the mapping object too. Although that's probably a good thing to do, I'm not sure to see how it makes any difference wrt this `shared_ptr` member, and why we should get rid of this member. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3103#note_41249

1 0

Re: [PATCH v3 0/5] MR3103: server: Create and use a desktop shared mapping for GetCursorPos.
by Rémi Bernon (＠rbernon) 03 Aug '23

03 Aug '23

v2: Use pointer to const when possible for the desktop_shm_t, make it writable only within SHARED_WRITE_BEGIN/END. Remove the recursive sequence number and the related asserts. I rebased and pushed the update to quickly apparently, Gitlab UI messed it up, the range-diff is 8bf8fb91603...8cd46e3de73. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3103#note_41246

1 0

Re: [PATCH v3 0/5] MR3103: server: Create and use a desktop shared mapping for GetCursorPos.
by Jinoh Kang (＠iamahuman) 03 Aug '23

03 Aug '23

Instead of creating a new directory object, how about we just make the desktop object itself a namespace and implement `object_ops::lookup_name`? Instead of WindowsStations\__wine_desktop_mappings\WinSta0\Default , we'd open WindowsStations\WinSta0\Default\__wine_desktop_mapping . -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3103#note_41245

1 0

[PATCH v2 0/5] MR3103: server: Create and use a desktop shared mapping for GetCursorPos.
by Rémi Bernon (＠rbernon) 03 Aug '23

03 Aug '23

First part of Proton shared memory series. The full branch can be seen at https://gitlab.winehq.org/rbernon/wine/-/commits/mr/shared-memories. -- v2: user32: Use the desktop shared data for GetCursorPos(). server: Add a sequence number to the shared data. server: Move the cursor position and last change time to the shared data. server: Use the helper to update the cursor last change time. server: Create a desktop shared mapping. https://gitlab.winehq.org/wine/wine/-/merge_requests/3103

2 5

[PATCH 0/1] MR3505: ntdll: Implement NtCreateToken().
by Dmitry Timoshkov (＠dmitry) 03 Aug '23

03 Aug '23

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/3505

4 7

Re: [PATCH v3 0/1] MR3504: ntdll: Handle invalid locks in ReleaseSRWLockExclusive.
by Yuxuan Shui (＠yshui) 03 Aug '23

03 Aug '23

On Thu Aug 3 15:48:53 2023 +0000, Zebediah Figura wrote: > > @zfigura I think this is unfortunately a case of the application > looking at the internal state of something that's supposed to be opaque. > > > > The application here is specifically creating a `SRWLOCK`, > manipulating its internal state not through the APIs, then calling > `ReleaseSRWLockExclusive` and inspecting the result. > > > > And if the result is different from what it expects, it opens a > KeyedEvent for `"\\KernelObjects\\CritSecOutOfMemoryEvent"`, and waits > on it in a loop. > > > > I can't tell you why it's doing that. > That makes some amount of sense (not that I know why the application > thinks it needs to mess with lock state manually, but, well, It > Happens). In that case I suppose the answer is that we probably need to > change our SRW lock implementation to match Windows'. I feel that is a bit overkill for a single application, which is using the lock in an invalid way anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_41229

1 0

2025

2024

2023

2022

wine-gitlab August 2023