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

[Bug 59237] New: EGS game (NSFW) not displaying properly (vertical offset when windowed, blank screen when full screen)
by WineHQ Bugzilla July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=59237 Bug ID: 59237 Summary: EGS game (NSFW) not displaying properly (vertical offset when windowed, blank screen when full screen) Product: Wine Version: 11.0-rc5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: tbterry0(a)yahoo.com Distribution: --- The EGS game (adult game) is not working properly with recent Wine versions (including 11.0rc5: it however works fine with Wine 10.2 or older). That game is available here: https://mega.nz/folder/EC1AnajC#Woaxul8_aI91GViGiop7xw When used in windowed mode, the display is shifted downwards in the window and a white strip appears at the top. When used in full screen mode, the whole screen becomes blank (white). -- 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 59767] New: loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations
by WineHQ Bugzilla July 5, 2026

July 5, 2026

http://bugs.winehq.org/show_bug.cgi?id=59767 Bug ID: 59767 Summary: loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations Product: Wine Version: 11.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: loader Assignee: wine-bugs(a)list.winehq.org Reporter: arraybolt3(a)gmail.com Distribution: --- This is kind of a weird bug as it doesn't have anything to do with Windows applications in particular, but rather with how Wine registers itself with the system. loader/wine.desktop registers Wine as a MIME handler for a number of different Windows-related executable file formats (EXEs, MSIs, and Batch files. Linux doesn't recognize these files as programs (unless they have their executable bit set and are registered with binfmt-misc of course), so it will attempt to "open" these files with Wine. Wine will then run arbitrary code within these programs with the privileges of whatever program launched Wine. On the surface, this doesn't sound like a problem, but it becomes an issue because sandboxed code under Linux can usually use D-Bus to open files in their default application *outside of the sandbox*. Since the default application to open EXE files in is Wine, anything that can open arbitrary files outside of the sandbox can now escape the sandbox by writing an EXE file somewhere and then "opening" it with Wine. There are two ways I know of to do this: * Some file managers handle the org.freedesktop.FileManager1.ShowFolders method call by opening the "folders" they are told to open with their default application. Of course, there is no guarantee that the "folders" actually are folders; if the sandboxed app passes a file name in this call, those file managers will open the specified files in their default application. If Wine is installed, and one of the "folders" specified is an EXE file, the application can now run arbitrary code outside of the sandbox. (I reported this bug to an affected file manager over 90 days ago.) * xdg-desktop-portal-gtk intentionally allows applications to open arbitrary files outside of a sandbox, via the org.freedesktop.portal.OpenURI.OpenFile D-Bus method. If there are multiple applications that can open the same file type, it will usually open a dialog asking what application to open the file in, but if there is only one handler for a file type on the system, it will immediately open the file with its default handler. Handlers for EXE files other than Wine are relatively rare (lxqt-archiver is one, oddly enough), so there is a very good chance that a sandboxed app can just write an EXE file to the disk, then open it with xdg-desktop-portal-gtk and have code execution outside the sandbox. (I reported this privately to the Flatpak developers over 90 days ago.) Arguably, neither of these issues are security vulnerabilities in xdg-desktop-portal or file managers. The `xdg-mime` manpage warns: Security Note: Never set a handler that will blindly execute code or commands from the file being handled. Such behavior will sooner than later lead to unintended code execution i.e. through a curious user trying to inspect a freshly downloaded file but running it by accident. Keeping opening and executing separate actions helps with people protecting themselves from malware, the default handler is an opener, not a runner. Therefore I believe this is an issue with Wine. -- 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 24

[Bug 59129] New: Parallel Port Tester fails to detect the parallel port's base I/O address
by WineHQ Bugzilla July 5, 2026

July 5, 2026

