wine-bugs

wine-bugs@winehq.org

1 participants
159122 discussions

[Bug 41549] New: Hover! in fullscreen mode does not cover the top bar in Gnome.
by wine-bugs＠winehq.org 13 Sep '25

13 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=41549 Bug ID: 41549 Summary: Hover! in fullscreen mode does not cover the top bar in Gnome. Product: Wine Version: 1.9.20 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: aaronbpaden(a)gmail.com Distribution: --- I'm using wine-staging 1.9.20. When you set Hover! to fullscreen, it sets the display resolution and fills up most of the screen as it should, but it's set under top bar in GNOME, resulting in several rows of pixels from the bottom of the application also being outside of the display. I confirmed that Hover! does cover the task bar in a Windows VM. There's nothing really in the logs, except for a weird "fixme:process:LoadModule Strange error set by CreateProcess: 193", but that shows up before setting fullscreen. -- 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 58480] New: winebuild ASLR breaks older DLLs
by WineHQ Bugzilla 13 Sep '25

13 Sep '25

http://bugs.winehq.org/show_bug.cgi?id=58480 Bug ID: 58480 Summary: winebuild ASLR breaks older DLLs Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tres.finocchiaro(a)gmail.com Distribution: --- The following commit (to the best of my understanding) introduces build flags to the PE sections of a wineg++ produced '.so.exe' file that force ASLR/DYNAMICBASE onto executables that it creates. https://github.com/wine-mirror/wine/commit/518e394794160818ffe6826c874ff2f5… As identified downstream with mingw and msvc, some scenarios exist where this ASLR/DYNAMICBASE must be disabled for the highest compatibility with 3rd-party DLLs, specifically 3rd-party VST instrument and effect plugins as they're loaded through DAWs using a Linux-wine-bridge. (Linux can be read ambiguously here, the issue would impact Unixes too) The downstream bug report encompases Windows and Wine instances of the LMMS application, however a solution exists on Windows for both the MSVC compiler as well as the mingw compiler (via relevant dynamicbase flags). MSVC: https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase mingw: https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default Applying a similar flag to wineg++/winegcc/winebuild has proven difficult without forking the winebuild executable. The stop-gap patch that LMMS has developed is provided here as a reference https://github.com/Fastigium/winebuild/commit/7f9e27e44cfb8eba79f3850f46e12… however this patch requires us to add winebuild as a build-time dependency to our build system. This is OK for a stop-gap, but as a long-term solution, I would like advice from the winehq team on how to support legacy DLLs (such as pre-Vist VST plugins) through a wine-bridge as a long-term 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 13

[Bug 58335] New: Works 10.8 but fails 10.9?
by WineHQ Bugzilla 12 Sep '25

12 Sep '25

http://bugs.winehq.org/show_bug.cgi?id=58335 Bug ID: 58335 Summary: Works 10.8 but fails 10.9? Product: Wine Version: 10.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mikes(a)kuentos.guam.net Distribution: --- Created attachment 78708 --> http://bugs.winehq.org/attachment.cgi?id=78708 run wine notepad with 10.8 Fine Update to 10.9 then it fails Have 5 machines that updated to 10.9 fine, but Acer notebook that works with 10.8 but fails with 10.9. Run wine notebook fine with 10.8 upgrade to 10.9 wine notebook then fails. downgrade to 10.8, and it works fine. -- 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 148

[Bug 51345] New: Regression: Visual Studio 2005 "package load failure"
by WineHQ Bugzilla 12 Sep '25

12 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=51345 Bug ID: 51345 Summary: Regression: Visual Studio 2005 "package load failure" Product: Wine Version: 6.11 Hardware: x86-64 OS: FreeBSD Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: damjan.jov(a)gmail.com winetricks vc2005trial wine cmd "C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat" devenv Some time during 28-31 March 2021, the Visual Studio 2005 trial began giving +/- 10 of these error dialogs on startup, each relating to a different package. This is a rough transcript of one of them: ------------------------ Package Load Failure ------------------------ Package 'Microsoft.VisualStudio.TestTools.TestCaseManagement.QualtyToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03F5F7f11d50s3a' has failed to load properly { GUID = {AS4DSAES-9ACE-4FOE-ADGF-7AFESSFEFCET) ). Please contact package vendor for assistance. Application restart is recommended, due to possible environment corruption. Would you like to disable loading this package in the future? You may use 'devenv /resetskippkgs' to re-enable package loading. Yes No ------------------------ It is the worst git bisect I've ever done. Apart from the lengthy time needed to test each commit, the regression occurs within a range of 44 commits (bb065801a69..2a8a4cbbe63), the first 43 of which all die on startup, so we can't easily distinguish that bug from this one. I've now had to make a separate branch, "git rebase --onto <that range>" to copy commits from that range there, then "git rebase -i" to reorder them and separate the startup-breaking commits (ntdll/kernel32/kernelbase) from the other commits. Unfortunately, having done so, it appears the startup-breaking commits are also the commits that caused this regression. One or more of these is the culprit: ntdll: Move kernel32 loading into LdrInitializeThunk(). ntdll: Return system dir path for PE mapping bootstrap placeholders. ntdll: Fail to load non-existent dlls, except during prefix bootstrap. ntdll: Also check syswow64 to determine if the prefix was initialized. include: Add more SYSTEM_INFORMATION_CLASS definitions. kernel32: Implement GetSystemCpuSetInformation(). ntdll: Implement NtQuerySystemInformationEx(SystemCpuSetInformation). kernelbase: Don't fall back to dll loading for LOAD_LIBRARY_AS_DATAFILE. ntdll: Set the window title to the image name on the Unix side. ntdll: Remove load_builtin_dll() and get_load_order() from the Unix interface. ntdll: Map the builtin or fake dll from the Wine dirs if it's missing from the 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.

