- wine-gitlab - winehq.org

[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 (＠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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3103

5 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 (＠insn) 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

2 15

Re: [PATCH v2 0/6] MR3502: LDAP session key - approved
by Alexandre Julliard (＠julliard) 03 Aug '23

03 Aug '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3502

1 0

Re: [PATCH v6 0/3] MR3472: secur32: Convert "Negotiate" to an LSA package. - approved
by Alexandre Julliard (＠julliard) 03 Aug '23

03 Aug '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3472

1 0

Re: [PATCH v3 0/1] MR3491: winegstreamer: Leave media source critical section before unlocking workqueue. - approved
by Alexandre Julliard (＠julliard) 03 Aug '23

03 Aug '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3491

1 0

2025

2024

2023

2022

wine-gitlab