http://bugs.winehq.org/show_bug.cgi?id=59129 Bug ID: 59129 Summary: Parallel Port Tester fails to detect the parallel port's base I/O address Product: Wine Version: 11.0-rc1 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: wmi&wbemprox Assignee: wine-bugs(a)list.winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Steps to reproduce: 1. Use a computer with a motherboard-attached or PCI-attached parallel port. USB-attached parallel ports do not have base I/O addresses and Parallel Port Tester ignores them. 2. Ensure that /dev/lp0 exists and works outside of Wine, for example by connecting the parallel port to a printer or to an LED tester, running `echo hello > /dev/lp0`, and seeing the word printed on the printer or seeing different LEDs light up on the tester. 3. (Optional) Figure out what the base address of the parallel port is by looking at DEVNAME in /sys/class/printer/lp0/device/ppdev/parport0/uevent, then reading the first number in /proc/sys/dev/parport/<DEVNAME>/base-addr. You will need to convert the value to hexadecimal and prepend "0x" if you want to manually enter it into Parallel Port Tester. 4. Run `wine ParallelPortTesterSetup-1.0.0.2.exe` 5. Run `wine 'C:\Program Files (x86)\Parallel Port Tester\ParallelPortTester.exe'` 6. Click the drop-down labeled "Port" in the lower-right corner of the window. When my desktop computer is booted into Windows and I click the drop-down in Parallel Port Tester, it offers "LPT3 (0xEFF8)" as an option. When the same computer is booted into Linux and I run Parallel Port Tester on Wine, the drop-down is empty. However, if I run it on Wine with https://gitlab.com/alexhenrie/ioperm and enter the parallel port's base address manually, the program correctly displays the states of the parallel port's pins and can manipulate them. That means that the main part of the program works, it's just failing to automatically detect the port. The author helpfully wrote up an explanation of what the program does to find parallel ports and their base addresses: https://www.downtowndougbrown.com/2014/11/detecting-parallel-ports-and-thei… $ sha256sum ParallelPortTesterSetup-1.0.0.2.exe 9e9b399dd92ac48433af2061eb8491d1d68a6134eaeab2efcdcd36361e723d09 -- 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 3

[Bug 44920] New: Starcraft II Arcade Crash during load
by wine-bugs＠winehq.org July 5, 2026

July 5, 2026

https://bugs.winehq.org/show_bug.cgi?id=44920 Bug ID: 44920 Summary: Starcraft II Arcade Crash during load Product: Wine Version: 3.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: antonio.e.russo(a)gmail.com Distribution: --- Created attachment 61011 --> https://bugs.winehq.org/attachment.cgi?id=61011 WINEDEBUG=warn+all log of crash (gzipped) Starcraft II is a moving target. After the most recent patch, I was unable to use wine-staging 2.21, which had been working excellently for me. Wine 3.5 has trouble: loading the "Hero Attack 3X" (popular) arcade game, the game crashes. I've attached a "WINEDEBUG=warn+all" log, and can help debug. I checked "use 32-bit version", and I am using a clean prefix. -- 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.

4 26

[Bug 26011] New: BitLocker.exe not working with wine
by wine-bugs＠winehq.org July 5, 2026

July 5, 2026

http://bugs.winehq.org/show_bug.cgi?id=26011 Summary: BitLocker.exe not working with wine Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: paloseco(a)gmail.com Created an attachment (id=33174) --> (http://bugs.winehq.org/attachment.cgi?id=33174) Log of the BitLocker.exe errors when trying to load USB Removable BitLocker.exe is a tool for reading/writing partitions or USB removable media encrypted with the BitLocker application included with Windows 7 Ultimate (similar to TrueCrypt). The pendrives encrypted include the portable application to read/write from windows xp platform. >From winecfg I've created a new drive pointing to the folder where the USB Removable is mounted, but doesn't work due to unimplemented features. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 59935] New: Request to implement NtLockFile
by WineHQ Bugzilla July 5, 2026

July 5, 2026

