June 2024 - Wine-Bugs - list.winehq.org

[Bug 56441] New: Illegal Instruction
by WineHQ Bugzilla June 26, 2024

June 26, 2024

https://bugs.winehq.org/show_bug.cgi?id=56441 Bug ID: 56441 Summary: Illegal Instruction Product: Wine Version: 0.9.3. Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: erisi(a)comcast.net Distribution: --- Created attachment 76201 --> https://bugs.winehq.org/attachment.cgi?id=76201 Tracefile - was requested by Program Error Details popup Trying to run a program. It does work under Windows arm64. -- 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 56869] New: Bitdefender reports bsdtar and newdev.dll have Gen.Variant.Lazy.506378 malware
by WineHQ Bugzilla June 26, 2024

June 26, 2024

https://bugs.winehq.org/show_bug.cgi?id=56869 Bug ID: 56869 Summary: Bitdefender reports bsdtar and newdev.dll have Gen.Variant.Lazy.506378 malware Product: Wine Version: 9.0 Hardware: aarch64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: pschlesinger(a)cryoport.com Hi all, my IT dept just reported that Bitdefender detected the Gen.Variant.Lazy.506378 malware in bsdtar and newdev.dll in /Users/<username>/Library/Caches/Homebrew/downloads/7d13c77af2d9d850e05e748be7e4c6b01b081a130464408b223bbdca168e6689--wine-stable-9.0_2-osx64.tar.xz --directory /private/tmp/homebrew-unpack20240621-22640-h6te1q Per the Homebrew forums, I'm to report stuff like this to WineHQ directly. Probably a false-positive, but you never know. -- 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 54903] New: PeaZip can't open Z: drive
by WineHQ Bugzilla June 25, 2024

June 25, 2024

https://bugs.winehq.org/show_bug.cgi?id=54903 Bug ID: 54903 Summary: PeaZip can't open Z: drive Product: Wine Version: 5.5 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Created attachment 74409 --> https://bugs.winehq.org/attachment.cgi?id=74409 Terminal output When PeaZip starts, it displays a file explorer. Browsing files on the C drive works fine, but if you double-click Z: or a directory symlinked to a directory on drive Z, the program freezes. Then, if you click in the file explorer again, an error dialog appears that says "Index Out of range". This was a regression in Wine 5.5. `git bisect` says: 6b498d98a86b5179a025afbaaeaa3d60a8bd74ec is the first bad commit commit 6b498d98a86b5179a025afbaaeaa3d60a8bd74ec Author: Zebediah Figura <z.figura12(a)gmail.com> Date: Fri Mar 20 12:15:25 2020 -0500 ntdll: Consider mount points to be reparse points in get_file_info(). Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> Terminal output is attached. The relevant part appears to be: 0024:fixme:file:NtFsControlFile FSCTL_GET_REPARSE_POINT semi-stub $ sha256sum peazip-9.2.0.WINDOWS.exe 67229ced7de6d27871b823ce7f61f69c7c61fd85ea13d844a7b085ce97adfd9b -- 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 56870] New: Final Fantasy XIV via XIV Launcher crashes upon logging in
by WineHQ Bugzilla June 25, 2024

June 25, 2024

https://bugs.winehq.org/show_bug.cgi?id=56870 Bug ID: 56870 Summary: Final Fantasy XIV via XIV Launcher crashes upon logging in Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: light.plan0535(a)fastmail.com Distribution: --- Created attachment 76669 --> https://bugs.winehq.org/attachment.cgi?id=76669 Backtrace of crash generated by XIV Launcher Instance of repeated crash is when zoning into the Sharlayan zone. Wine version selected by the XIV Launcher. Backtrace is 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.

1 5

[Bug 52501] New: TASInput (Mupen64-RR-Lua): TASInput window doesn't close and stops responding
by WineHQ Bugzilla June 25, 2024

June 25, 2024

