- wine-gitlab - winehq.org

[PATCH v2 0/8] MR6951: msvcrt: Prepare more functions to handle utf-8 encoded file names.
by Piotr Caban (＠piotr) 03 Dec '24

03 Dec '24

-- v2: msvcrt: Prepare _mktemp_s to handle UTF-8 strings. msvcrt: Prepare _mktemp to handle UTF-8 strings. msvcrt: Call _wunlink in _wremove function. msvcrt: Call _unlink in remove function. msvcrt: Call _wchmod in _chmod function. msvcrt: Call _waccess in _access function. msvcrt: Call _wunlink in _unlink function. msvcrt: Prepare _fsopen to handle UTF-8 strings. https://gitlab.winehq.org/wine/wine/-/merge_requests/6951

3 9

[PATCH v2 0/1] MR6728: explorer: Prevent apps from showing Wine specific shell tray window with no icons.
by Paul Gofman (＠gofman) 03 Dec '24

03 Dec '24

-- v2: explorer: Prevent apps from showing Wine specific shell tray window with no icons. https://gitlab.winehq.org/wine/wine/-/merge_requests/6728

3 9

[PATCH 0/8] MR6951: msvcrt: Prepare more functions to handle utf-8 encoded file names.
by Piotr Caban (＠piotr) 03 Dec '24

03 Dec '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6951

3 9

[PATCH 0/1] MR6949: gdiplus: Cast enums to unsigned type when validating its value.
by Jacek Caban (＠jacek) 03 Dec '24

03 Dec '24

According to the spec, the compiler is free to use a signed, unsigned, or even char type for enums, provided all values fit within the type. For example, constructs like `*_FORCE_DWORD` can force an unsigned type using a value like `0xffffffff`. While some headers use this approach, it’s inconsistent and 0x7fffffff is often used instead. Unfortunately, MSVC and GCC differ in their behavior: GCC always uses an unsigned type, while MSVC uses a signed type when possible. Consequently, Clang’s behavior depends on the mode being used. Additionally, Clang emits a warning for "useless" checks when building Wine in MinGW mode. For instance: ``` dlls/gdiplus/graphics.c:7337:18: warning: result of comparison of unsigned enum expression < 0 is always false [-WTautological-unsigned-enum-zero-compare] 7337 | src_space < 0 || src_space > CoordinateSpaceDevice) ``` This warning is impractical for code that aims to be portable. The check is not tautological when building in MSVC mode (e.g., in our CI). I considered disabling the warning, but since this is the only place in the codebase where it’s problematic, I believe we can simply adjust the check. This resolves the last warning in LLVM builds, allowing -Werror to be used in MinGW mode as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6949

3 2

[PATCH v4 0/2] MR6948: Vulkan object rework hotfixes.
by Aida Jonikienė (＠DodoGTA) 03 Dec '24

03 Dec '24

This allows 32-bit DXVK games (like NFS Underground) to work again after the recent Vulkan changes. -- v4: winevulkan: Use WINE_UNIX_LIB instead of WINE_VK_HOST. https://gitlab.winehq.org/wine/wine/-/merge_requests/6948

3 4

[PATCH v3 0/2] MR6948: Vulkan object rework hotfixes.
by Aida Jonikienė (＠DodoGTA) 03 Dec '24

03 Dec '24

This allows 32-bit DXVK games (like NFS Underground) to work again after the recent Vulkan changes. -- v3: win32u: Make sure some Vulkan defines get defined. https://gitlab.winehq.org/wine/wine/-/merge_requests/6948

3 4

[PATCH v2 0/2] MR6948: Vulkan object rework hotfixes.
by Aida Jonikienė (＠DodoGTA) 03 Dec '24

03 Dec '24

This allows 32-bit DXVK games (like NFS Underground) to work again after the recent Vulkan changes. -- v2: win32u: Make sure some Vulkan defines get defined. https://gitlab.winehq.org/wine/wine/-/merge_requests/6948

2 2

[PATCH v4 0/5] MR6917: windows.networking.connectivity: Implement IConnectionProfile::GetNetworkConnectivityLevel().
by Mohamad Al-Jaf (＠maljaf) 03 Dec '24

03 Dec '24

Needed by Just Cause 4. -- v4: windows.networking.connectivity: Implement IConnectionProfile::GetNetworkConnectivityLevel(). windows.networking.connectivity/tests: Add INetworkInformationStatics::GetInternetConnectionProfile() tests. windows.networking.connectivity: Implement INetworkInformationStatics::GetInternetConnectionProfile(). https://gitlab.winehq.org/wine/wine/-/merge_requests/6917

3 9

[PATCH 0/2] MR6948: Vulkan object rework hotfixes.
by Aida Jonikienė (＠DodoGTA) 03 Dec '24

03 Dec '24