1 30

[Bug 58635] New: CapCut crashes upon launch
by WineHQ Bugzilla 12 Sep '25

12 Sep '25

http://bugs.winehq.org/show_bug.cgi?id=58635 Bug ID: 58635 Summary: CapCut crashes upon launch Product: Wine Version: 10.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ihatemylife0025(a)gmail.com Distribution: --- Created attachment 79192 --> http://bugs.winehq.org/attachment.cgi?id=79192 Logs from running CapCut on a new wineprefix I've tried every workaround I could find but CapCut (version 6.9.0, from here: https://lf16-capcut.faceulv.com/obj/capcutpc-packages-us/packages/CapCut_6_…) crashes ~10 seconds from launch. Things I've tried: Installing on a Windows PC and copying the files. No difference. Enabling DXVK. No difference. Using the experimental xe driver for my GPU. No difference. Creating a new prefix. No difference Using the stable 10.0 version. No difference Using CapCut beta version 7.0.0. No difference Installing corefonts with winetricks. No difference I'm using wine version 10.13 from the official fedora 42 repository GPU: 0000:00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) Subsystem: Lenovo Device 3f9c Kernel driver in use: i915 Kernel modules: i915, xe CPU: 11th Gen Intel(R) Core(TM) i5-1135G7 (8) @ 4.20 GHz RAM: 20GB (16+4) DDR4 3200mhz Laptop Model: 82H8 (IdeaPad 3 15ITL6) Kernel Version: Linux 6.15.10-200.fc42.x86_64 Distribution: Fedora 42 KDE Plasma Edition -- 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 56278] New: wayland: dropdowns is rendered as toplevel
by WineHQ Bugzilla 12 Sep '25

12 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=56278 Bug ID: 56278 Summary: wayland: dropdowns is rendered as toplevel Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hugo(a)whynothugo.nl Distribution: --- When using the wayland driver, dropdown menus are rendered as their own toplevel windows. On tiling window managers (e.g.: swaywm), this results in it being tiled just like any other window. I can't imagine that they would be placed correctly on stacking window managers either. I confirmed with lswt that dropdowns are effectively rendered as toplevels. An xdg_popup should be used here instead: https://wayland.app/protocols/xdg-shell#xdg_popup The weirdness in behaviour can be reproduced with: - wine reg.exe add HKCU\\Software\\Wine\\Drivers /v Graphics /d wayland - winecfg - Go to the desktop integration tab and click on any dropdown -- 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 58503] New: Mouse cursor vanishes when using winewayland
by WineHQ Bugzilla 12 Sep '25

12 Sep '25

http://bugs.winehq.org/show_bug.cgi?id=58503 Bug ID: 58503 Summary: Mouse cursor vanishes when using winewayland Product: Wine Version: 10.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)winehq.org Reporter: sutupud(a)yahoo.com Distribution: --- Since the cursor changes on winewayland in wine 10.12, I see a regression when playing Saints Row 3 Remastered (GOG). After some time in game, the mouse cursor no longer appears when switching to the menu. When that happens, the log is filled with: 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash [... repeated ~100 times ...] 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:waylanddrv:wayland_pointer_update_cursor_buffer Failed to get icon info for cursor=0xa70076 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:waylanddrv:wayland_pointer_update_cursor_buffer Failed to get icon info for cursor=0xa70076 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:waylanddrv:wayland_pointer_update_cursor_buffer Failed to get icon info for cursor=0xa70076 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash [... keeps repeating ...] The game normally switches between hidden and visible mouse cursor when accessing the menu or in-game phone screen. Except from that the game keeps running, just without visible mouse cursor. It doesn't trigger immediately, which makes testing not so easy. Most of the time it runs fine for something between half an hour and an hour. For that reason I can't say if other applcations are affected too, since I didn't test anything else long enough. It did not happen in wine 10.11, and I could not reproduce it after reverting https://gitlab.winehq.org/wine/wine/-/commit/6a9df1f4c5a8448f426ba3454faf25… -- 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 11