http://bugs.winehq.org/show_bug.cgi?id=59935 Bug ID: 59935 Summary: Request to implement NtLockFile Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: chenyutao0706(a)gmail.com Distribution: --- NtLockFile has been missing in Wine for a long time, and it doesn't seem like there has been much progress on it. e.g, When running: wine zig.exe cc test.zig it breaks the Zig compiler. After looking into Zig's source code, I'm fairly confident this is the root cause of why `zig cc` fails under Wine. Here are the relevant logs: 0024:fixme:file:NtLockFile Unimplemented yet parameter 012c:fixme:file:NtLockFile Unimplemented yet parameter 0150:fixme:file:NtLockFile Unimplemented yet parameter 014c:fixme:file:NtLockFile Unimplemented yet parameter 0144:fixme:file:NtLockFile Unimplemented yet parameter 0114:fixme:file:NtLockFile Unimplemented yet parameter 00f4:fixme:file:NtLockFile Unimplemented yet parameter 010c:fixme:file:NtLockFile Unimplemented yet parameter 0138:fixme:file:NtLockFile Unimplemented yet parameter 0108:fixme:file:NtLockFile Unimplemented yet parameter 0140:fixme:file:NtLockFile Unimplemented yet parameter 013c:fixme:file:NtLockFile Unimplemented yet parameter 00f0:fixme:file:NtLockFile Unimplemented yet parameter 00fc:fixme:file:NtLockFile Unimplemented yet parameter 0134:fixme:file:NtLockFile Unimplemented yet parameter 0110:fixme:file:NtLockFile Unimplemented yet parameter 0148:fixme:file:NtLockFile Unimplemented yet parameter 0120:fixme:file:NtLockFile Unimplemented yet parameter 00f8:fixme:file:NtLockFile Unimplemented yet parameter 00e8:fixme:file:NtLockFile Unimplemented yet parameter 0130:fixme:file:NtLockFile Unimplemented yet parameter 011c:fixme:file:NtLockFile Unimplemented yet parameter 0104:fixme:file:NtLockFile Unimplemented yet parameter 0118:fixme:file:NtLockFile Unimplemented yet parameter 0124:fixme:file:NtLockFile Unimplemented yet parameter 0100:fixme:file:NtLockFile Unimplemented yet parameter error: sub-compilation of mingw-w64 crt2.o failed note: failed to check cache: manifest_create Unexpected error: sub-compilation of compiler_rt failed note: failed to check cache: manifest_create Unexpected error: sub-compilation of mingw-w64 libmingw32.lib failed note: failed to check cache: manifest_create Unexpected error: unable to generate mingw DLL import .lib file for api-ms-win-crt-conio-l1-1-0: CacheCheckFailed Z:\lib\zig\c.zig:1:1: error: unable to load 'c.zig': Unexpected Z:\lib\zig\std\std.zig:1:1: error: unable to load 'std.zig': Unexpected Z:\lib\zig\ubsan_rt.zig:1:1: error: unable to load 'ubsan_rt.zig': Unexpected -- 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 10

[Bug 59962] New: dinput: buffered keyboard events visible to the game before the corresponding window message is pumped, causing GUI double-activation in Neverwinter Nights (Diamond 1.69)
by WineHQ Bugzilla July 4, 2026

July 4, 2026

http://bugs.winehq.org/show_bug.cgi?id=59962 Bug ID: 59962 Summary: dinput: buffered keyboard events visible to the game before the corresponding window message is pumped, causing GUI double-activation in Neverwinter Nights (Diamond 1.69) Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: olanordmann(a)duck.com Distribution: --- Created attachment 81349 --> http://bugs.winehq.org/attachment.cgi?id=81349 WINEDEBUG=+key,+dinput, 1000 lines around five V presses In Neverwinter Nights (2002, GOG Diamond Edition 1.69, 32-bit), pressing a GUI hotkey (V = quickchat menu, Enter = chat bar focus) opens the GUI element and immediately closes it again ("flash"), unless the key is released extremely quickly. Text typing inside the chat is unaffected. The game is unaffected on real Windows 10/11 on the same machine. The game uses DirectInput (dinput.dll, DirectInputCreateA, keyboard device with SetCooperativeLevel DISCL_NONEXCLUSIVE | DISCL_FOREGROUND) for world hotkeys, polling GetDeviceData every frame, and window messages (WM_KEYDOWN/WM_CHAR) for its GUI. It Unacquires the keyboard while a GUI element is open and re-Acquires on close. A WINEDEBUG=+key,+dinput trace shows the failure sequence for one single physical key press (X11 delivers exactly one KeyPress; xev confirms no duplicate events; auto-repeat disabled via `xset r off` does not change the behavior): ``` X11DRV_KeyEvent KeyPress keysym=76 (v) # one physical press X11DRV_send_keyboard_input vkey=0056 scan=002f flags=0000 input_thread_ll_hook_proc calling dinput_keyboard_hook # dinput queue filled immediately dinput_keyboard_hook wparam 0x100 vkCode 0x56 # from Wine's input thread [game polls GetDeviceData, sees V press, OPENS quickchat menu] dinput_device_Unacquire # game switches to GUI input mode NtUserTranslateMessage Translating key VK_V (0056) # the SAME keystroke's message NtUserTranslateMessage -> PostMessage WM_CHAR "v" # is pumped only now [the now-open menu receives WM_KEYDOWN/WM_CHAR for V and CLOSES] dinput_device_Acquire # game back in world mode ``` The dinput buffered event is enqueued by Wine's dedicated input thread (low-level hook path) and becomes visible to the game's GetDeviceData poll *before* the game's main thread has pumped the WM_KEYDOWN for the same keystroke. The game acts on the dinput copy first (opens menu), then acts on the message copy (menu closes). On Windows the game evidently never observes this ordering. Only world→GUI transitions double-fire. Closing a GUI element is always clean, because the keyboard is unacquired while the GUI is open, so only the message path is active — consistent with the analysis. **Workarounds tried, all ineffective or impossible:** - wine 10.20, 11.5, 11.10, 11.11, wine-cachyos (proton-derived): identical behavior - Disabling dinput via WINEDLLOVERRIDES: nwmain.exe statically imports DINPUT.dll → fails to load - Native Win10/11 dinput.dll: crashes (delay-loads ext-ms-win-mininput-inputhost-l1-1-0.dll, not provided by Wine) - X11 and Wayland sessions, virtual desktop mode, autorepeat off, vsync on/off: no difference **Steps to reproduce:** 1. Install NWN Diamond (GOG) in a 32-bit-capable prefix, run nwmain.exe 2. Start any module, press V at a normal speed (hold ~100–300 ms) 3. Quickchat menu opens and instantly closes; releasing the key within a few tens of ms keeps it open **System:** Arch Linux (CachyOS), kernel 7.1.1-2-cachyos, KDE Plasma 6.7.1 (X11 and Wayland), NVIDIA RTX 4090 (proprietary 610.43.02), wine 11.11 (also reproduced 10.20/11.5/11.10) **Attachment:** nwn-dinput-trace-excerpt.log (WINEDEBUG=+key,+dinput, 1000 lines around five V presses; full 4.4 MB log available on request) -- 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 39303] New: Cannot copy schematics between different windows / ltspice
by wine-bugs＠winehq.org July 4, 2026

