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

[Bug 53847] New: NfRemote: mouse input ignored
by WineHQ Bugzilla May 23, 2026

May 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=53847 Bug ID: 53847 Summary: NfRemote: mouse input ignored Product: Wine Version: 7.0 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: thelen(a)radiomankato.com https://www.telosalliance.com/uploads/Omnia%20Products/Software/NfRemote.exe Say hello to nfremote. It's a little piece of software used to administer a particular manufacturer's equipment, commonly used at radio and TV stations. I can confirm it has, and does, work fine under Wine 2.21 - just tested today on a MacBookPro8,1 running the official binaries (https://dl.winehq.org/wine-builds/macosx/pool/winehq-staging-2.21.pkg) under OS 10.13.6. Meanwhile, I have a new Mac (MacBookPro16,2 - Intel-based), on which I’ve deployed Wine 7.0 via homebrew under OS 12.6.1. There I can start nfremote just fine... but it ignores my mouse input. If I were to start it with the command-line argument "run", it presents me with a window where both keyboard and mouse input are accepted; there I can type in the text fields, so I know it's responsive. But when I hover the cursor over buttons, they do not 'light up’ to indicate such. And when I click, nothing happens. Even in years past, I found that newer versions of Wine exhibited the issue I describe below, so I simply never updated beyond 2.21. Wonder if this might be a long-undiscovered regression of some sort? -- 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 59758] New: Wiki: Use of extended regular expressions with grep in the "Debug Channels" page, without the E flag
by WineHQ Bugzilla May 23, 2026

May 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59758 Bug ID: 59758 Summary: Wiki: Use of extended regular expressions with grep in the "Debug Channels" page, without the E flag Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: www-unknown Assignee: wine-bugs(a)list.winehq.org Reporter: barathrk11(a)gmail.com Distribution: --- In the page https://gitlab.winehq.org/wine/wine/-/wikis/Debug-Channels, the following line: $ grep -r --include='*.c' --include='*.h' 'WINE_(DEFAULT|DECLARE)_DEBUG_CHANNEL' dlls/ programs/ only seems to work when the -E flag is specified(grep -rE). The -E flag is specified in the example immediately after this one, however: for modname in $(find dlls/ programs/ -mindepth 1 -type d | sort); do echo $(grep -rE --include='*.[ch]' '^WINE_(DEFAULT|DECLARE)_DEBUG_CHANNEL' $modname \ | awk -F "[()]" '{print $2}' | sort | uniq) \ | awk -v modname=$modname '{if (NF>0) printf("%-*s%s\n", 26, modname": ", $0)}'; done -- 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 59759] New: Crash using bottles 63.2
by WineHQ Bugzilla May 23, 2026

May 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59759 Bug ID: 59759 Summary: Crash using bottles 63.2 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: abcd0000(a)poczta.onet.pl Distribution: --- Created attachment 80957 --> http://bugs.winehq.org/attachment.cgi?id=80957 callstack rom debugger Crash happens on both fedora (latest) and ubuntu (24.04.4), when I run fusion 360 ti runs AdskIdentityManager and this application crash. -- 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 52330] New: iZotope software authorization process fails
by WineHQ Bugzilla May 23, 2026

May 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=52330 Bug ID: 52330 Summary: iZotope software authorization process fails Product: Wine-staging Version: 7.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: christian.frech(a)protonmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 71492 --> https://bugs.winehq.org/attachment.cgi?id=71492 journalctl log during authorization process Authorizing iZotope software will result in an error. According to the iZotope Support, the attempt is visible, but the local application did not recognize that. Also see attachment. -- 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 22

[Bug 59765] New: wineserver: performance regression in newer Wine versions (apparently related to Winsock/socket polling)
by WineHQ Bugzilla May 23, 2026