[Bug 57444] New: A old game Exertus darkness approaches unable to run under wine wow64
by WineHQ Bugzilla 12 Sep '25

12 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=57444 Bug ID: 57444 Summary: A old game Exertus darkness approaches unable to run under wine wow64 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: l12436.tw(a)gmail.com Distribution: --- Created attachment 77440 --> https://bugs.winehq.org/attachment.cgi?id=77440 Log from wine wow64 Exertus darkness approaches is a very old game. It was able to play even with virtualbox, but unable to run under wow64 env Ubuntu 20.04 wine lastest master -- 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 32

[Bug 58513] New: Wine 10.9 completely broke (LGA775 Core2Quad)
by WineHQ Bugzilla 12 Sep '25

12 Sep '25

http://bugs.winehq.org/show_bug.cgi?id=58513 Bug ID: 58513 Summary: Wine 10.9 completely broke (LGA775 Core2Quad) Product: Wine Version: 10.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xeroxslayer(a)proton.me Distribution: --- I have no other way to describe it except this. Everything was working fine up until Wine 10.8, then I upgrade to Wine 10.9 on Void Linux, and it doesn't work at all any more. There are more details in this issue on GitHub. There is just way too much info to paste here. https://github.com/void-linux/void-packages/issues/55697 Basically, it just doesn't work at all. You run `winecfg` or any other software and this is what you get. ``` 002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6fffffc4c133 0034:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6fffffc4c133 003c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6fffffc4c133 ``` Nothing works. This happens, and then Wine quietly exits. From what little I understoo, basically, it can't locate binaries. The binaries are there, at that location, it just doesn't see them... or can't load them, IDK. You can find more relevant info in this comment, with some debug flags enabled. https://github.com/void-linux/void-packages/issues/55697#issuecomment-29902… I do have to note that Wine past 10.8 (>=10.9) does work on other rigs I have, newer ones, but this particular rig is an LGA775 Core2Quad. Now, I know that Wine is mostly focused towards gaming and gamers, but there are people out there that use it for simple things as well, like Winamp and similar things, and we really don't need brand new hardware to do that. In fact, this is my workshop rig and I basically just need it to browse some things on the web (still performs OKish regarding that) and maybe open a few documents, an IC programmer from time to time, but that's about it. So, this rig still suits my needs just fine. I tried scrubbing the volume, check for errors, nothing, everything is peachy, no corruption problems whatsoever. On Void's side, there are literally no changes in the template, except bumping up versions, hashes and removing `libOSMesa` as a dependency (which is depreciated, found that out later on), but I even tried adding `libOSMesa` as a dependency and building it like that, no changes whatsoever, it's still completely broken. There are way too many commits between 10.8 and 10.9, and in all honesty, I wouldn't even know where to start looking (I presume something to do with CPU, but, I'm just guessing here), so if someone could shed some light, I would gladly test. -- 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 25

[Bug 58027] New: trivial use of Win32 GNU make failes with Wine 10.x but not with Wine 9.0
by WineHQ Bugzilla 12 Sep '25

12 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=58027 Bug ID: 58027 Summary: trivial use of Win32 GNU make failes with Wine 10.x but not with Wine 9.0 Product: Wine Version: 10.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dl.soluz(a)gmx.net Distribution: --- Created attachment 78286 --> https://bugs.winehq.org/attachment.cgi?id=78286 contains the specific make.exe (with MD5, and source-infos)+makefile and scenarios its a super simple makefile that does nothing more then clean: del *.not_existing_at_all and make fails to run the del command on 10.x Wine versions but works on Wine 9.0 i created a git-repo with the make.exe (with MD5) a makefile and a clear description whats happening - in short Wine 10.x breaks someway the del command run the repo: https://github.com/LowLevelMahn/bug_repo0 (i also attached the 3 files of the repo as zip) i don't know if that is a real Wine bug but its strange that is does not happen with a older Wine version (tested only 9.0 so far) tested with up-to-date Ubuntu 24.10 (up-to-date) + sudo apt install wine32 => wine 9.0 up-to-date WSL2/SUSE Tumbleweed + sudo zypper install wine => wine 10.0 up-to-date Fedora 42 (Beta) + sudo dnf install wine32 => wine 10.4 -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs