Windows registry keys such as `HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WindowsRuntime\\ActivatableClassId\\Windows.Storage.ApplicationData` indicate that `Windows.Storage.ApplicationData` related classes should be in `windows.storage.applicationdata.dll`, and the remaining classes together with `Windows.Storage.StorageFile` should be in `windows.storage.dll`.
This allows future implementions of class `Windows.Storage.StorageFile` to be correctly put in the `windows.storage.dll`, instead of `windows.storage.applicationdata.dll`, see https://gitlab.winehq.org/wine/wine/-/merge_requests/8394
--
v2: windows.storage: Split ApplicationData
https://gitlab.winehq.org/wine/wine/-/merge_requests/8416
This test seems to be testing different filters when creating volumes, and
nothing indicates it's intentionally testing volume creation from out-of-bound
srcboxes.
The pixels array is 16x4 bytes, pixel format D3DFMT_A8R8G8B8 is 4 bpp, so pixels
have 16 pixels in total. The boxes have 2 slices, with a slice pitch of 32
bytes, that's 8 pixel/slice. The original width*height is 6*6 which is thus
beyond these bounds. This commit changed it to 4*2 so the rowpitch of 16 bytes
is perserved.
--
v2: d3dx9/tests: Fix volume test boxes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8418
Windows registry keys such as `HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WindowsRuntime\\ActivatableClassId\\Windows.Storage.ApplicationData` indicate that `Windows.Storage.ApplicationData` related classes should be in `windows.storage.applicationdata.dll`, and the remaining classes together with `Windows.Storage.StorageFile` should be in `windows.storage.dll`.
Split Windows.Storage.ApplicationData definitions out of
windows.storage.idl to windows.storage.applicationdata.idl and import
that instead of whole window.storage.idl into
windows.storage.applicationdata.dll, to better reflect Windows
implementation.
This allows future implementions of class `Windows.Storage.StorageFile` to be correctly put in the `windows.storage.dll`, instead of `windows.storage.applicationdata.dll`, see https://gitlab.winehq.org/wine/wine/-/merge_requests/8394
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8416
As discussed in !8402. @cmccarthy what do you think of this? I think queueing an event right before shutting down the queue is enough to get the media session notified? It won't get the actual event but it will be able to see the MF_E_SHUTDOWN error after calling `EndGetEvent`?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8415
comctl32/treeview: Return from TREEVIEW_LButtonDown when the treeview handle is invalid.
LButtonDown should return when the treeview handle is invalid (e.g. destroyed) after NM_CLICK to prevent further message processing.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58211
--
v5: comctl32/treeview: Return from TREEVIEW_LButtonDown when the treeview handle is invalid.
comctl32/tests: Add a test for treeview deletion during NM_CLICK in LBUTTONDOWN.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8258
Dot segments removal in parse_canonicalize makes the assumption that the entire
path part of the URI fits into the output buffer (len is the length the output
URI would have taken had the output buffer been large enough). So when the
output buffer is too small, remove_dot_segments will access out-of-bound.
Considering URI unescaping could be happening at the same time, there is no
simple way to calculate the required output buffer size correctly without
keeping the actual output URI in memory.
* * *
As you can see from the [test results](https://testbot.winehq.org/JobDetails.pl?Key=158742), this seems to be bugged on native. I don't know if we need to replicate native's behavior
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8331
While preparing !8397 I wondered If there other uses of CallWindowProc[AW] which use a 4-byte sized type to store the return value, while at x86_64 LRESULT is 8 bytes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8411
Some window manager won't send a ConfigureNotify event if the stack
mode isn't actually changed, and we cannot predict whether it will.
We would be waiting forever for an event and delay other requests when
we can just request the above state the next time the window needs to
be reconfigured.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8412
This is required to fix video playback in Crashlands 2 on Proton 10.
--
v3: mfreadwrite: Fix media type output when video processor is used.
mfreadwrite/tests: Check DEFAULT_STRIDE is not always present.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8172