This allows 32-bit DXVK games (like NFS Underground) to work again after the recent Vulkan changes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6948

4 4

[PATCH 0/1] MR6943: msvcp140: Add a version resource.
by Louis Lenders (＠xe) 03 Dec '24

03 Dec '24

This fixes an error that was reported at the forum: https://forum.winehq.org/viewtopic.php?t=39757 The application (PrismLive) prints an error in the console (error: Failed to get msvcp140.dll version info size) and refuses to start. The application can be found at https://prismlive.com/en_us/# -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6943

3 3

Re: [PATCH v2 0/5] MR6944: winex11: Workaround KWin bug with maximized windows.
by Rémi Bernon (＠rbernon) 03 Dec '24

03 Dec '24

v2: Free the new thread data members on thread detach. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6944#note_89544

1 0

[PATCH 0/3] MR6947: win32u: Improve experience with emulated display mode.
by Rémi Bernon (＠rbernon) 03 Dec '24

03 Dec '24

Keep fullscreen window aspect ratio, with opaque window padding on X11. Use bilinear filtering for XRender blits. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6947

2 3

[PATCH v2 0/2] MR6877: ntdll: Force redirect all ARM64EC indirect calls until the JIT is ready.
by Billy Laws (＠bylaws) 03 Dec '24

03 Dec '24

Tested by running chrome without no-sandbox successfully. -- v2: ntdll: Force redirect all ARM64EC indirect calls until the JIT is ready. ntdll: Add arm64ec_get_module_metadata helper. https://gitlab.winehq.org/wine/wine/-/merge_requests/6877

2 4

[PATCH v3 0/4] MR6922: Improve clang configuration.
by eric pouech (＠epo) 03 Dec '24

03 Dec '24

This MR improves configuration scheme when using clang as cross compiler: - it fixes test for dwarf (-4) support (current test is failing as ldd emits a warning when generating the long section names for the dwarf section, that configure.ac treats as an error), - it fixes --enable-build-id option with clang (clang linker uses -build-id option, while gcc uses --build-id /mind the extra '-'/) - it adds support in winegcc for a generic build-id linker option. (extracted from draft MR!6715) -- v3: configure.ac: Don't add -Wl,--build-id linker option to CFLAGS. configure.ac: Properly detect build-id support for clang. winegcc: Remap build-id linker option for clang. configure.ac: Properly test clang for dwarf support. https://gitlab.winehq.org/wine/wine/-/merge_requests/6922

3 8

[PATCH v32 0/2] MR6869: timeout: Windows 10 introduce the timeout command
by Michele Dionisio (＠michele.dionisio) 03 Dec '24

03 Dec '24

Windows 10 and 11 introduce the timeout.exe command. This is a similar program with same argument options. https://bugs.winehq.org/show_bug.cgi?id=56068 -- v32: timeout: add minimal test suite timeout: Windows 10 introduce the timeout command https://gitlab.winehq.org/wine/wine/-/merge_requests/6869

3 5

[PATCH 0/1] MR6946: ntdll/tests: Fix format warning with clang.
by eric pouech (＠epo) 03 Dec '24

03 Dec '24

Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6946

2 1

[PATCH 0/1] MR6945: winex11: Do not use desired_state when computing state updates.
by Rémi Bernon (＠rbernon) 03 Dec '24

03 Dec '24

It is updated in window_wm_state_notify on unexpected state changes to match the host state and to avoid requesting the Win32 state again. We can use the window style instead to decide what needs to be changed. https://bugs.winehq.org/show_bug.cgi?id=57481 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6945

2 1

[PATCH 0/5] MR6944: winex11: Workaround KWin bug with maximized windows.
by Rémi Bernon (＠rbernon) 03 Dec '24

03 Dec '24

I know we've had a policy to avoid window manager specific workarounds, I think we could reconsider it. The fix could be unguarded and applied with every window manager, and could very well work, but I think it is ugly enough to justify checking for KWin specifically. The problem is that as soon as a window configure request is sent to a maximized window, KWin internal state gets bogus and it loses track of the window maximized state. I've described the KWin source details on https://bugs.kde.org/show_bug.cgi?id=496966 and opened https://invent.kde.org/plasma/kwin/-/merge_requests/6854 as a possible fix for it, but the time it will take to land could justify working around it in Wine. The workaround is to avoid sending configure requests to maximized windows, which sounds sensible and we already avoid resizing maximized windows, but, moving a maximized window to a different monitor *requires* sending a configure request. KWin bug makes no difference to requests with only position changes, and they trigger it all the same. So, the only solution is to temporarily remove the maximized state bits before sending the configure request, putting them back afterwards. This is quite straightforward to do with the new state tracker, but it could very well trigger other problems with other window managers. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57465 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6944

2 5

