--
v2: comctl32/listview: Properly handle item state value for LVS_OWNERDATA controls.
comctl32/tests: Add item state value tests for LVS_OWNERDATA controls.
comctl32/listview: Don't touch iImage value for subitems if LVS_EX_SUBITEMIMAGES is not set.
comctl32/tests: Add tests for iImage value for listview subitems.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8330
Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/7815, for https://gitlab.winehq.org/wine/wine/-/merge_requests/7226, this only split the sync ops to a separate vtable and let objects delegate theirs to a separate object.
This starts using a event-like interface for most objects, leaving the decision regarding if/how to split sync themselves / integrate inproc syncs for later.
--
v11: server: Use an event sync for fd objects.
server: Introduce a new event sync object.
server: Redirect fd-based objects sync to the fd.
server: Add an operation to retrieve an object sync.
server: Move object grab/release out of (add|remove)_queue.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7848
Before this, stopping and restarting the media session
could cause MFT streams to get stuck in the "already pending"
state, which would lead to no more samples getting delivered.
This also reverts 18c0dd7390b354d2e505e54cd3f3f9b08226b265,
my previous attempt to fix the problem which for some reason
seemed to help - but with the new fix, it does not make any
difference.
The reverted commit is faulty since the Flush() method - which is called at session Stop, but runs after sample_grabber_set_state - already releases pending items, while processing markers immediately.
Sorry for the trouble.
--
v2: Revert "mf: Release pending items when sample grabber is stopped."
mf: Clear pending MFT stream requests when flushing.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8175
Before this change we've treated Rbp as a CONTEXT_CONTROL register, but it is a CONTEXT_INTEGER register on windows (unlike ebp on i386, which is indeed a CONTEXT_CONTROL register on windows).
This caused issues with debuggers, specifically the Visual Studio 2022 Remote Debugging Server issues a SetThreadContext call with ContextFlags=CONTEXT_CONTROL, without Rbp set, which leads to Rbp getting erroneously zero'd.
Attached a simple test program [capture.c](/uploads/74698f4cd99246880250d6a139777603/capture.c), not sure if this should be part of the ntdll tests instead.
--
v2: ntdll, server: Treat Rbp as CONTEXT_INTEGER register.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8317
Before this, stopping and restarting the media session
could cause MFT streams to get stuck in the "already pending"
state, which would lead to no more samples getting delivered.
This also reverts 18c0dd7390b354d2e505e54cd3f3f9b08226b265,
my previous attempt to fix the problem which for some reason
seemed to help - but with the new fix, it does not make any
difference.
The reverted commit is faulty since the Flush() method - which is called at session Stop, but runs after sample_grabber_set_state - already releases pending items, while processing markers immediately.
Sorry for the trouble.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8175
Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/7815, for https://gitlab.winehq.org/wine/wine/-/merge_requests/7226, this only split the sync ops to a separate vtable and let objects delegate theirs to a separate object.
This starts using a event-like interface for most objects, leaving the decision regarding if/how to split sync themselves / integrate inproc syncs for later.
--
v10: server: Use an event sync for fd objects.
server: Introduce a new event sync object.
server: Redirect fd-based objects sync to the fd.
server: Add an operation to retrieve an object sync.
server: Move object grab/release out of (add|remove)_queue.
server: Move signal access checks outside of the objects.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7848