October 2026 - Wine-Bugs - list.winehq.org

[Bug 57567] New: Punishing gray raven fails to launch
by WineHQ Bugzilla Oct. 4, 2026

Oct. 4, 2026

https://bugs.winehq.org/show_bug.cgi?id=57567 Bug ID: 57567 Summary: Punishing gray raven fails to launch Product: Wine Version: 10.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: francisco278herrera(a)gmail.com Distribution: --- Created attachment 77665 --> https://bugs.winehq.org/attachment.cgi?id=77665 debug log with WINEDEBUG=PGR.exe:+all Punishing gray raven fails to launch, presumably due to failiing call to 2771.744:00f0:00f4:trace:reg:RegQueryValueExA (000000000000014C,"SystemBiosVersion",0000000000000000,0000000000000000,00000000001058E0,0000000000105890=260) with OBJECT_NAME_NOT_FOUND and several other registry keys fail with the same error and failing call 2769.893:00f0:00f4:fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot 2769.910:00f0:00f4:fixme:toolhelp:Heap32ListFirst : stub the game's anticheat does seem to scan memory after 2769.910:00f0:00f4:Ret KERNEL32.CreateToolhelp32Snapshot() retval=0000014c ret=6ffff991a22d and scan threads with Thread32Next so maybe the game is intentionally refusing to run in wine, in which case the bug is invalid. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 12

[Bug 60430] New: Plee the Bear 0.6 does not show "yellow" mouse cursor
by WineHQ Bugzilla Oct. 4, 2026

Oct. 4, 2026

http://bugs.winehq.org/show_bug.cgi?id=60430 Bug ID: 60430 Summary: Plee the Bear 0.6 does not show "yellow" mouse cursor Product: Wine Version: 11.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Target Milestone: --- Distribution: --- V0.6 from: https://sourceforge.net/projects/plee-the-bear/files/Plee%20the%20Bear/ does not show "yellow" mouse cursor when ran -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 60432] New: Wargaming Game Center: integrity check stalls while a VPN utun interface is present (macOS)
by WineHQ Bugzilla Oct. 4, 2026

Oct. 4, 2026

http://bugs.winehq.org/show_bug.cgi?id=60432 Bug ID: 60432 Summary: Wargaming Game Center: integrity check stalls while a VPN utun interface is present (macOS) Product: Wine Version: 11.18 Hardware: x86-64 URL: https://redirect.wargaming.net/WGC/Wargaming_Game_Cent er_Install_EU.exe OS: MacOS Status: UNCONFIRMED Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: bureau_paged7s(a)icloud.com Target Milestone: --- Created attachment 82245 --> http://bugs.winehq.org/attachment.cgi?id=82245 Terminal output of the VPN run, Wine 11.18 (WINEDEBUG=err+all,warn+nsi,warn+iphlpapi), xz-compressed Wargaming Game Center (WGC) stalls during "Check and Repair" (integrity verification) of World of Tanks whenever a VPN client's TUN interface is up on macOS. After ~12 seconds disk reading stops, CPU goes idle and the progress bar stays at 25% indefinitely (waited 38 minutes). With the VPN disconnected, the same check in the same prefix completes in about 4 minutes. Environment: - Wine 11.18 (official macOS build by Gcenx, wine-devel-11.18-osx64), fresh 64-bit WINEPREFIX - macOS 27.0 on Apple Silicon (Wine runs under Rosetta 2) - Wargaming Game Center 26.05.01.3645, World of Tanks EU 2.4.0.5473 - VPN client in TUN mode: creates utun4 (198.18.0.1) and adds 56 of the 83 IPv4 routes Steps to reproduce: 1. Connect a VPN client that uses a utun interface. 2. Create a fresh prefix and install WGC (see the note on the installer below). 3. In WGC, use "Import Installed Games" to add an existing World of Tanks EU installation. 4. Open Game Settings -> Check and Repair -> Continue. Actual result: the check of part "client" starts, the game volume is read at ~450 MB/s for ~12 seconds, then reading drops to 0 MB/s and nothing else happens. The UI shows "Checking integrity... 25%" forever. Disconnecting the VPN does not make the stalled check continue. Expected result: the check completes, as it does with the VPN disconnected. A/B in the same fresh prefix, same game files: - VPN connected: part "locale" completes in 1 s, part "client" stalls after ~12 s (no progress for 38 min). - VPN disconnected: "locale" 1 s, "client" 52 s, "sdcontent" 88 s, "hdcontent" 76 s, all "completed successfully". The same A/B was first observed on a copy of an existing prefix with the same result. While WGC runs with the VPN connected, Wine prints tens of thousands of nsi warnings from ipv4_forward_enumerate_all ("Unexpected address type 0x20", "Received unsupported sockaddr family 0x12") plus "ipv6_forward_enumerate_all not implemented" (about 40,000 / 27,000 / 111 in the attached log). I could not yet confirm whether these warnings are the cause; WGC bundles libtorrent 1.1.9, which enumerates interfaces and routes. Component is left as "-unknown"; iphlpapi/nsi looks like the most likely candidate. Note on installation: the official web installer (https://redirect.wargaming.net/WGC/Wargaming_Game_Center_Install_EU.exe, SHA1 9fee6b470eab9a50568eb3c260618114eb9046f3) never shows its window in a fresh prefix (100% CPU), and with /VERYSILENT it crashes right after its first HTTPS request; this happens with and without the VPN, so it is a separate issue. For this test WGC was installed the way the installer does it: the package it downloads (https://redirect.wargaming.net/wds/wargaming_game_center_install_eu_win64.w…, SHA1 c8edc3420add78170301da2ba4fa853de22987d8) was extracted with the installer's own 7za.exe into C:\Program Files\Wargaming.net\GameCenter, and the uninstall registry key and C:\ProgramData\Wargaming.net\GameCenter\data\wgc_path.dat that the installer creates were added by hand. Attachments: - wine-11.18-wgc-terminal-output-with-vpn.txt.xz: full terminal output of the VPN run (WINEDEBUG=err+all,warn+nsi,warn+iphlpapi) - wgc-integrity-timeline.txt: disk read rate sampled every ~4 s plus the integrity lines from the WGC log for both runs -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 60431] New: winewayland.drv: Wine windows cannot be interactively resized under labwc
by WineHQ Bugzilla Oct. 4, 2026