[PATCH 0/2] MR6909: Draft: winex11: Avoid requesting window size changes for maximized or fullscreen windows.
by Rémi Bernon (＠rbernon) 03 Dec '24

03 Dec '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57465 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6909

2 3

[PATCH v5 0/3] MR6891: cmd: Use CD /D to change directory in POPD (same as PUSHD).
by huangqinjin (＠huangqinjin) 03 Dec '24

03 Dec '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57137 -- v5: cmd: Set =C: environment variable if POPD succeeds (same as PUSHD). cmd: Refactor CD command. cmd/tests: Add tests for POPD with directory that no longer exists. https://gitlab.winehq.org/wine/wine/-/merge_requests/6891

3 8

[PATCH 0/1] MR6942: gdiplus: Use the FormatID of the source image when cloning.
by Haoyang Chen (＠chenhaoyang) 03 Dec '24

03 Dec '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6942

3 2

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Rémi Bernon (＠rbernon) 02 Dec '24

02 Dec '24

On Mon Dec 2 22:29:18 2024 +0000, Robbert van der Helm wrote: > Ah I completely missed the assignment there at the end when I was > grepping for usages of `wm_state_serial`. I still can't reliably get > Wine to accept configuration events I sent to it though. If I set the > `WM_STATE` property it does process the next event, but then it gets > stuck again after that because now `net_wm_state_serial` will be stuck > on a nonzero value. I could probably figure out a way to get Wine to > cooperate, but that's almost certainly going to break in a future Wine release. > To reiterate, my goal isn't necessarily to send `ConfigureNotify` events > to Wine. I just want a Wine window that's reparented to another window > to handle mouse events correctly, as otherwise Wine seems to interpret > pointer events as being relative to the root window. So for example, if > I have a regular top level X11 window at position 50x50 relative to the > top left of the root window, and I reparent a Wine window into that > window, clicking at coordinates 20x20 from the top left of the > reparented Wine window will cause Wine to register a click at coordinate > 70x70. Up until now it was possible to work around this by telling Wine > about its location on screen through `ConfigureNotify` events, but that > is of course a hack. > Since you've been working on Wine's X11 driver, what do you think is the > best way to approach this in a way that isn't likely to break again in > the future? Would extending Wine's existing tracking of > reparented/embedded windows so any events related to pointer coordinates > get translated accordingly make sense? There has been various changes in the way we handle window positioning, and it's now probably more flexible to arbitrary X11 parent windows, but in any case we still always consider the X root window coordinates as the origin for the Win32 desktop. If you want to embed all Wine windows into another window and use its position as the Win32 desktop origin, it's basically what the "virtual desktop" mode is doing already. It's an option in winecfg, where we create a dedicated window for the Win32 desktop and every Wine window will be a child of it. You could probably then reparent the desktop window to the window you want? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_89502

1 0

Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.
by Robbert van der Helm (＠robbert-vdh) 02 Dec '24

02 Dec '24

On Mon Dec 2 10:04:22 2024 +0000, Rémi Bernon wrote: > `wm_state_serial` should be cleared when the window state actually > changes and the `WM_STATE` PropertyNotify event is received, calling > `window_wm_state_notify` which clears it. Ah I completely missed the assignment there at the end when I was grepping for usages of `wm_state_serial`. I still can't reliably get Wine to accept configuration events I sent to it though. If I set the `WM_STATE` property it does process the next event, but then it gets stuck again after that because now `net_wm_state_serial` will be stuck on a nonzero value. I could probably figure out a way to get Wine to cooperate, but that's almost certainly going to break in a future Wine release. To reiterate, my goal isn't necessarily to send `ConfigureNotify` events to Wine. I just want a Wine window that's reparented to another window to handle mouse events correctly, as otherwise Wine seems to interpret pointer events as being relative to the root window. So for example, if I have a regular top level X11 window at position 50x50 relative to the top left of the root window, and I reparent a Wine window into that window, clicking at coordinates 20x20 from the top left of the reparented Wine window will cause Wine to register a click at coordinate 70x70. Up until now it was possible to work around this by telling Wine about its location on screen through `ConfigureNotify` events, but that is of course a hack. Since you've been working on Wine's X11 driver, what do you think is the best way to approach this in a way that isn't likely to break again in the future? Would extending Wine's existing tracking of reparented/embedded windows so any events related to pointer coordinates get translated accordingly make sense? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_89501

1 0

[PATCH 0/1] MR6941: winevulkan: Update to VK spec version 1.4.303.
by Georg Lehmann (＠DadSchoorse) 02 Dec '24

02 Dec '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6941

3 2

Re: [PATCH v2 0/2] MR6921: ntdll: Fix reported exception code for some brk immediates. - approved
by Alexandre Julliard (＠julliard) 02 Dec '24

02 Dec '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6921

1 0

2025

2024

2023

2022

wine-gitlab