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

[Bug 58698] Application goes into an infinite loop under new wow64 but works okay under old wow64

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58698 --- Comment #3 from Daniel Kamil Kozar <dkk089(a)gmail.com> --- Created attachment 79381 --> http://bugs.winehq.org/attachment.cgi?id=79381 Disassembly of the function calling VirtualAlloc -- 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.

Oct. 2, 2025

[Bug 58698] Application goes into an infinite loop under new wow64 but works okay under old wow64

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58698 --- Comment #2 from Daniel Kamil Kozar <dkk089(a)gmail.com> --- After some more peeking and poking, I was able to pinpoint the exact point where the infinite loop happens. Attached is a disassembly with some comments inline. I understand that code like this isn't very common as otherwise this would've already been reported. Additionally, making the code jump out of the loop on VirtualAlloc's first success (so, basically replacing "je .fail" with "jne .epilogue" and NOPing things out to make sense) makes everything work properly, which shows that this code doesn't seem to have a real purpose and the rest of the application doesn't seem to care or is able to adapt to an allocation being smaller than "all available memory". 64-bit Windows behaviour when running 32-bit applications seems to follow "old WoW64" behaviour though : a short test shows that calling VirtualAlloc(0, 0x7fffffff,0x2000,4) does indeed return zero, which makes this code work even though it's flawed. Perhaps it's worth considering adding a registry flag or an environment variable for a "maximum VirtualAlloc allocation size" in new WoW64 to combat cases like these. -- 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.

Oct. 2, 2025

[Bug 58590] PDF-XChange Editor: crashes when press ctrl+f

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58590 sherry.phasuta(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEEDINFO |RESOLVED --- Comment #5 from sherry.phasuta(a)gmail.com --- Hi! I have solved this issue by installing Windows core fonts in Winetricks. -- 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.

Oct. 2, 2025

[Bug 35648] Anthem Room Correction 2 v1.0.1: crash when connecting to A/V receiver in auto mode

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=35648 --- Comment #7 from Esme Povirk <madewokherd(a)gmail.com> --- I don't have the hardware to test this, but the crashing method uses 'thiscall' calling convention, which wasn't supported at the time but now is. So this would be worth a retest if anyone is still around who can do that. -- 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.

Oct. 2, 2025

[Bug 58734] How to disable usage of wayland and use x11 (xwayland) instead

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58734 mata <sutupud(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sutupud(a)yahoo.com --- Comment #4 from mata <sutupud(a)yahoo.com> --- But with the x11 driver still being the default if not forced, the only way the wayland driver could be used in this scenario was when running a wayland session without XWayland installed. So first step would be to ensure that XWayland is installed and running. Then the x11 driver should be used automatically again. -- 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.

Oct. 2, 2025

[Bug 58745] PeekNamedPipe() unsuccessful on stdin

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58745 --- Comment #4 from Robin Haberkorn <rhaberkorn(a)fmsbw.de> --- (In reply to Eric Pouech from comment #3) > to do a proper implementation, you'd need to somehow buffer the unix pipe > stream (for eg peeknamedpipe to work) and that cannot be done on reader side > (as several processes can peek from the same Unix pipe) > this cannot be done on writer side as its a Unix process But couldn't you just return TRUE when peeking 0 elements on the pipe? Even if you do not allow peeking more than 0 elements, this would already improve compatibility. > From your latest post: why would you need temporary files? reading from the > wrapped unix pipe with ReadFile would work just fine (I mean reading from > temp files or reading from the wrapped unix pipe should behave the same). Because I have code using glib and as long as we don't have a workaround in glib itself, I cannot read from stdin using glib APIs (GIOChannel). They do a zero-peek on the pipe to determine whether it is readable. [1] As long as this is a given, AFAIK I could only work around the issue on my side - where I have full control - with temporary files. Let's suppose Wine is not changed and I would like to work around this issue in glib, what would you suppose to do in order to determine whether the pipe is readable? Is using PeekNamedPipe() instead of ReadFile() for FIFOs necessary at all? I suppose they had some reason to write it like this in the first place. [1] https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/giowin32.c#L1780 -- 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.

Oct. 2, 2025

[Bug 23326] Cannot change printer settings, Family Tree Maker (Broderbund versions)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=23326 --- Comment #12 from James E. LaBarre <j.e.labarre(a)gmail.com> --- I located another version of Family Tree Maker (v11, https://archive.org/details/ftm-11.7z) set the MSWindows version as Windows XP (32 bit), and the same printer setup error occurs. So at this point, the versions confirmed to have this bug are 7, 8, 11, and 2005. -- 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.

Oct. 2, 2025

[Bug 58745] PeekNamedPipe() unsuccessful on stdin

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58745 --- Comment #3 from Eric Pouech <eric.pouech(a)gmail.com> --- that's very unlikely that's going to be fixed in Wine to do a proper implementation, you'd need to somehow buffer the unix pipe stream (for eg peeknamedpipe to work) and that cannot be done on reader side (as several processes can peek from the same Unix pipe) this cannot be done on writer side as its a Unix process doing that in the Wine server would be rather complex (signal state of the pipe should be set according to the buffer state...) That goes IMO beyond the goals of Wine (which is the emulate Windows); what's expected here is a full integration between Unix objects and Windows objects >From your latest post: why would you need temporary files? reading from the wrapped unix pipe with ReadFile would work just fine (I mean reading from temp files or reading from the wrapped unix pipe should behave the same). (it doesn't work if the app has only -from stdin- or -from-named-file' command line options though) I also assumed that LHS from pipe is a unix executable whereas RHS is a windows executable (if both were win32 executables this could be executed with cmd.exe) -- 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.

Oct. 2, 2025

[Bug 58733] widl gives a segmentation fault.

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58733 --- Comment #2 from Louis Lenders <xerox.xerox2000x(a)gmail.com> --- (In reply to Nikolay Sivov from comment #1) > Did this come up when you tried to add a typelib for it? Yes, for bug https://bugs.winehq.org/show_bug.cgi?id=47135 -- 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.

Oct. 2, 2025

[Bug 58696] Profi cash 12 (32-Bit German Banking Software) may hang in critical section wait on startup

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58696 --- Comment #6 from Esme Povirk <madewokherd(a)gmail.com> --- It's really hard to get good info on deadlocks. I may need to write some tools. -- 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.

Oct. 2, 2025