Oct. 4, 2026

http://bugs.winehq.org/show_bug.cgi?id=60431 Bug ID: 60431 Summary: winewayland.drv: Wine windows cannot be interactively resized under labwc Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)list.winehq.org Reporter: tiwasaka(a)live.jp Target Milestone: --- Distribution: --- Created attachment 82243 --> http://bugs.winehq.org/attachment.cgi?id=82243 Compressed logs containing WAYLAND_DEBUG=1 output for both labwc (not working) and Weston (working) using 'DISPLAY= wine notepad'. Description When using Wine's native Wayland driver (winewayland.drv) under labwc, Wine windows cannot be interactively resized by dragging their borders or corners. The resize cursor appears when the pointer is moved to a window edge or corner, but dragging it has no visible effect. The same Wine application can be interactively resized under Weston using the native Wayland driver. Resizing also works when Wine is run through XWayland under labwc. I am not sure whether this is a Wine bug, a labwc/wlroots issue, or an interoperability issue between winewayland.drv and labwc. Environment Compositor: labwc Wine: 11.16 and 11.19 Wayland driver: native Wayland (winewayland.drv) OS: Archlinux labwc version: labwc 0.20.2-dirty (+xwayland +nls +rsvg +libsfdo) wlroots-0.20.2 Reproduction Start labwc. Run a Wine application with the native Wayland driver: DISPLAY= wine notepad DISPLAY is unset so that Wine uses the native Wayland driver rather than XWayland. Move the pointer to a window edge or corner. The resize cursor appears. Drag the edge or corner. Actual behavior The window does not visibly resize. The same behavior occurs with labwc's Alt + Right Click + Drag resize operation. Expected behavior The Wine window should interactively resize while dragging an edge or corner. Comparison Environment Native Wayland Resize labwc Yes ❌ Does not work Weston Yes ✅ Works labwc + XWayland No ✅ Works I also tested both client-side and server-side decorations in labwc. The behavior is identical in both cases, so CSD vs. SSD does not appear to be the cause. Output scale labwc is normally configured to use an output scale of 1.5 via wlr-randr. I also tested labwc with an output scale of 1.0, and the resize problem remains unchanged. Therefore, the behavior does not appear to depend on the output scale. Weston was tested without changing the output scale, and interactive resizing works there. Wayland debug information I captured WAYLAND_DEBUG=1 output while attempting to resize the same Wine application under both compositors. labwc (Not working) Immediately after the resize request, labwc sends an initial 0, 0 configure, which Wine acknowledges. As the user drags the mouse, labwc then sends a stream of updated configurations (serials 10483 through 10505). In the captured trace, Wine does not send any further ack_configure or corresponding geometry updates after acknowledging the initial 10480 configure: -> xdg_toplevel#39.resize(wl_seat#10, 10479, 10) ... xdg_toplevel#39.configure(0, 0, array[4]) xdg_surface#38.configure(10480) ... -> xdg_surface#38.ack_configure(10480) -> xdg_surface#38.set_window_geometry(0, 0, 751, 812) -> wl_surface#3.commit() [09:57:33.732655] xdg_toplevel#39.configure(751, 811, array[4]) # Serial 10483 ... [09:57:34.186056] xdg_toplevel#39.configure(435, 494, array[4]) # Serial 10505 No subsequent ack_configure or geometry update from Wine is visible in the captured trace during the drag operation. One noticeable difference is that the xdg_toplevel.configure state array is reported as array[4] by labwc. Weston (Working) Under Weston, the sequence also starts with a 0, 0 configure. As Weston sends updated configurations, Wine sends acknowledgements and corresponding geometry updates while the resize is in progress: -> xdg_toplevel#26.resize(wl_seat#12, 427, 10) ... xdg_toplevel#26.configure(0, 0, array[8]) xdg_surface#25.configure(430) ... xdg_toplevel#26.configure(1122, 1215, array[8]) xdg_surface#25.configure(438) -> xdg_surface#25.ack_configure(436) -> xdg_surface#25.set_window_geometry(0, 0, 1125, 1216) -> wl_surface#19.commit() Interactive resizing works correctly under Weston. Another noticeable difference is that the xdg_toplevel.configure state array is reported as array[8] by Weston, compared with array[4] under labwc. I am not sure whether this difference is relevant to the issue. Additional information The issue is reproducible with Wine 11.16 and 11.19. The issue occurs with both CSD and SSD in labwc. The issue occurs with labwc output scale 1.5 and 1.0. XWayland resizing works under the same labwc session. Native Wayland resizing works under Weston. The issue has been observed with multiple Wine applications. The Wayland traces show that both compositors receive the xdg_toplevel.resize() request and send subsequent xdg_toplevel.configure() events. However, the behavior of Wine in response to those configure events differs between labwc and Weston. At this point I am not sure whether this indicates a problem in winewayland.drv, labwc/wlroots, or their interoperability, so I am reporting the behavior and the protocol traces for further investigation. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 60105] New: Crossrunner emulator crashes on loading a hard drive image file (Gentoo Linux)
by WineHQ Bugzilla Oct. 4, 2026

