Check that NULL has no special meaning.
Check GetLastError() for systray windows.
Trace the module filename in case of unexpected success and enclose it
in quotes in case there are leading or trailing spaces.
Fix the filename buffer initialization.
---
The buf2[0] = 0 line at the top of the patch was introduced in
914cb228685b but buf2 was not used after that. So clearly it is buf1
that should have been initialized there.
That said I'm not sure initializing buf1 & buf2 is really necessary as
they are only used in case of success. I guess the fear was that
GetWindowModuleFileName() would sometimes return success without
touching the buffer but I'm not convinced that fear is justified. Still
I decided to be conservative and preserve the initializations. I'm fine
with removing them though (maybe the buf2 case is a bit special).
Finally this is meant to help figure out the reason for the failure
decribed in bug 55777.
--
v2: user32/tests: Don't test GetWindowModuleFileName() on windows belonging to another process.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4084
This MR improves window management related behavior and adds support for more scenarios.
Some highlights (please see the full commit list and messages for more info):
1. Better support for tiled states.
2. Detect and handle fullscreen windows.
3. Increased robustness against state disagreements between Wine and the Wayland compositor.
4. Move top-level windows to (0,0) (using that fixed point for now, we will later generalize this mechanism for multiple monitors), in order to:
a. maximize the accessible mouse input region (which may be clipped in Windows virtual screen space, but still accessible in Wayland space).
b. introduce the basic mechanism to allow windows applications to (very roughly!) track which output(s) they are really on (to be continued in the full multi-monitor form).
Although (4) is not a perfect solution for the lack of absolute positioning, it has worked well in practice in its full, multi-monitor implementation (i.e., in the experimental branch). I wonder if for (4a) in particular we can do better, e.g., by being able to emit input that circumvents the normal virtual screen clipping. Is there a way to do this already? If not, do you think that such an approach would be a feasible and acceptable way forward, or is virtual screen input clipping fundamentally baked in the current core design and assumptions?
Thanks!
--
v4: winewayland.drv: Avoid resizing fullscreen windows.
winewayland.drv: Rename wayland_surface_configure_is_compatible for consistency.
winewayland.drv: Use surface geometry to satisfy state size constraints.
winewayland.drv: Handle application-initiated fullscreen state.
winewayland.drv: Store and use the latest window config for a wayland_surface.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4014
I.e., top-left origin, and clockwise front-facing. These end up cancelling
each other out when drawing full-screen quads, but that's not necessarily true
for other geometry.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/404