May 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59765 Bug ID: 59765 Summary: wineserver: performance regression in newer Wine versions (apparently related to Winsock/socket polling) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)list.winehq.org Reporter: csoresz2(a)gmail.com Distribution: --- Created attachment 80967 --> http://bugs.winehq.org/attachment.cgi?id=80967 CPU usage on various Ubuntu versions Hello Wine developers, I would like to report what looks like a significant wineserver performance regression in newer Wine versions, apparently related to Winsock/socket polling. We run a Windows application stack under Wine on Linux. The architecture is roughly: - one main Windows service process running under Wine - many child worker processes launched by that service - each worker process receives RTSP video streams from IP cameras - the RTSP implementation uses live555 internally - the streams mostly use RTSP/RTP over TCP - a typical system runs around 50-60 worker processes under the same Wine prefix The same workload behaves very differently on two otherwise similar machines: Old system: Ubuntu 20.x + Wine 5.x New system: Ubuntu 26.x + Wine 11.8 On the old system, wineserver uses about 25% of one CPU core and the application runs well. On the new system, wineserver frequently reaches 100% of one CPU core and becomes a bottleneck. Basically anything above Ubuntu 20.x and Wine 5.x is using more CPU. Tested on roughly 50 Linux servers with exactly the same Windows application. See the attachment. Wine versions tested: - wine-5.0 (Ubuntu 5.0-3ubuntu1) - wine-9.0 (Ubuntu 9.0~repack-4build3) - wine-9.15 - wine-10.12 - wine-10.16 - wine-10.19 - wine-11.0 - wine-11.8 Ubuntu versions tested: - 20.04 - 22.04 - 24.04 - 25.10 - 26.04 Let's stick to the original lineup: Ubuntu 20.x + Wine 5.x VS Ubuntu 26.x + Wine 11.8 I collected strace -c data from the wineserver process on both systems under comparable load. On the newer Wine/Linux system, the wineserver syscall profile looks approximately like this: ioctl ~280,000 calls read ~250,000 calls write ~132,000 calls epoll_ctl ~142,000 calls getsockopt ~52,000 calls poll ~50,000 calls On the older Wine/Linux system, the same workload looks very different: write ~443,000 calls read ~462,000 calls epoll_wait ~18,000 calls epoll_ctl ~209 calls poll ~95 calls getsockopt ~6 calls The most striking difference is epoll_ctl: roughly 142,000 calls on the new system versus only about 200 on the old system. ioctl, getsockopt, and poll are also much higher on the newer Wine/Linux system. I also installed debug symbols and profiled wineserver with perf. The hot path on the new system is mostly: main_loop_epoll fd_poll_event thread_poll_event read_request call_req_handler req_ioctl poll_socket sock_poll_event sock_reselect sock_get_poll_events There is also time under: req_select select_on end_wait object_sync_satisfied async_satisfied async_set_result async_reselect sock_reselect_async sock_reselect sock_get_poll_events I also traced epoll_ctl calls. Almost all of them are EPOLL_CTL_MOD, not ADD/DEL: EPOLL_CTL_ADD 2 EPOLL_CTL_DEL 2 EPOLL_CTL_MOD 11625 The event masks are constantly being toggled, mostly between no events and readable/priority events: events=0 5842 events=EPOLLIN|EPOLLPRI 3711 events=EPOLLIN 1961 events=EPOLLOUT 100 events=EPOLLPRI 9 events=EPOLLPRI|EPOLLOUT 2 The affected file descriptors are mostly TCP sockets, including RTSP camera connections such as: TCP:[local_ip:port->camera_ip:554] This strongly suggests that the newer Wine version is doing much more wineserver-side socket re-selection / epoll event mask modification for the same Winsock workload. The application uses live555, so the socket behavior is probably based on normal Winsock select() / ioctlsocket() / recv() style logic. I tried several application-side experiments, including increasing the live555 select() timeout and changing scheduler behavior, but these did not produce a useful improvement. This makes me suspect the regression may be in the Wine socket / wineserver handling path rather than in the application logic itself. The main symptom is that the newer Wine version appears to generate a very large amount of: req_ioctl -> poll_socket -> sock_reselect -> sock_get_poll_events -> epoll_ctl(EPOLL_CTL_MOD) activity for many concurrent TCP RTSP streams, while Wine 5 on the older system does not. Could this be a known change or regression in wineserver socket polling, async socket handling, or Winsock select() / ioctlsocket() emulation between Wine 5 and newer Wine versions? If there is anything we can provide to help investigate this, please let us know. Thank you for your work on Wine. Best regards -- 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 45461] New: OnScreenKeyboard Portable: App displays splash screen but does not start
by wine-bugs＠winehq.org May 23, 2026

May 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=45461 Bug ID: 45461 Summary: OnScreenKeyboard Portable: App displays splash screen but does not start Product: Wine Version: 3.12 Hardware: x86-64 URL: https://portableapps.com/apps/accessibility/on-screen_ keyboard_portable OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tobbi.bugs(a)googlemail.com Created attachment 61801 --> https://bugs.winehq.org/attachment.cgi?id=61801 log After installing (extracting) OnScreenKeyboard Portable and tryin to run it, it does show the splash screen but does not start the actual program. $ openssl sha256 On-ScreenKeyboardPortable_2.0.paf.exe SHA256(On-ScreenKeyboardPortable_2.0.paf.exe)= 12c4943e1d7a65a12f7c58ac5aac3430b98c5158f18a94c51c26036770af19df -- 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 5

[Bug 56034] New: Borland Turbo CPP 4.5 installer hangs after opening INSTALL.TXT
by WineHQ Bugzilla May 23, 2026

May 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=56034 Bug ID: 56034 Summary: Borland Turbo CPP 4.5 installer hangs after opening INSTALL.TXT Product: Wine Version: 9.0-rc2 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 75680 --> https://bugs.winehq.org/attachment.cgi?id=75680 Patch that fixes the first hang Note that the installer is INSTALL.EXE, not SETUP.EXE. If you click Continue, the installer opens INSTALL.TXT in Notepad. When you close Notepad, the installer should continue, but instead it hangs. If you click Skip, the installer works but hangs after installation. The attached patch fixes the problem, mostly. For some reason you have to click the background after closing Notepad, and the installer still hangs at the end. I don't know how close the patch is to a correct solution. $ sha256sum 'Borland Turbo CPP 4.5 for Windows.7z' 8a6f5797f0af880728421426beacf5e5760701e424d89e14cd714a13e625f2ff -- 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 53355] New: Missing functions SystemTimeToTzSpecificLocalTimeEx and TzSpecificLocalTimeToSystemTimeEx
by WineHQ Bugzilla May 23, 2026