Oct. 4, 2026

http://bugs.winehq.org/show_bug.cgi?id=60105 Bug ID: 60105 Summary: Crossrunner emulator crashes on loading a hard drive image file (Gentoo Linux) Product: Wine Version: 11.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: enkiferreiracosta867(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81656 --> http://bugs.winehq.org/attachment.cgi?id=81656 console output I installed the Crossrunner emulator for Apple IIGS (https://www.crossrunner.gs/) using the provided .msi file. The program runs fine, until I try to load ANY hard disk image (.hdv/.2mg) file, be it by clicking the `...` button, or even typing its path in the text field. That's when the crash happens, and, to make it even weirder, no meaningful message is shown in the console output, as you can see in the attachment. These "Ignoring stroke style" messages all appear when i simply just hover the text field for the drive image file. Wine 11.12 was compiled on Gentoo with the `X alsa custom-cflags gecko kerberos mingw opengl ssl strip truetype vulkan wayland wow64` USE flags. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 60425] New: Spider-Man 2001: Keyboard and mouse no more available after ALT-TAB
by WineHQ Bugzilla Oct. 4, 2026

Oct. 4, 2026

http://bugs.winehq.org/show_bug.cgi?id=60425 Bug ID: 60425 Summary: Spider-Man 2001: Keyboard and mouse no more available after ALT-TAB Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: legluondunet(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82234 --> http://bugs.winehq.org/attachment.cgi?id=82234 spider-man 2001 wine-staging 11.17 log Hello, about this game: https://en.wikipedia.org/wiki/Spider-Man_(2000_video_game) Spider-Man 2001 PC version This game has a major issue when playing with Wine: when you alt-tab, you loose mouse and keyboard, all you can do is to force close the window game. log joined. tested with wine-staging 11.17 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 57556] New: Zenless zone zero game sometimes doesn't respond to mouse input
by WineHQ Bugzilla Oct. 4, 2026

Oct. 4, 2026

https://bugs.winehq.org/show_bug.cgi?id=57556 Bug ID: 57556 Summary: Zenless zone zero game sometimes doesn't respond to mouse input Product: Wine Version: 10.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: francisco278herrera(a)gmail.com Distribution: --- The game is based on unity and runs on directx11, the first time you open it, it will not respond to any mouse input, if you open it a second time, it will only respond once to mouse input, and if you open it a third time, it will remain repsonsive to mouse input. To reproduce i believe you have to start with a fresh wineprefix. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 5

[Bug 60420] New: Wuthering Waves launcher window shows up fully transparent
by WineHQ Bugzilla Oct. 4, 2026

Oct. 4, 2026

http://bugs.winehq.org/show_bug.cgi?id=60420 Bug ID: 60420 Summary: Wuthering Waves launcher window shows up fully transparent Product: Wine Version: 11.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: bluechxindv(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82227 --> http://bugs.winehq.org/attachment.cgi?id=82227 +server,+x11drv,+win compressed log Pretty much the title: after installing the Wuthering Waves launcher from https://wutheringwaves.kurogames.com/en/, its window shows up fully transparent and nothing inside it renders. The launcher relies on WebView2, but even forcing Windows 7 for msedgewebview2.exe with an override (which should get rid of the dependency on dcomp) doesn't fix it. From my understanding of the logs, the launcher is a WPF window with AllowsTransparency, so it's drawn with UpdateLayeredWindow and it gets a 32-bit ARGB visual. Edge then places its own window inside it and draws there from its own processes, so the content ends up being drawn into child windows of a layered window. In the +server log, once UpdateLayeredWindow is called, the launcher window gets a 1x1 surface ({306,126;307,127}). From then on, every time Edge asks for its window's visible area, it gets back an empty region (region={{0,0;0,0}}), so nothing it draws shows up. Removing the clipping wasn't enough, though... once it becomes layered, the launcher's X window is recreated with an ARGB visual. Edge still draws into it, but since the window belongs to another process, X11DRV_GetDC uses the default visual instead of the ARGB one (there's a FIXME for this: https://gitlab.winehq.org/wine/wine/-/blob/13625e51fd62639c8a60d7c2774ae70d…) So what Edge draws doesn't end up matching the window's format. I can't really come up with a good solution myself, hopefully leaving this here will help! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 60428] New: 3D preview renders correctly on screen but prints/exports as solid black blocks (reproduced on both classic WoW64 and pure WoW64)
by WineHQ Bugzilla Oct. 3, 2026

