August 2023 - Wine-gitlab - list.winehq.org

Re: [PATCH v3 0/5] MR3103: server: Create and use a desktop shared mapping for GetCursorPos.
by Rémi Bernon 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 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

1 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

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

03 Aug '23

> @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'. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_41228

1 0

[PATCH 0/5] MR3103: server: Create and use a desktop shared mapping for GetCursorPos.
by Rémi Bernon 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3103

4 50

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

03 Aug '23

@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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_41224

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 don't think this makes sense if we aren't representing lock state the same way. > This fixes a dead lock which prevents WeCom from starting up. How does this deadlock occur? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3504#note_41223

1 0

[PATCH v2 0/15] MR3482: mshtml: Implement Cycle Collection for all mshtml objects (dispex), part 2.
by Gabriel Ivăncescu 03 Aug '23

03 Aug '23

-- v2: mshtml: Use unlink and destructor in the vtbl for HTMLNamespaceCollection. mshtml: Use unlink and destructor in the vtbl for HTMLPerformance. mshtml: Use unlink and destructor in the vtbl for HTMLPerformanceNavigation. mshtml: Use unlink and destructor in the vtbl for Navigator. mshtml: Use unlink and destructor in the vtbl for HTMLMimeTypesCollection. mshtml: Use unlink and destructor in the vtbl for HTMLPluginsCollection. mshtml: Use unlink and destructor in the vtbl for History. mshtml: Use unlink and destructor in the vtbl for HTMLScreen. mshtml: Use unlink and destructor in the vtbl for HTMLDOMImplementation. mshtml: Use unlink and destructor in the vtbl for HTMLDOMAttribute. mshtml: Use unlink and destructor in the vtbl for HTMLTxtRange. mshtml: Use unlink and destructor in the vtbl for HTMLDOMRange. mshtml: Use unlink and destructor in the vtbl for HTMLSelectionObject. mshtml: Use unlink and destructor in the vtbl for HTMLStorage. mshtml: Unlink variants using a helper function. https://gitlab.winehq.org/wine/wine/-/merge_requests/3482

1 15