May 23, 2026

https://bugs.winehq.org/show_bug.cgi?id=53355 Bug ID: 53355 Summary: Missing functions SystemTimeToTzSpecificLocalTimeEx and TzSpecificLocalTimeToSystemTimeEx Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: osmanx(a)problemloesungsmaschine.de Distribution: --- Created attachment 72743 --> https://bugs.winehq.org/attachment.cgi?id=72743 tz.exe Please implement SystemTimeToTzSpecificLocalTimeEx and TzSpecificLocalTimeToSystemTimeEx. The documentation can be found at <https://docs.microsoft.com/en-us/windows/win32/api/timezoneapi/nf-timezonea…> and <https://docs.microsoft.com/en-us/windows/win32/api/timezoneapi/nf-timezonea…>. Note that because these functions currently outright abort, the work-around I implemented requires explicitly detecting Wine and not even trying to call them, which is far from optimal. Even just implementing stubs that always fail gracefully instead of just aborting the whole process would be much appreciated. This came up when improving local timezone handling in OpenMPT. See <https://bugs.openmpt.org/view.php?id=1618> and <https://source.openmpt.org/browse/openmpt?op=comp&compare[]=/trunk/OpenMPT/…>. Simple test case (for SystemTimeToTzSpecificLocalTimeEx): tz.cpp: ``` #include <iostream> #include <stdexcept> #include <windows.h> int main() { try { SYSTEMTIME sys{}; GetSystemTime(&sys); DYNAMIC_TIME_ZONE_INFORMATION dtzi{}; if (GetDynamicTimeZoneInformation(&dtzi) == TIME_ZONE_ID_INVALID) { throw std::runtime_error("GetDynamicTimeZoneInformation() failed."); } SYSTEMTIME sys_local{}; if (SystemTimeToTzSpecificLocalTimeEx(&dtzi, &sys, &sys_local) == FALSE) { throw std::runtime_error("SystemTimeToTzSpecificLocalTimeEx() failed."); } std::cout << "OK" << std::endl; return 0; } catch (const std::exception & e) { std::cout << std::flush; std::cerr << e.what() << std::endl; std::cerr << std::flush; } std::cout << "FAIL" << std::endl; return 1; } ``` built with VS2022 by running `cl /std:c++20 /permissive- /EHsc /O2 /W4 tz.cpp` results in ``` wine: Call from 0x7bc7c990 to unimplemented function KERNEL32.dll.SystemTimeToTzSpecificLocalTimeEx, aborting ``` not even reaching the FAIL output. tz.exe attached. -- 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 2

[Bug 59782] New: Diablo (GOG): Menu screen is completely white, though functional.
by WineHQ Bugzilla May 22, 2026

May 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=59782 Bug ID: 59782 Summary: Diablo (GOG): Menu screen is completely white, though functional. Product: Wine Version: 11.0-rc3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: chiitoo(a)gentoo.org Regression SHA1: 98d1f8bb3847b18ca0797cbc58e9a65311a21381 Distribution: Gentoo Created attachment 80990 --> http://bugs.winehq.org/attachment.cgi?id=80990 log at wine-11.9-86-gcf80269f7e9 After 98d1f8bb384 [1] Diablo / Hellfire menu screen is completely white, though functional. This is the GOG-modified version; need to find my CDs to try the original, too... As a side-note, perhaps uninterestingly, the screen is black instead without 18339eb0f50 [2] which is related to bug 59109 [3], and I can see flashes of white in the menu here too. Before it turns all-white that is. There's one difference I can see in regular logging with the whiteness happening, though it's printed only after exiting the game via ESC: fixme:d3d_shader:glsl_blitter_upload_palette P8 texture loaded without a palette. There's also another issue before this, where the menu rendering isn't updated except for when moused over, which looks like painting/erasing away the black from covering the screen, or when moving the menu selection with arrow keys. Could not find a bug for that, so maybe that will happen after this. The game itself seems to work just fine in any case, though have only tried moving around the starting area a little bit so far. Thank you! 1. https://gitlab.winehq.org/wine/wine/-/commit/98d1f8bb3847b18ca0797cbc58e9a6… 2. https://gitlab.winehq.org/wine/wine/-/commit/18339eb0f5048500efb668e6a9b679… 3. https://bugs.winehq.org/show_bug.cgi?id=59109 -- 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 46803] New: Diablo 1 GOG.com crash
by wine-bugs＠winehq.org May 22, 2026

May 22, 2026

https://bugs.winehq.org/show_bug.cgi?id=46803 Bug ID: 46803 Summary: Diablo 1 GOG.com crash Product: Wine Version: 4.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xzgamertag(a)mail.com Distribution: --- Created attachment 63823 --> https://bugs.winehq.org/attachment.cgi?id=63823 Log Diablo crashes immidiately after skipping intro, while using hi-res, latest version. When I try to run Diablo (Classic) version, it requires original CD to proceed. -- 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 17