Oct. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=60428 Bug ID: 60428 Summary: 3D preview renders correctly on screen but prints/exports as solid black blocks (reproduced on both classic WoW64 and pure WoW64) Product: Wine Version: 11.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)list.winehq.org Reporter: fjavier1954(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82237 --> http://bugs.winehq.org/attachment.cgi?id=82237 3D view rendering correctly on screen Summary 3D simulation preview renders correctly on screen, but printing or exporting it to file (including a virtual PDF printer) produces solid black blocks instead of the actual rendered image. Reproduced on two completely different setups (classic WoW64 32-bit and new pure WoW64), which rules out a 32/64-bit architecture issue. Environment - Wine builds tested: wine-11.0 (classic WoW64, wine32+wine64, multilib/i386 enabled) and wine-11.18 (pure WoW64, no multilib). - Hosts tested: - Linux Mint 21.3, classic WoW64 (wine32+wine64). - CachyOS Linux rolling release, pure WoW64 (no multilib). - Confirmed Wine 11.9 and 11.11 bring no related changes (those releases focused on gaming/DirectX12, not GDI/offscreen rendering). What I'm trying to run A commercial legacy Windows application from around 1999-2000 (proprietary software, name withheld, happy to give more detail if it helps triage), originally built for Windows XP, 32-bit. It has a 3D preview mode for a design the software generates, rendered via Direct3D. Steps to reproduce 1. Open the application and load/create any design. 2. Switch to the 3D simulation/preview view - it renders correctly on screen. 3. Print that 3D view (to a physical printer or a virtual PDF printer), or use the application's own "export to file" option for the 3D view. 4. Open the resulting printed page or exported file. Expected result The printed page or exported file shows the same 3D rendering visible on screen. Actual result The 3D rendering area is replaced by solid black blocks. Everything else on the same page (text, 2D elements, if any) prints/exports correctly. See attached screenshots. Additional notes / troubleshooting already done - 2D printing/export is unaffected: printing or exporting flat 2D drawings and text from the same application works correctly (right colors and proportions), both to a physical printer and to a virtual PDF printer. The bug is specific to the 3D-rendered view. - On-screen rendering is correct: the 3D view displays properly in the application window at all times; the corruption only appears in the printed/exported output, never live on screen. - Tried Wine's virtual desktop (explicit virtual desktop mode, with and without): no change, the exported file still shows black blocks. (Side note: enabling virtual desktop mode also made the mouse pointer noticeably less responsive, unrelated to this bug but mentioned in case it's useful context.) - Tried HKCU\Software\Wine\Direct3D -> OffscreenRenderingMode = backbuffer: no effect. - Tried HKCU\Software\Wine\Direct3D -> renderer = gdi: no effect. - Reproduced identically on two unrelated setups: classic WoW64 (Wine 11.0, wine32+wine64, Linux Mint 21.3) and pure WoW64 (Wine 11.18, no multilib, CachyOS rolling release) - same black-block result in both, which strongly suggests this is not tied to 32-bit vs 64-bit WoW64 architecture, and points instead at something in the Direct3D-to-GDI/offscreen-surface path used when rendering to a printer or file DC instead of the screen. - The black blocks do not follow the silhouette of the original design. Tested with several different designs: in every case the printed/exported result shows a generic grid of rectangular black cells (more or fewer cells depending on the design's size/extent), never the actual shape of the 3D model. This suggests the failure is in a tiling/block-based rendering or compositing step itself (e.g. how the view is divided into regions for printing), rather than a simple loss of texture/color mapped onto the correct geometry. - Happy to test further Wine versions, try additional registry overrides, or provide WINEDEBUG logs (e.g. +d3d, +gdi) if that would help triage. I'd rather not share the application itself, as it's proprietary commercial software. --- -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 60074] New: Incorrect `GL_FRAMEBUFFER_SRGB` handling on the default framebuffer
by WineHQ Bugzilla Oct. 3, 2026

Oct. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=60074 Bug ID: 60074 Summary: Incorrect `GL_FRAMEBUFFER_SRGB` handling on the default framebuffer Product: Wine Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs(a)list.winehq.org Reporter: tpaniaki(a)protonmail.com Target Milestone: --- Distribution: --- Created attachment 81584 --> http://bugs.winehq.org/attachment.cgi?id=81584 Patch Somehow related to https://bugs.winehq.org/show_bug.cgi?id=59436 which has been fixed upstream alternatively. While investigating a color issue affecting Roon under Wine with Xwayland, I found that `GL_FRAMEBUFFER_SRGB` remained enabled while rendering to the default framebuffer. This produced incorrect color output because the default framebuffer should not always inherit the application's logical sRGB state. ### Root cause Wine correctly tracks the logical OpenGL enable state through `set_context_attribute()`, but `GL_FRAMEBUFFER_SRGB` requires additional handling because its physical state depends on the currently bound draw framebuffer. An application may also call: glEnable(GL_FRAMEBUFFER_SRGB); while the default framebuffer is bound. In that case, simply disabling sRGB in `glBindFramebuffer(0)` is not sufficient because the subsequent `glEnable()` immediately re-enables it. ### Proposed solution The patch introduces four changes: 1. Add `GL_FRAMEBUFFER_SRGB` to Wine's tracked enable state. 2. Generate a manual wrapper for `glEnable()`. 3. Prevent the physical `glEnable(GL_FRAMEBUFFER_SRGB)` call when the current draw framebuffer is the default framebuffer, while still updating Wine's logical state through `set_context_attribute()`. 4. Update `set_current_fbo()` so that switching draw framebuffers restores the correct physical OpenGL state: * disable sRGB when binding framebuffer 0; * re-enable it when binding a user FBO if the logical state is enabled. ### Why a wrapper? The wrapper is necessary because `glEnable()` is executed before `set_context_attribute()`. Without intercepting `glEnable(GL_FRAMEBUFFER_SRGB)`, an application can immediately re-enable sRGB on the default framebuffer, bypassing the correction performed during framebuffer switches. ### Validation The patch was tested with Roon, which originally exhibited incorrect colors. Instrumentation confirmed the following sequence: * `glEnable(GL_FRAMEBUFFER_SRGB)` is issued while the default framebuffer is bound. * The wrapper blocks the physical OpenGL enable while preserving the logical state. * When Roon switches to its off-screen FBO, `GL_FRAMEBUFFER_SRGB` is correctly enabled. * When it returns to the default framebuffer, `GL_FRAMEBUFFER_SRGB` is disabled again. The resulting rendering is correct and no regressions were observed during testing. I'd appreciate comments on whether this approach fits Wine's intended handling of framebuffer-dependent OpenGL state, or whether there is a preferred architectural solution. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 59300] New: Hemekonomi: Missing minimize widget
by WineHQ Bugzilla Oct. 3, 2026

Oct. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=59300 Bug ID: 59300 Summary: Hemekonomi: Missing minimize widget Product: Wine Version: 11.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: winehq(a)jonass.user.lysator.liu.se Distribution: --- Created attachment 80238 --> http://bugs.winehq.org/attachment.cgi?id=80238 Wine 11.1 on Xubuntu Hogia Hemekonomi is missing the minimize widget that should be right beside maximize and close. See attachment image. There is Notepad++ in the background to show when the minimize widget is present. To reproduce, download Hemekonomi and untar. Start "wine Hemeko.exe". First time there will be an intro with yellow bakground, dismiss by "Återgå till HemEkonomi" Then there is a dialogue "Sifferformatet under internationell i kontroll-panelen..." (See Bug 53410.) Dismiss by Yes Check window decorations top right. Tested with Wine 11.1 and Wine-9.8, neither shows the minimize widget. For reference I used Notepad++ v 8.9 32-bit x86 Portable zip In Winecfg I tried both XP and 10. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 59775] New: German umlauts won't be handled correctly by typing
by WineHQ Bugzilla Oct. 3, 2026

Oct. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=59775 Bug ID: 59775 Summary: German umlauts won't be handled correctly by typing Product: Wine Version: 11.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: andreas.franz(a)arcor.de Distribution: --- German umlauts (ö, ä, ü) make strange things, if typed on keyboard: - .NET keycode-event don't produce any keycode in an e. g. textbox. But letter is shown correctly in same textbox. Pressing CTRL+<umlaut> produce letter AND keycode. - Pressing "ö" crashes MailStore-Client with "arithmetic" error. Works fine with 11.0 stable. Works fine if Ctrl+ö is pressed, too. I've noticed this behavior since wine 11.8. Copy&Paste works fine in all tested applications. So I think it's something wrong with keyboard-press-eventhandling? Any ideas? regards, Andy -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 54

[Bug 60128] New: Problem with resizing X11 decorated windows in Linux Mint Cinnamon (Muffin WM)
by WineHQ Bugzilla Oct. 3, 2026

Oct. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=60128 Bug ID: 60128 Summary: Problem with resizing X11 decorated windows in Linux Mint Cinnamon (Muffin WM) Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: empcomputer(a)outlook.com.au Target Milestone: --- Distribution: --- Created attachment 81701 --> http://bugs.winehq.org/attachment.cgi?id=81701 Notepad after launch - OK Running Linux Mint 22.3 Cinnamon. If window manager decorations are enabled and a window is resized/maximised/restored, mouse coordinates are reported incorrectly, resulting in an offset between the on-screen cursor position and hit point. Also manifests as a menu activated by keyboard accelerators appearing in incorrect position. I have found that, under certain conditions (can't see a clear pattern, but seems to depend on window position and size), the window manager triggers ConfigureNotify events for the client window before the parent (frame) window. When this happens, the X11 driver computes the window rectangles using the old frame coordinates, leading to the offset problem described earlier. If window manager decorations are disabled, the problem does not occur (there is no frame window in that case). Simple repro steps: - Ensure that "Allow the window manager to decorate the windows" and "Allow the window manager to control the windows" options are checked - Ensure that "Emulate a virtual desktop" is UNchecked - Launch Notepad - Position the window approximately in the centre of the screen (away from the top-left corner) - Maximise the window - Pull down a menu using the keyboard (e.g. Alt+F or Alt+H) - Note that the menu appears away from the expected position - If you restore the window, you'll notice a similar effect (with reversed offsets) - Moving the window using the title bar corrects the coordinates The problem was first noticed in Wine 11.13, but testing shows that it goes back as far as ~10.0. It is more pronounced/consistent in 11.13, but can be triggered sporadically in some earlier versions as well. After looking through the code and some experimenting, one possible fix is to modify the "host_window_map_point" function to use XTranslateCoordinates. I'm not sure if it's the best solution; I imagine there's a good reason it was coded the way it is (e.g. performance issues due to X protocol overhead - I haven't looked into it enough). I hope I have at least provided a good starting point. I'll also note that I have tested it with a few other window managers (Xfwm, Metacity and Compiz, running Linux Mint 22.3 Xfce Live ISO in VirtualBox) and they did not exhibit the same problem. (More attachments to follow...) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 60422] New: About your instructions for using the winehq repo
by WineHQ Bugzilla Oct. 3, 2026

Oct. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=60422 Bug ID: 60422 Summary: About your instructions for using the winehq repo Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: documentation Assignee: wine-bugs(a)list.winehq.org Reporter: ray.schwamberger(a)gmail.com Target Milestone: --- Distribution: --- Not really a bug, but there is a WAY easier method for setting up the winehq repo on debian trixie and sid distributions (and some derivatives like Tuxedo beta). They have a new tool called extrepo, so setting up the winehq repo is as simple as ... sudo apt install extrepo extrepo search winehq // this isn't strictly necessary but will show info sudo extrepo enable winehq sudo apt update sudo apt install winehq-stable (or winehq-staging) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 54471] New: Spider-Man The Movie (2022) black cut-scenes
by WineHQ Bugzilla Oct. 3, 2026

Oct. 3, 2026

https://bugs.winehq.org/show_bug.cgi?id=54471 Bug ID: 54471 Summary: Spider-Man The Movie (2022) black cut-scenes Product: Wine Version: 8.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: legluondunet(a)gmail.com Distribution: --- Hello, I tried to install Spider-Man The Movie (2022) (CD), intro video and all others videos are black, but you can hear sound. The video are encoded with blink codec. I can reproduce this bug with demo of this game available here: https://www.fileplanet.com/archive/p-27762/Spider-Man-The-Movie-Demo My log using wine-staging 8: $ wine SpiderMan.exe 0144:fixme:imm:ImeSetActiveContext (0003008E, 1): stub 0144:fixme:imm:ImmReleaseContext (00040050, 0003008E): stub 012c:fixme:imm:ImeSetActiveContext (000000000002003E, 0): stub 012c:fixme:imm:ImmReleaseContext (00000000000200A8, 000000000002003E): stub 0144:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION 0144:err:d3d:wined3d_restore_display_modes Failed to read the registry display mode for L"\\\\.\\DISPLAY1". 0144:err:d3d:wined3d_swapchain_init Failed to restore display mode. 014c:fixme:d3d:state_linepattern_w Setting line patterns is not supported in OpenGL core contexts. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 6

[Bug 60271] New: Chrome 16 crashes when opening about:memory
by WineHQ Bugzilla Oct. 3, 2026

Oct. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=60271 Bug ID: 60271 Summary: Chrome 16 crashes when opening about:memory Product: Wine Version: 11.16 Hardware: x86-64 URL: https://www.oldversion.com/windows/google-chrome/googl e-chrome-16-0-912-75-1/ OS: Linux Status: UNCONFIRMED Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: lingm+winebz(a)posteo.org Target Milestone: --- Distribution: ArchLinux Created attachment 81990 --> http://bugs.winehq.org/attachment.cgi?id=81990 wine-11.16-console-output Just type "about:memory" into the address bar and hit enter. The tab crashes, although not the entire browser. > $ sha1sum chrome_installer_16.0.912.75.exe > b44af829b88ac422b3c3c8848b631c69bb5a463b chrome_installer_16.0.912.75.exe > $ du -h chrome_installer_16.0.912.75.exe > 24M chrome_installer_16.0.912.75.exe winetricks corefonts doesn't help. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 35319] New: Wolverine: install game crash
by wine-bugs＠winehq.org Oct. 3, 2026

Oct. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=35319 Bug ID: 35319 Summary: Wolverine: install game crash Product: Wine Version: 1.7.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: legluondunet(a)free.fr Classification: Unclassified Created attachment 47105 --> http://bugs.winehq.org/attachment.cgi?id=47105 Wolverine install crash log Hello, when installing Wolverine game, the install window suddenly disappear, without any error message. Fortunately it seems the crash happened after install all files. I joined you the wine terminal log from start to the end of the install process. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

3 13

[Bug 57104] New: every game I try segfaults in the same way in Experimental WOW64 mode
by WineHQ Bugzilla Oct. 3, 2026

Oct. 3, 2026

https://bugs.winehq.org/show_bug.cgi?id=57104 Bug ID: 57104 Summary: every game I try segfaults in the same way in Experimental WOW64 mode Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: redwindwanderer(a)gmail.com Distribution: --- Created attachment 76986 --> https://bugs.winehq.org/attachment.cgi?id=76986 WINE Experimental WOW64 crash log Hi, I build WINE latest gitlab master branch code in a 64bit-only Debian Stable system. I build it like this: ./configure --enable-win64 --without-x --with-wayland --enable-archs=x86_64,i386 However, any games using Directx crash before even starting (backtrace log attached). Is that expected at this point? Shouldn't many games work by now in experimental WOW64 mode or is it still early days? Thanks! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 7

[Bug 60423] New: Rufus installer crashes right from the start
by WineHQ Bugzilla Oct. 3, 2026

Oct. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=60423 Bug ID: 60423 Summary: Rufus installer crashes right from the start Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: wineserver Assignee: wine-bugs(a)list.winehq.org Reporter: fabi.n21(a)web.de Target Milestone: --- Distribution: --- Created attachment 82231 --> http://bugs.winehq.org/attachment.cgi?id=82231 backtrace output from wine debuger when starting the rufus installer over cli "wine rufus-4.15.exe" or over gui, it crashes right from the start. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 60386] New: Compile errors in dlls/opencl/unix_thunks.c
by WineHQ Bugzilla Oct. 2, 2026

Oct. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=60386 Bug ID: 60386 Summary: Compile errors in dlls/opencl/unix_thunks.c Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: opencl Assignee: wine-bugs(a)list.winehq.org Reporter: jeffersoncarpenter2(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82179 --> http://bugs.winehq.org/attachment.cgi?id=82179 Configure command output When I compile the latest version of Wine with opencl not found I get a compile error. I've attached the output of the configure command. Also attached is the output of the make command after running it once so that the error message is near the top. My expected behavior is for the configure command to raise an error and fail. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 60298] New: msvc-wine: freeze / deadlock during build due to a recent regression
by WineHQ Bugzilla Oct. 2, 2026

Oct. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=60298 Bug ID: 60298 Summary: msvc-wine: freeze / deadlock during build due to a recent regression Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: abdullah.ahmed-20(a)outlook.com CC: julliard(a)winehq.org Target Milestone: --- Distribution: --- Created attachment 82046 --> http://bugs.winehq.org/attachment.cgi?id=82046 Output Log where msbuild freezes on dllmain.cpp Hello, There has been a regression in the recently released Wine 11.17, building msvc projects using msvc-wine's msbuild can cause a freeze / deadlock where winedevice.exe will continue using CPU resources (3.2% in my case) infinitely and stall, and msbuild will hang until I manually kill winedevice.exe and then it will proceed to compile / build the project as it normally used to in Wine 11.16. I've tested for regressions as suggested in the Wiki and it seems to be the "2ecc2f84b45ec42afbf1725d756181180a8204b1" commit (linked below) authored by Evan Morse and committed by Alexandre Julliard that causes this issue, reverting that commit fixes the issue. Links to the msvc-wine project and the commit are below, system and architecture are Arch Linux x86_64. I tried to follow the Wiki for Bug Reporting to my best ability, if anything else is required please let me know. Links: msvc-wine: https://github.com/mstorsjo/msvc-wine Commit: https://gitlab.winehq.org/wine/wine/-/commit/2ecc2f84b45ec42afbf1725d756181… Thanks! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 45969] New: ArcGIS Pro crashes on start
by wine-bugs＠winehq.org Oct. 2, 2026

Oct. 2, 2026

https://bugs.winehq.org/show_bug.cgi?id=45969 Bug ID: 45969 Summary: ArcGIS Pro crashes on start Product: Wine Version: 3.17 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Created attachment 62523 --> https://bugs.winehq.org/attachment.cgi?id=62523 console output To reproduce: 1. Run `winetricks dotnet461`. This is a prerequisite of ArcGIS Pro. 2. Run `wine ArcGISPro_22_163783.exe`. Note that this is a 64-bit program. 3. Run `wine 'C:\Program Files\ArcGIS\Pro\bin\ArcGISPro.exe'`. Console output is attached. $ sha256sum ArcGISPro_22_163783.exe b6acceb36d51cdb1cc283478fd6170b7e51630f127ea4c841fef67d662d40f1e -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 11

[Bug 60343] New: Euro Truck Simulator 2 fails to start using OpenGL renderer with the EGL backend
by WineHQ Bugzilla Oct. 2, 2026

Oct. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=60343 Bug ID: 60343 Summary: Euro Truck Simulator 2 fails to start using OpenGL renderer with the EGL backend Product: Wine Version: 11.12 Hardware: x86-64 URL: https://store.steampowered.com/app/227300/Euro_Truck_S imulator_2/ OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com CC: rbernon(a)codeweavers.com Target Milestone: --- Regression SHA1: e0a0ab55202d78f5cb85a81433b91f1d53b9d4b2 Distribution: --- Euro Truck Simulator 2 fails to start when its OpenGL renderer is selected while Wine is using the EGL OpenGL backend ("no valid graphics device was found" error). The DirectX 11 renderer continues to work. Reproducible with the Euro Truck Simulator 2 Demo available on Steam (download size 23 GiB!). Select <Launch with OpenGL> from the launch options. This is a regression between Wine 11.11 and Wine 11.12 and is still present in Wine 11.17-git. I identified the following commit as the first bad commit: commit e0a0ab55202d78f5cb85a81433b91f1d53b9d4b2 win32u: Share all unix-side GL contexts with a global context. The parent of this commit works: the game starts successfully with its OpenGL renderer. A regular Wine terminal log does not show any additional useful error messages. Game: Euro Truck Simulator 2, Steam version 1.61.1.0s GPU: NVIDIA GeForce GTX 1660 SUPER Driver: NVIDIA proprietary driver 615.71.09 Desktop session: X11 / XFCE wine-11.17-322-g67eb19d662b -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 60117] New: Evolution: The Game of Intelligent Life demo fails to start
by WineHQ Bugzilla Oct. 2, 2026

Oct. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=60117 Bug ID: 60117 Summary: Evolution: The Game of Intelligent Life demo fails to start Product: Wine Version: 8.5 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: imm32 Assignee: wine-bugs(a)list.winehq.org Reporter: alexhenrie24(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81675 --> http://bugs.winehq.org/attachment.cgi?id=81675 WINEDEBUG=+imm,+msgbox Steps to reproduce: 1. Run `wine Evolution-The-Game-of-Intelligent-Life_Demo_Win_EN.exe` 2. Run `LIBGL_ALWAYS_SOFTWARE=1 wine 'C:\Program Files (x86)\Discovery Multimedia\EvoDemo\EvoDemo.exe'` LIBGL_ALWAYS_SOFTWARE=1 is necessary to avoid a DirectDraw DDERR_OUTOFVIDEOMEMORY error. In Wine 8.4 and before, the game shows three error dialogs on start that say "MEM_BAD_HANDLE" and then one more when you start the game, but the game is playable. In Wine 8.5 and later, the game shows one error dialog on start that says "SmartHeap error handler recursively re-entered." Then the game simply exits. `git bisect` says: db5cf9a5e12b6e8f664f54a626f4cf6efc2bfbf3 is the first 'bad' commit commit db5cf9a5e12b6e8f664f54a626f4cf6efc2bfbf3 Author: Rémi Bernon <rbernon(a)codeweavers.com> AuthorDate: Mon Mar 27 14:45:42 2023 +0200 Commit: Alexandre Julliard <julliard(a)winehq.org> CommitDate: Tue Mar 28 11:55:31 2023 +0200 imm32: Use installed IME language for the created HKL. Notes: Approved-by: Alexandre Julliard (@julliard) Merge-Request: https://gitlab.winehq.org/wine/wine/-/merge_requests/2520 dlls/imm32/Makefile.in | 2 +- dlls/imm32/imm.c | 26 ++++++++++++++++++++++---- dlls/imm32/tests/imm32.c | 1 - 3 files changed, 23 insertions(+), 6 deletions(-) Reverting that specific commit atop current master makes the game playable again. Terminal output from Wine 11.14 with WINEDEBUG=+imm,+msgbox is attached. $ sha256sum Evolution-The-Game-of-Intelligent-Life_Demo_Win_EN.exe d0d63338ce0c79e081511f932191b7b3da8d94546251dc240b42af59d3f79ea9 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 58319] New: winevdm crashes running Quicktime 2
by WineHQ Bugzilla Oct. 2, 2026

Oct. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=58319 Bug ID: 58319 Summary: winevdm crashes running Quicktime 2 Product: Wine Version: 10.8 Hardware: x86-64 URL: http://www.oldversion.com/windows/quicktime-2-1-2 OS: Linux Status: NEW Keywords: download, win16 Severity: normal Priority: P2 Component: user16 Assignee: wine-bugs(a)winehq.org Reporter: imwellcushtymelike(a)gmail.com Distribution: Ubuntu Created attachment 78677 --> http://bugs.winehq.org/attachment.cgi?id=78677 Wine 10.9 backtrace Running c:\windows\player.exe, part of Quicktime 2, crashes winevdm and the application cannot be used. Workarounds: - Hacked krnl386.exe16 as per https://bugs.winehq.org/attachment.cgi?id=51212 (Bug 18260) Looks like a fixme might be offering the explanation: 0168:fixme:hook:SetWindowsHookEx16 System-global hooks (3) broken in Win16 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 5