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

[Bug 59772] wintab32/winex11: user32-rawinput-mouse patch set stops XDeviceMotionEvent-s enabled by x11 wintab

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59772 Katharine <katharine.chui(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- 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.

May 20, 2026

[Bug 59772] wintab32/winex11: user32-rawinput-mouse patch set stops XDeviceMotionEvent-s enabled by x11 wintab

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59772 Katharine <katharine.chui(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum(a)codeweavers.com -- 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.

May 20, 2026

[Bug 59772] New: wintab32/winex11: user32-rawinput-mouse patch set stops XDeviceMotionEvent-s enabled by x11 wintab

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59772 Bug ID: 59772 Summary: wintab32/winex11: user32-rawinput-mouse patch set stops XDeviceMotionEvent-s enabled by x11 wintab Product: Wine-staging Version: 11.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: katharine.chui(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- On wine staging, wintab32 currently randomly stops sending graphics tablet input messages to application, usually after mouse input. A bisection on the patch set shows that the issue first emerged from `0005-winex11-Keep-track-of-mouse-device-and-pointer-butto.patch`. Further inspection with `WINEDEBUG="-all,+event"` points to `XDeviceMotionEvent` events vanishing, despite enabled in `wintab.c` `tablet_attach_queue()` This suggests that the use of `XCloseDevice` in the patch conflicts with x11 wintab's use of `XSelectExtensionEvent`. Documentation of `XCloseDevice` seems to explain this behavior https://manpages.debian.org/buster/libxi-dev/XCloseDevice.3.en.html ``` When a client makes an XCloseDevice request, any active grabs that the client has on the device are released. Any event selections that the client has are deleted, as well as any passive grabs. If the requesting client is the last client accessing the device, the server may disable all access by X to the device. ``` This issue was observed in Xwayland, I do not know if it happens in normal X11 as well. This might be a duplicate of https://bugs.winehq.org/show_bug.cgi?id=49512 , https://bugs.winehq.org/show_bug.cgi?id=33056 -- 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.

May 20, 2026

[Bug 59765] Custom application using sockets performs worse on 11.8 vs 5.0

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59765 --- Comment #4 from mcsordas <csoresz2(a)gmail.com> --- Hi, We added application-side timing around the Winsock calls used by the RTSP client: select(), recv(), and send(). The send() calls are negligible in our case, as expected. recv() is called frequently, and select() is also called frequently. We also measured the full live555 scheduler iteration, around BasicTaskScheduler::SingleStep(). One interesting result is that select() wall-clock time by itself does not show the regression clearly. The select() average time is in the same general range on Windows, Wine 5, and Wine 11.8, probably because the measurement includes normal waiting time. However, recv() shows a much larger difference. Native Windows system, about a 30-second interval: singlestep count=15751 avg=1904.36us over1ms=20.20% over5ms=13.03% over10ms=9.36% singlestep count=15335 avg=1955.60us over1ms=20.88% over5ms=13.45% over10ms=9.63% select count=15439 avg=1928.37us over1ms=20.02% over5ms=13.36% over10ms=9.59% recv count=32620 avg=1.13us over1ms=0.00% over5ms=0.00% over10ms=0.00% select count=16511 avg=1799.67us over1ms=19.10% over5ms=12.42% over10ms=8.90% recv count=35142 avg=1.29us over1ms=0.01% over5ms=0.00% over10ms=0.00% Wine 11.8 system, about a 30-second interval: singlestep count=14931 avg=2009.05us over1ms=55.91% over5ms=8.33% over10ms=5.75% singlestep count=13982 avg=2145.34us over1ms=57.36% over5ms=11.03% over10ms=7.67% select count=12104 avg=1407.79us over1ms=11.20% over5ms=8.88% over10ms=6.54% recv count=27682 avg=459.68us over1ms=0.04% over5ms=0.00% over10ms=0.00% select count=11466 avg=1665.23us over1ms=15.08% over5ms=11.71% over10ms=8.57% recv count=25371 avg=422.41us over1ms=0.03% over5ms=0.00% over10ms=0.00% Wine 5 system, about a 30-second interval: singlestep count=16461 avg=1821.97us over1ms=22.35% over5ms=16.72% over10ms=12.52% singlestep count=17383 avg=1725.04us over1ms=21.17% over5ms=15.73% over10ms=11.78% select count=17881 avg=1619.30us over1ms=20.14% over5ms=15.03% over10ms=11.28% recv count=36613 avg=23.89us over1ms=0.12% over5ms=0.00% over10ms=0.00% select count=16702 avg=1741.18us over1ms=21.58% over5ms=16.38% over10ms=12.27% recv count=33725 avg=21.25us over1ms=0.00% over5ms=0.00% over10ms=0.00% For a single stream, recv() is roughly: Windows: ~1.2 us average Wine 5: ~21-24 us average Wine 11.8: ~420-460 us average So compared to Wine 5, recv() is roughly 18-22x slower on Wine 11.8. Looking at the accumulated recv() time over roughly 30 seconds: Windows: ~0.037-0.045 seconds Wine 5: ~0.72-0.87 seconds Wine 11.8: ~10.7-12.7 seconds So even though almost all recv() calls are still below 1 ms individually, the accumulated cost becomes significant. The full live555 SingleStep() timing also changed. The average SingleStep() time is only moderately higher on Wine 11.8: Windows: ~1.90-1.96 ms Wine 5: ~1.73-1.82 ms Wine 11.8: ~2.01-2.15 ms However, the percentage of SingleStep() calls taking more than 1 ms is much higher on Wine 11.8: Windows: ~20-21% Wine 5: ~21-22% Wine 11.8: ~56-57% The per-call recv() cost is still small in absolute terms, but the call count is high enough that it adds up quickly. Please let us know if there is anything specific we should try or measure next. -- 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.

May 20, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #18 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Aaron Rainbolt from comment #16) > > I'm curious as to what makes you say that the "MIME handler system" promises a form of > > security boundary. Where did you get that notion from? > > The xdg-mime manpage quoted in the original report, which states clearly > "Keeping opening and executing separate actions helps with people protecting > themselves from malware, the default handler is an opener, not a runner." To put this into perspective, this message was added in 2023 while tools/wine.desktop with the application/x-ms-dos-executable MIME type was introduced in 2004. -- 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.

May 20, 2026

[Bug 57123] Wine crashes when input devices are plugged / unplugged

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=57123 weaseal(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |weaseal(a)gmail.com --- Comment #5 from weaseal(a)gmail.com --- This issue exists in wine-staging 11.2, but does not exist in wine 11.8 -- 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.

May 20, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #17 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- (In reply to Aaron Rainbolt from comment #15) > What happens if you try to 'xdg-open' an EXE file? On my end, this always > automatically launches the application, on both Fedora (using WineHQ's RPM > package) and Debian (using WineHQ's DEB package), if I'm remembering > correctly. I've also seen "Wine Windows Program Loader" as an option in the > "Open With..." menus of various file managers when right-clicking an EXE > file, something that should only happen if the MIME system recognizes Wine > as a file handler for EXE files. Hello, I only use locally built Wine, no distributed package, that probably makes a difference. Gnome File Roller is the default handler for application/x-ms-dos-executable on Gnome/Debian. If I disable the File Roller handler, 'xdg-open' prints an error message 'Unable to find the default application for this type of content "application/x-ms-dos-executable"' (rough translation from French), and in nautilus it shows a "no application for this file" dialog. I made a few tests with stub desktop files and XDG selects the default in that order (first found becomes the default): - first desktop file specified in the user's mimeapps.list; - first desktop file specified in the system's mimeapps.list; - first desktop file in the user's database directory, in alphabetical order; - first desktop file in the system database directory, in alphabetical order; If you want to prevent Wine from running EXE files without confirmation, you could set the default handler to something else in your mimeapps.list, a desktop file for a custom wrapper script, for example. (In reply to Aaron Rainbolt from comment #16) > The xdg-mime manpage quoted in the original report, which states clearly > "Keeping opening and executing separate actions helps with people protecting > themselves from malware, the default handler is an opener, not a runner." That's a security policy. There is no concrete mechanism to enforce it in the implementation. Wine cannot prevent XDG to select it as the default handler, since XDG just uses the first desktop file it finds. Having some way to tell XDG that a handler is not an 'opener' but a 'runner', and enforcing the policy by excluding runners from being selected as default, is a valid feature request to direct at Freedesktop. If they offered such a feature, Wine would use it. 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.

May 20, 2026

[Bug 59765] Custom application using sockets performs worse on 11.8 vs 5.0

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59765 --- Comment #3 from mcsordas <csoresz2(a)gmail.com> --- Hello Zeb, Thanks for your reply. We try to make some measures based on your advices. -- 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.

May 20, 2026

[Bug 59732] Custom WinXP/7 app printing garbled from wine 9 onwards

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59732 --- Comment #12 from Rafał Mużyło <galtgendo(a)o2.pl> --- ...actually, there might be one more thing: I'm not sure what's the quality of pdf files produced by wine, but if they're better that 'drop everything in a page as a single bitmap', then two such files printing the same document might offer even more info than the debug logs. -- 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.

May 20, 2026

[Bug 59732] Custom WinXP/7 app printing garbled from wine 9 onwards

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59732 --- Comment #11 from Rafał Mużyło <galtgendo(a)o2.pl> --- So, I'm still parsing the two logs, but two things: 1. As a point of order, these logs should be attached, so that the bug doesn't depend on external links that may expire. 2. I'll probably find it in the logs shortly, but I feel a need to ask: the screenshots are in different resolutions, but PSDRV_ExtTextOut gets same coordinates in both 8.7 and 8.13 logs... Any chance it's about a change in paper size ? -- 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.

May 20, 2026

[Bug 58587] Bioshock 1.0 demo crashes during HLSL shader compilation

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58587 Francisco Casas <fcasas(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fcasas(a)codeweavers.com --- Comment #2 from Francisco Casas <fcasas(a)codeweavers.com> --- Thanks for providing the shaders. This should be fixed by https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/2042. -- 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.

May 20, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #16 from Aaron Rainbolt <arraybolt3(a)gmail.com> --- > I'm curious as to what makes you say that the "MIME handler system" promises a form of > security boundary. Where did you get that notion from? The xdg-mime manpage quoted in the original report, which states clearly "Keeping opening and executing separate actions helps with people protecting themselves from malware, the default handler is an opener, not a runner." -- 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.

May 20, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #15 from Aaron Rainbolt <arraybolt3(a)gmail.com> --- > Wine doesn't register itself as the DEFAULT handler anywhere in the code. All Wine does is to install a few .desktop files in ~/.local/share/applications. > The loader/wine.desktop file is not even there on my system. It's installed in > $INSTALL_DIR/share/applications", nowhere else, and 'xdg-mime query default <mimetype>' > returns nothing for the concerned mimetypes. What happens if you try to 'xdg-open' an EXE file? On my end, this always automatically launches the application, on both Fedora (using WineHQ's RPM package) and Debian (using WineHQ's DEB package), if I'm remembering correctly. I've also seen "Wine Windows Program Loader" as an option in the "Open With..." menus of various file managers when right-clicking an EXE file, something that should only happen if the MIME system recognizes Wine as a file handler for EXE files. -- 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.

May 20, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #14 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, I'm curious as to what makes you say that the "MIME handler system" promises a form of security boundary. Where did you get that notion from? To me, there is no security implied from that system. You can set anything as a MIME handler and there are no security checks of any kind. It's practically just a shortcut to launch an application from the files without opening it first and then loading the files. I might even say that it is a security vulnerability if the handlers are not examined before they become active. 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.

May 20, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |integration --- Comment #13 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, Wine doesn't register itself as the DEFAULT handler anywhere in the code. All Wine does is to install a few .desktop files in ~/.local/share/applications. The loader/wine.desktop file is not even there on my system. It's installed in "$INSTALL_DIR/share/applications", nowhere else, and 'xdg-mime query default <mimetype>' returns nothing for the concerned mimetypes. If it's different on your system, then it may come from the Wine package you installed. It probably copied the wine.desktop file into /usr/share/applications or the ~/.local equivalent. I'm not saying that it's wrong, though. My understanding of the XDG documentation is that setting the default handler is the responsibility of the user/system policy. However, XDG happily sets the default handler to the first handler if there is only one. The Freedesktop/MIME/XDG specifications provide no way for a .desktop file to indicate whether the handler is an opener or runner. Requiring that the default handler is an opener, but automatically setting the first one as the default without asking the user, and without anyway to tell openers from runners, is a broken implementation to me. XDG should either: - Not blindly set the first handler as the default handler; - Provide a mechanism to distinguish between openers and runners (and only use openers as default); If there is a bug somewhere, it's in the XDG implementation. 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #12 from Aaron Rainbolt <arraybolt3(a)gmail.com> --- Hmm, portability is a concern I hadn't thought of. It looks like BSDs in general don't support binfmt-misc or a similar mechanism. -- 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #11 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Aaron Rainbolt from comment #10) > I agree with you that Wine *should* not act as a security boundary. > Unfortunately, that's exactly what it is doing; by registering itself as a > MIME handler, Wine is telling the system "I am capable of acting as a > security boundary. If you hand me an EXE file, I can do something the user > finds useful with it, without compromising the system." That's what the MIME > handler system is for. Of course, Wine isn't capable of keeping that > promise, for the reasons you described, which is why I'm arguing that Wine > should not be promising the system that it will behave in a safe way. Okay, I had a feeling that's where this might eventually lead; this position does make sense to me. I don't know why we ship a .desktop and not a binfmt_misc handler. Portability, maybe? It does feel like an oversight that xdg in itself doesn't provide this distinction and relies on other tools to do so (or, well, considers it out of scope? Still feels like an oversight) > That is the implicit assertion in the manpage, but it isn't the focus of > this report. The focus of this report is *users don't have control of the > files they open.* If a user has Wine installed, any running application in > any Flatpak (and probably many Snaps) can trivially escape the sandbox at > will, without user interaction. I don't think users expect that installing > Wine will break the security model of unrelated applications, even if the > user doesn't do anything with Wine other than install it. Well, I'm not exactly sympathetic to this direct appeal, because I don't think you can argue that Flatpak is doing a reasonable thing here without being able to appeal to xdg-mime and the intent behind xdg-mime. Flatpak tends to do things I find unreasonable, after all... -- 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #10 from Aaron Rainbolt <arraybolt3(a)gmail.com> --- > I don't see how that has anything to do with sandboxing, though? The system > isn't designed with any way to know whether something is trustworthy or not, > so something like LibreOffice can't make that decision based on the presence > of a sandbox; it has to decide to not do anything dangerous for *any* files, > ever. > > Generally, then, an application has to decide whether it is going to act as a > security boundary, or whether it's going to put all the burden of trust on the > user. LibreOffice can act as a security boundary relatively easily (as I > understand). Firefox has a harder time, but chose to do it anyway. Wine has > *always* decided not to, mostly because it has an extremely hard time doing > so. Once you're letting code run natively on the processor, it is very hard to > prevent it from escaping, and attempts to do so very frequently come with a > performance cost, not to mention a development cost. I agree with you that Wine *should* not act as a security boundary. Unfortunately, that's exactly what it is doing; by registering itself as a MIME handler, Wine is telling the system "I am capable of acting as a security boundary. If you hand me an EXE file, I can do something the user finds useful with it, without compromising the system." That's what the MIME handler system is for. Of course, Wine isn't capable of keeping that promise, for the reasons you described, which is why I'm arguing that Wine should not be promising the system that it will behave in a safe way. The reason I mentioned LibreOffice is because it's a good example of why sandboxed apps need to be able to make applications outside of their sandboxes open files. Sandboxing is intended to isolate apps, but apps are not used in isolation, so saying "just use a sandbox that doesn't allow opening files" doesn't work (at least not if you're looking at per-app sandboxing). The system needs to know what apps can safely open specific file types from untrusted sources, and the MIME database is its source of info for that. > Wine's behaviour may contradict XDG guidelines, but there's no way to follow > them while still being useful. There is though. As I mentioned above, the binfmt-misc system exists for the purpose of registering code interpreters / loaders with the kernel. If Wine were registered as a binfmt-misc handler for EXE files, users could then double-click EXEs that had their executable bit set, and they would run, very much like how they do now. At the same time, Wine would not be promising the system that it is a safe handler for EXE files, and so the system would not trust it to open arbitrary things a sandbox hands to it. > As far as I can tell, the implicit assertion behind the guidelines is "users > shouldn't have to vet the files they're opening", which is incompatible with > Wine's security model. That is the implicit assertion in the manpage, but it isn't the focus of this report. The focus of this report is *users don't have control of the files they open.* If a user has Wine installed, any running application in any Flatpak (and probably many Snaps) can trivially escape the sandbox at will, without user interaction. I don't think users expect that installing Wine will break the security model of unrelated applications, even if the user doesn't do anything with Wine other than install it. > It would make more sense to argue that Wine should be a sandbox. I don't > expect that argument to be well-received, though, and you should be prepared > to be able to put up all of the work that would be necessary, since nobody > else is likely to, whether volunteer or sponsored. This isn't really related to the bug report. Wine itself doesn't really need to be sandboxed IMO (and there are projects already out there that sandbox it if you want). > Also, how exactly does Flatpak deal with ELF binaries? They're in essentially > the same category. ELF binaries don't have any MIME handler registered. They aren't generally "opened" in the traditional sense, they're exec'd. PE binaries can be exec'd on Linux too, but only if they are registered with the kernel using binfmt-misc. Because there isn't a MIME handler for ELF binaries, opening them with org.freedesktop.portal.OpenURI.OpenFile doesn't do anything useful to an attacker. -- 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #9 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Aaron Rainbolt from comment #6) > That depends on the kind of code though. If a user downloads a Word document > with a sandboxed Firefox, then clicks the "Open" button in the browser to > open it, the user would naturally expect that a) the file should open, and > b) opening the file won't run arbitrary code within the file. I don't see how that has anything to do with sandboxing, though? The system isn't designed with any way to know whether something is trustworthy or not, so something like LibreOffice can't make that decision based on the presence of a sandbox; it has to decide to not do anything dangerous for *any* files, ever. Generally, then, an application has to decide whether it is going to act as a security boundary, or whether it's going to put all the burden of trust on the user. LibreOffice can act as a security boundary relatively easily (as I understand). Firefox has a harder time, but chose to do it anyway. Wine has *always* decided not to, mostly because it has an extremely hard time doing so. Once you're letting code run natively on the processor, it is very hard to prevent it from escaping, and attempts to do so very frequently come with a performance cost, not to mention a development cost. Wine's behaviour may contradict XDG guidelines, but there's no way to follow them while still being useful. As far as I can tell, the implicit assertion behind the guidelines is "users shouldn't have to vet the files they're opening", which is incompatible with Wine's security model. It would make more sense to argue that Wine should be a sandbox. I don't expect that argument to be well-received, though, and you should be prepared to be able to put up all of the work that would be necessary, since nobody else is likely to, whether volunteer or sponsored. Also, how exactly does Flatpak deal with ELF binaries? They're in essentially the same category. -- 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.

May 19, 2026

[Bug 59760] Missing i386-part on latest 11.9 Ubuntu (noble, jammy) packages

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59760 Ian <superian(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |superian(a)gmail.com -- 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.

May 19, 2026

[Bug 59771] TrackChecker-x64.exe hangs at 100% CPU on startup since Wine 11.7 (msxml3 regression)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59771 --- Comment #7 from fumadordeducados(a)gmail.com --- Created attachment 80980 --> http://bugs.winehq.org/attachment.cgi?id=80980 Test data.xml -- 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.

May 19, 2026

[Bug 59771] TrackChecker-x64.exe hangs at 100% CPU on startup since Wine 11.7 (msxml3 regression)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59771 --- Comment #6 from fumadordeducados(a)gmail.com --- Further findings: The recursion is not infinite. A minimal fake data.xml (6 entries) loads successfully but noticeably slowly. The real data.xml (~24,000 tracking entries, 3.4MB) causes a stack overflow crash — the process runs at ~100% CPU with Wine continuously growing the thread stack (visible in strace as repeated mprotect calls on incrementing addresses), then terminates. Wine 11.6 with libxml2 parsed the same file instantly with no issues. This indicates a severe performance regression in Wine 11.7+'s new MSXML implementation — likely O(n²) or worse complexity when parsing large XML files, compared to Wine 11.6 (which used libxml2 and loaded the same file instantly). A minimal reproducer data.xml with fictional data is attached. To reproduce the stack overflow crash, a large data.xml with thousands of entries is needed. -- 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.

May 19, 2026

[Bug 59771] TrackChecker-x64.exe hangs at 100% CPU on startup since Wine 11.7 (msxml3 regression)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59771 --- Comment #5 from fumadordeducados(a)gmail.com --- Further testing: A fresh installation on a clean win64 WINEPREFIX with no prior tracking data starts correctly after letting it run a bit longer. It seems that the bug is triggered by existing user data. The original setup used a "portable" mode (empty file named portable in the installation directory), which causes TrackChecker to store its data locally rather than in AppData. This includes data.xml (~3.4MB, containing hundreds of accumulated tracking entries) Copying only data.xml (~3.4MB, containing hundreds of accumulated tracking entries) into a fresh portable-mode installation reproduces the bug immediately. The three domdoc_get_parseError semi-stub calls become six (two DOMDocument objects being parsed), then the process enters 100% CPU infinite recursion. Without data.xml (fresh install, no data): starts correctly. With data.xml present: hangs at ~100% CPU, no window. The root cause is likely specific content or structure in data.xml that triggers a code path in Wine 11.7+'s new MSXML reimplementation that was handled correctly in Wine 11.6. -- 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.

May 19, 2026

[Bug 59771] TrackChecker-x64.exe hangs at 100% CPU on startup since Wine 11.7 (msxml3 regression)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59771 --- Comment #4 from fumadordeducados(a)gmail.com --- Regarding the installation method: i'm running it from a manually copied directory because the app was already set up from a previous Windows installation. Will reproduce using the official installer on a clean prefix and update the report. Tested with a fresh installation using the official installer on a clean win64 WINEPREFIX (no prior data, no manually copied files). The bug reproduces identically: Installer run via: wine explorer /desktop=TC,1280x960 TrackChecker-setup.exe (because the license is not scrollable otherwise and the "Accept" button cannot be enabled) Launched via: wine "C:\\Program Files\\TrackChecker\\TrackChecker.exe" Result: process immediately goes to ~100% CPU, no window created, must be killed Last debug output before spin: three consecutive fixme:msxml:domdoc_get_parseError ... semi-stub calls, identical to original report -- 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.

May 19, 2026

[Bug 25974] AutoCAD 2009 LT: acadlt.msi doesn't start installer

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=25974 Janne <janne.kekkonen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|janne.kekkonen(a)gmail.com | -- 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.

May 19, 2026