https://bugs.winehq.org/show_bug.cgi?id=52501 Bug ID: 52501 Summary: TASInput (Mupen64-RR-Lua): TASInput window doesn't close and stops responding Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jackyguo18(a)hotmail.com Distribution: --- source code: https://github.com/mkdasher/mupen64-rr-lua-/tree/master/tasinput_plugin/src. Checkboxes and radio buttons in the TASInput window are not cleared before being redrawn, leading to weird overlapping graphics. See the attached screenshot. Wine version: 7.0 (winehq-stable) Linux distro: Ubuntu 21.10 (impish) Display server: Wayland, GNOME Mutter To reproduce, download the package from https://repack.skazzy3.com, then simply unzip to a folder and run mupen64.exe. From there: - run an N64 ROM - note that the TASInput window (the one with the fancy checkboxes) shows up - File > Close ROM - the TASInput window should close, but doesn't, and freezes up. - Eventually, (at least for me) GNOME prompts me to force-quit Mupen. -- 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 6

[Bug 56688] New: Audio input not working
by WineHQ Bugzilla June 24, 2024

June 24, 2024

https://bugs.winehq.org/show_bug.cgi?id=56688 Bug ID: 56688 Summary: Audio input not working Product: Wine Version: 0.9.8. Hardware: aarch64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: erisi(a)comcast.net Audio input is not working. This message was output: 0118:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel 0xffffffff 0118:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel 0xffffffff 0118:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel 0xffffffff Please let me know what info I can provide. The program I ran was DSDPlus on MacOS. -- 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 56851] New: wineconsole runs at 20fps
by WineHQ Bugzilla June 24, 2024

June 24, 2024

https://bugs.winehq.org/show_bug.cgi?id=56851 Bug ID: 56851 Summary: wineconsole runs at 20fps Product: Wine Version: 9.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ikm(a)zbackup.org Distribution: --- Created attachment 76657 --> https://bugs.winehq.org/attachment.cgi?id=76657 Continuously outputs text so you can see that scrolling is sluggish Simply by running `wineconsole` and pressing some letter on your keyboard so it autorepeats you can already see that the console window is sluggish to refresh. If that's not evident enough, run the attached `test.bat` in `wineconsole`, which will output some lines of text repeatedly. You can notice the way the text scrolls isn't smooth at all. It's at about 20fps. Any application run by wineconsole is sluggish like that. This wasn't the case some years ago, where the updates were instantaneous. I've traced this to commit 8ccf24ccb0a4362c407aea61927e604e60d41f6e ("conhost: Delay window refresh on output update"), which introduces a 50ms delay for the window refresh. There's no rationale as for why this change was made. It does make life miserable though. Please revert this unless there's some actual reason the console should run at 20fps. It used to be nice and speedy, now it's a slog. -- 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 53636] New: System tray not visible, Ubuntu 20.0.2, Wine 7.16 Staging
by WineHQ Bugzilla June 24, 2024

June 24, 2024

https://bugs.winehq.org/show_bug.cgi?id=53636 Bug ID: 53636 Summary: System tray not visible, Ubuntu 20.0.2, Wine 7.16 Staging Product: Wine Version: 7.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jubilantjerry(a)gmail.com Distribution: --- Created attachment 73034 --> https://bugs.winehq.org/attachment.cgi?id=73034 Tooltip from WeChat that should be from the system tray System is running Ubuntu 20.04 LTS. Kernel version is 5.4.0-125-generic. Desktop environment is Unity 7.5.0. Hardware is Dell Inspiron 7577, which has an Intel(R) Core(TM) i5-7300HQ CPU and a Nvidia GTX 1060 Max-Q GPU. When running an application that minimizes to the system tray when closed, the application is effectively gone. There is no small system tray panel on the screen, unlike what I see about the issue online. Maybe the system tray is size 0x0 on the top left corner, since the tooltip pop-ups that should appear on the system tray icon appear on the top left of my screen. The lack of system tray was observed with WeChat, I don't know of other applications that use the system tray and have an automatic tooltip at the moment, though if you point me to an installer I can try it to see if the problem is reproduced. Let me know if other information 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.

1 12

[Bug 56624] New: Steam fails to install and seems to be stuck in an endless loop - Login screen can't be reached
by WineHQ Bugzilla June 23, 2024

June 23, 2024

