Implement `DeviceWatcher` on top of a `HDEVQUERY` object, obtained from `DevCreateObjectQuery`. All events from the query object's associated callback are directly forwarded to the `DeviceWatcher`'s corresponding event handlers.
As closing/freeing the `HDEVQUERY` is performed asynchronously, I have also added `IWeakReference` support for the device watcher.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8555
Needed by LINE.
The IMediaTranscoder2 definition isn't needed for this, but it's small enough to add in case it's used by mingw.
--
v3: windows.media: Implement IActivationFactory::ActivateInstance() for IMediaTranscoder.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8554
For allocation, the block size calculation is snapped to block bin sizes, but
for reallocation it is not. So the tail_size calculation will be wrong if the
block size is not one of the bin sizes.
To illustrate the problem: assume an allocation size of 32 bytes.
heap_get_block_size will return 40 bytes. heap_allocate_block_lfh will round
it up to 48 bytes. The tail_size is thus, 48 - 8 - 32 = 8 bytes. Later,
HeapReAlloc is called to shrink it to 30 bytes. heap_get_block_size returns
40 bytes, heap_resize_block_lfh will not return STATUS_NO_MEMORY, because
ROUND_SIZE(30) == 32, and 30 < 32. It will then calculate the tail_size based
on the new block_size, which is 40 bytes. So the new tail_size becomes:
40 - 8 - 30 = 2 bytes. But block->block_size is still 48 bytes! So what it
actually did is **growing** the block to 48 - 8 - 2 = 38 bytes from 32 bytes.
This commit fixes it by also rounding up the block_size to bin sizes in
heap_resize_block_lfh.
* * *
This was discovered serendipitously by ASan, because the heap shadowing code I added for ASan didn't expect `heap_allocate_block_lfh` to enlarged the block, this mismatch triggered an ASan report.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8663
Windows implements `xinput9_1_0.dll` by dynamically loading `xinput1_4.dll` and calling into it.
In a test app linked against `xinput9_1_0`, `GetModuleHandleW(L"xinput1_4.dll")` returns non-NULL after `xinput9_1_0.XInputGetState` is called (but NULL before anything is called, indicating it calls `LoadLibrary` in the `XInput*` functions).
Steam Input depends on this behavior: it works by injecting a DLL into the game process, running `GetModuleHandleW(L"xinput1_{1-4}.dll")`, and hooking every `xinput1_*` DLL that's loaded. It notably does not look for or hook `xinput9_1_0.dll`, but it doesn't need to since the `xinput1_4` hooks affect `xinput9_1_0`.
This meant that Steam Input did not work in any games using `xinput9_1_0`, which are surprisingly common. Animal Well and Journey are two examples.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8668