July 4, 2026

https://bugs.winehq.org/show_bug.cgi?id=39303 Bug ID: 39303 Summary: Cannot copy schematics between different windows / ltspice Product: Wine Version: 1.7.51 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dieter.jurzitza(a)t-online.de Distribution: --- Trying to copy parts or an entire schematic between two schematics in two windows from within ltspice does not work. I can easily select components to copy, I can copy them within one single schematic, but I cannot copy them between two different schematics in a single ltspice instance (what works without issues using plain windows, but who is using plain windows :-)) Thank you for looking into this, take care Dieter Jurzitza -- 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 8

[Bug 56726] New: Ability to disable wine builtin title bar and borders
by WineHQ Bugzilla July 4, 2026

July 4, 2026

https://bugs.winehq.org/show_bug.cgi?id=56726 Bug ID: 56726 Summary: Ability to disable wine builtin title bar and borders Product: Wine Version: 9.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: winewayland Assignee: wine-bugs(a)winehq.org Reporter: Deresiant(a)protonmail.ch Distribution: --- Currently when running applications through wine on the wayland driver, those windows have a titlebar and border (I think these called window decorations?) which are provided by wine and can be configured in winecfg. There isn't a method to disable these window decorations completely. -- 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 59957] New: Touch online game launcher redirects to incorrect URL upon logging in
by WineHQ Bugzilla July 3, 2026

July 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=59957 Bug ID: 59957 Summary: Touch online game launcher redirects to incorrect URL upon logging in Product: Wine Version: 11.12 Hardware: x86-64 URL: https://d3dpfszsi3fome.cloudfront.net/patch/weiduan_4g ames/SetupTouch_4gamesExpress_en.exe OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: mshtml Assignee: wine-bugs(a)list.winehq.org Reporter: arethusa26(a)gmail.com Distribution: --- Created attachment 81338 --> http://bugs.winehq.org/attachment.cgi?id=81338 Compressed +mshtml,+wininet trace When logging into the Touch online game through its launcher, the embedded web page in the launcher interface that should show a list of servers instead redirects to a 404 page. I suspect the issue is due to the launcher trying to navigate to a URL using a string that includes HTML entities, which is then passed verbatim to HttpOpenRequestW: 0128:trace:mshtml:HTMLLocation_put_href (0C570838)->(L"/common/webgameServerlist?redijsp=serverlistWeiduan36&clientId=36&cdn=10") 0128:trace:mshtml:outer_window_AddRef (08C1B4A0) ref=9 0128:trace:mshtml:navigate_uri L"http://www.4games.com/common/webgameServerlist?redijsp=serverlistWeiduan36&…" ... 0128:trace:wininet:HttpOpenRequestW (00000002, L"GET", L"/common/webgameServerlist?redijsp=serverlistWeiduan36&clientId=36&cdn=10", (null), (null), 0022F414, 00400000, 08c2cfe0) Presumably HTMLLocation_put_href should decode any present HTML entities in the href string rather than allowing them to appear in the actual HTTP request. -- 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