https://bugs.winehq.org/show_bug.cgi?id=56624 Bug ID: 56624 Summary: Steam fails to install and seems to be stuck in an endless loop - Login screen can't be reached Product: Wine Version: 9.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: maiktapwagner(a)aol.com Distribution: --- Created attachment 76393 --> https://bugs.winehq.org/attachment.cgi?id=76393 Console output 9.7 (non-staging) Dear wine-team, I am running a Slackware 15.0 box with bash-5.1$ wine --version wine-9.7 Here are the steps I went through: bash-5.1$ mkdir WineApps/Steam bash-5.1$ export WINEPREFIX=/home/mwagner/WineApps/Steam/ bash-5.1$ winetricks steam 2&>/home/mwagner/Desktop/SteamConsoleOutput.txt I originally thought that this has been an issue with winetricks but they confirmed the issue and said is wasn't related to their script. https://github.com/Winetricks/winetricks/issues/2216 -- 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 26

[Bug 56208] New: Inconsistent mouse speed tied to frame rate and mouse polling rate
by WineHQ Bugzilla June 23, 2024

June 23, 2024

https://bugs.winehq.org/show_bug.cgi?id=56208 Bug ID: 56208 Summary: Inconsistent mouse speed tied to frame rate and mouse polling rate 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: korbel00(a)gmail.com Distribution: --- Created attachment 75922 --> https://bugs.winehq.org/attachment.cgi?id=75922 logs and patch In Secret World Legends the actual mouse speed depends on the current frame rate in Wine which does not seem to happen in Windows. (if it does, it's not noticeable for me) Looking around with the camera, the mouse speeds up and slows down randomly, making the game really hard to control if possible at all. It's even worse when a fight is going on in one direction, and there nothing in the other, making it impossible to turn around. (I have ~30 FPS looking into a fight and ~300 FPS looking away, the mouse movement slows down so much that I cannot do a 180 turn) I attempted to do some investigation and I think I could pinpoint the problem which I'll try to explain here. The game loop does the following to control the camera (this is an assumption based on my calculations and on the logged relay messages): ``` loop { screen_movement := ZERO last_position := GetCursorPos() SetCursorPos(CENTER_OF_SCREEN) // reset cursor while msg = PeekMessage() { if (msg.type == WM_MOUSEMOVE) { screen_movement += msg->position - last_position last_position = msg->position } translate and dispatch msg } convert `screen_movement` to camera movement and do some stuff } ``` My tests and calculations confirms it: - At 50FPS, it takes 2906px raw movement to do a 360 turn at 1000Hz polling rate - At 100FPS, it takes 4129px raw movement to do a 360 turn at 1000Hz polling rate In both cases, logging out the PeekMessage values and running the algorithm above on the logs gave me approx 2080px on-screen movement which the game translated into a 360 turn. Interestingly at low polling rates the pattern reverses: high FPS gives faster movement speed than low FPS. For the algorithm to work, there are some assumption made: - every mouse motion must enter the message queue - there cannot be a new motion between calling GetCursorPos and SetCursorPos, and the next motion after SetCursorPos should be the center of the screen. With wine, neither of the conditions stands: - GetCursorPos by default gives back the position from the wine server, even though the display driver may have unsent motion messages in the output buffer. - SetCursorPos will tell X11DRV_MotionNotify to ignore all these unprocessed motions using the "warp_serial" value. The ignored messages won't translate to camera movements and will get lost. I modified the code so only the raw inputs get processed, effectively ignoring all X11DRV_MotionNotify events, and commenting out all code that attempts to sync the graphics driver position. This does not cause problems in this case because for every frame SetCursorPos sends the center of the screen both directly to the message queue and the graphics driver. It solved the issue and the mouse movements became very smooth and uniform however it is not a proper solution. I will attach logs of me doing a 360 turn on both 50FPS and 100FPS. To sum the raw values I used this script: ``` cat messages.log | grep map_raw_event_coords | sed -E 's/.*input (-?[[:digit:]]+).*/\1/' | awk '{ sum += $1}; END { print sum }' ``` To run the algorithm which I think the game is doing (sum the PeekMessage deltas) to calculate the total motion I used this: ``` cat messages.log | awk 'BEGIN { last = 960; sum = 0 }; { if (match($0, "peek_message WM_MOUSEMOVE: \\(([[:digit:]]+) ", m)) { sum += m[1] - last; last = m[1] } else if (match($0, "X11DRV_SetCursorPos warped to ([[:digit:]]+)", m)) { last = m[1] } }; END { print sum }' ``` I will also attach the stripped down version of the relay log of the game loop and my attempt at patching wine 9.0 git version. -- 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