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
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
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
> @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
@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
--
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