copy_propagation_transform_object_load() currently retrieves true, which
indicates that there was progress, even if the input dereference remains
the same.
This can happen repeatedly if an uninitialized object is copied onto
itself, as in the tests added in this patch. This results on the
compilation getting stuck on an endless loop.
This patch checks if the deref didn't change, to retrieve false in that
case.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/59
Depending on the theme, if there was a header,
the border ends up painted lower than it should be,
and clipped by the header.
7-Zip file manager, the reason why the offset was added in 5f0dcf79185941c4faff35d1cc9c758160f3a27d in the first place, still renders correctly.
Before:
![before](/uploads/8321f45c657469278b2787edfa147b20/before.png)
After:
![after](/uploads/013241f4cd3b893c7f4073b6a9fe8119/after.png)
EDIT1:
Actually compared screenshots of 7-Zip file manager and looks like the headers are now painted consistently after highlighting them.
![7zFM-before-hilite](/uploads/64fe3fb80002c847c2e9270337bab4e8/7zFM-before-hilite.png)
![7zFM-after-hilite](/uploads/4db4778c2ad6d27eddbd4a1202b41881/7zFM-after-hilite.png)
--
v3: comctl32/listview: Exclude header area in WM_NCPAINT.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1878
For some reason NosTale is checking memory regions preventing it's own logic from calling system memory.
It checks if the code is called under "0x70000000" range, but for some reason "user32.dll" is placed below this region (by Wine) causing mouse bug, graphical glitches and other memory-access related errors.
This pull-request fixes the bug, because I wanted to be sure I tested it on two Linux machines, Steam Deck and one macOS device.
Everything just works fine.
Not sure if we should set only this dll base address or (according to reference image) set it for other dll libraries too.
Also under Windows (I tested it too) it's randomized by ALSR - maybe we should do it the same way (and place library between range "0x70000000" - 0x80000000" for example).
Reference:
https://user-images.githubusercontent.com/21007545/210278824-29f42d90-aca4-…
Resolves these issues:
https://bugs.winehq.org/show_bug.cgi?id=49988https://bugs.winehq.org/show_bug.cgi?id=42999
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1907
I was unable to write tests for this; it seems it doesn't consistently work on
Windows. However, Rayman 3 seems to rely on it; it maps the same buffer twice
immediately after creation, with DISCARD flags on both maps, and expects the
same address to be returned.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53752
--
v3: d3d8: Filter out redundant buffer discards.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1884