wine-bugs

wine-bugs@winehq.org

1 participants
159127 discussions

[Bug 56640] New: Genshin Impact: The game-launcher cannot be started anymore
by WineHQ Bugzilla 14 Jun '24

14 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56640 Bug ID: 56640 Summary: Genshin Impact: The game-launcher cannot be started anymore Product: Wine Version: 9.4 Hardware: x86-64 URL: https://genshin.hoyoverse.com/ OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: 9427421240(a)posteo.net Distribution: Debian Created attachment 76415 --> https://bugs.winehq.org/attachment.cgi?id=76415 Log - after trying to start the game-launcher. Since Wine 9.4, the game-launcher for Genshin Impact cannot be started normally anymore. When trying to start it, nothing seems to happen. After installing the game-launcher, the installer offers a button for starting the game-launcher. The game-launcher does start successfully when using that button. -- 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 56451] New: catch block fetches bogus frame when using alignas with 32 or higher
by WineHQ Bugzilla 14 Jun '24

14 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56451 Bug ID: 56451 Summary: catch block fetches bogus frame when using alignas with 32 or higher Product: Wine Version: 9.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: dlehman25(a)gmail.com Distribution: --- Created attachment 76211 --> https://bugs.winehq.org/attachment.cgi?id=76211 simple c++ repro case catch block will fetch bogus frame when using alignas() with 32 or higher will submit pr: https://gitlab.winehq.org/dlehman25/wine/-/tree/alignas -- 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 56591] New: Since commit a00efa12, Steam (Win) doesn't render individual game pages correctly.
by WineHQ Bugzilla 14 Jun '24

14 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56591 Bug ID: 56591 Summary: Since commit a00efa12, Steam (Win) doesn't render individual game pages correctly. Product: Wine Version: 9.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: logos128(a)gmail.com Regression SHA1: a00efa12e27035a4a1afb961daefa69766e86b17 Distribution: ArchLinux Created attachment 76346 --> https://bugs.winehq.org/attachment.cgi?id=76346 wine-steam-d3d.log (WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+d3d) Seems the issues are mainly with blocks of information that don't include pictures, just text - like game hotfix info, etc. I'm using the vulkan backend renderer for wined3d. -- 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 15

[Bug 52585] New: NtQueryDirectoryObject multiple entries not implemented, breaks shells on Cygwin
by WineHQ Bugzilla 14 Jun '24

14 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=52585 Bug ID: 52585 Summary: NtQueryDirectoryObject multiple entries not implemented, breaks shells on Cygwin Product: Wine Version: 7.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: megastallman(a)gmail.com Distribution: --- When I try running any command(not builtin) in Cygwin bash or sh, I get no output and no results in Wineconsole. Though, among usual harmless LDAP-related errors, Wineconsole outputs the following to terminal: 0180:fixme:sync:NtQueryDirectoryObject multiple entries not implemented 0180:fixme:sync:NtQueryDirectoryObject multiple entries not implemented 0180:fixme:sync:NtQueryDirectoryObject multiple entries not implemented even after Enter is pressed. Builtin commands work fine, but no external command works at all. Reproducing steps: - cd /cygwin/path/bin - Run "wineconsole" from terminal. There you'll see NtQueryDirectoryObject error. - Run "uname" in Wineconsole. Despite FAST_CWD error, it works. - Run "sh" in Wineconsole. - Run "ls", or just press Enter, or run any other non-builtin command and see those 3 NtQueryDirectoryObject errors. Command itself will not just output anything, it won't work at all, just silently release the terminal. -- 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 20

[Bug 56764] New: Empire Earth Gold doesn't start in virtual desktop mode
by WineHQ Bugzilla 14 Jun '24

14 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56764 Bug ID: 56764 Summary: Empire Earth Gold doesn't start in virtual desktop mode Product: Wine Version: 9.6 Hardware: x86-64 URL: https://www.gamepressure.com/download.asp?ID=954 OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: 4573910acc2783a3f678a428aa313377b09a04e8 Distribution: ArchLinux When I start the game in virtual desktop mode, all I get is an empty and unresponsive virtual desktop screen. The game executable is lingering in the process list with 0% CPU usage. I have to kill the Empire Earth.exe process manually. The game starts properly in Wine's full screen mode. Bisecting revealed that the problem occurred since commit 4573910acc2783a3f678a428aa313377b09a04e8 win32u: Move D3DKMT vulkan implementation out of winex11. The demo version can be used to reproduce the problem. I'm using X.Org X Server 1.21.1.13 with Nvidia binary drivers 550.40.63. Still present in Wine-9.10. -- 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 56665] New: ELF binaries are being built but its supposed to be PE build
by WineHQ Bugzilla 14 Jun '24

14 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56665 Bug ID: 56665 Summary: ELF binaries are being built but its supposed to be PE build Product: Wine Version: 9.0 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: Alexander88207(a)Protonmail.com Hello, as of wine 9, ELF binaries (dll.so) are being built but normally these should be PE binaries (.a). This is how we build wine: https://codeberg.org/FreeBSD/freebsd-ports/src/branch/main/emulators/wine I will try to find to the commit that is causing this. -- 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 14

[Bug 56756] New: Support the asahi gpu driver
by WineHQ Bugzilla 14 Jun '24

14 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56756 Bug ID: 56756 Summary: Support the asahi gpu driver Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: m1m1k4tz(a)protonmail.com Distribution: --- When using krun + boxwine it complains that no card selector is available for the vendor and polygonoffset scale factor detection failed -- 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 18

[Bug 56643] New: Ntdll support for custom baud rates
by WineHQ Bugzilla 13 Jun '24

13 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56643 Bug ID: 56643 Summary: Ntdll support for custom baud rates Product: Wine Version: unspecified Hardware: Other OS: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: testator(a)protonmail.ch Implementing custom baud rates across different OS's would be non-trivial but a useful prerequisite for some obscure apps like qemu or the "mode" command. Termios2 is a linux specific implementation of custom baud rates. In wine-9.8 there was a commit, 898ab8dab19d498c17859f39a55e317ee7e367a5 , that added termios2 usage via glibc headers which breaks compilation on musl based systems, doesn't work in osx, and doesn't work in *bsd. In https://opensource.apple.com/source/IOSerialFamily/IOSerialFamily-55/IOSeri… there is a way to set custom baud rates for osx via IOSSIOSPEED e.g <IOKit/serial/ioss.h> . Setting the rate on linux via <linux/termios.h> instead of the glibc specific extensions of <termios.h> would work as well with how its currently implemented in wine-9.8. It looks like net/openbsd use termios1 modified to their own thing to allow setting arbitrary speeds via tcsetattr https://github.com/openbsd/src/blob/master/lib/libc/termios/tcsetattr.c e.g <termios.h> . In general there doesn't seem to be a common unix implementation for setting custom baud rates and looks like a huge complicated mess to implement. The musl devs found this out already it seems openwall.com/lists/musl/2024/04/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.

1 2

[Bug 50591] New: ReadFile schedules async read when ReadIntervalTimeout is MAXDWORD
by WineHQ Bugzilla 13 Jun '24

13 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=50591 Bug ID: 50591 Summary: ReadFile schedules async read when ReadIntervalTimeout is MAXDWORD Product: Wine Version: 6.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: aaron.knister(a)gmail.com Distribution: --- Created attachment 69269 --> https://bugs.winehq.org/attachment.cgi?id=69269 ntdll: NtReadFile async reads always return success when avail_mode TRUE TeraTerm is ending up with missing data when it reads from a COM/Serial port. TeraTerm sets ReadIntervalTimeout to MAXDWORD and then calls ReadFile asynchronously, and if there's pending IO it waits 1 second for the overlapped struct event to be signalled. If the signal is received, it processes the received I/O, else continues on and will perform another ReadFile. This is the code snippet: if (!ReadFile(cv->ComID,&(cv->InBuff[cv->InBuffCount]), InBuffSize-cv->InBuffCount,&C,&rol)) { if (GetLastError() == ERROR_IO_PENDING) { if (WaitForSingleObject(rol.hEvent, 1000) != WAIT_OBJECT_0) { C = 0; } else { GetOverlappedResult(cv->ComID,&rol,&C,FALSE); } } What's happening in WINE, is ReadFile returns non-zero with ERROR_IO_PENDING and the WaitForSingleObject times out. The asynchronous read *does* complete after the timeout, but by that point the application has given up and moved on. I initially thought the application was at fault, because it should retry if the wait times out. However, in the documentation for ReadFile it points to documentation about COMMTIMEOUTS (https://docs.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-commt…) which says the following: A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received. To me, that means Wine ought not to be triggering an asynchronous read when the comm timeout parameters are set as indicated above. I coded a simple fix, which is in NtReadFile, if avail_mode is TRUE return success even if no bytes were read. See attached patch. It works for TeraTerm, I have no idea if it causes other regressions. -- 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 4

[Bug 56821] New: Keyboard modifiers behavior is unreliable
by WineHQ Bugzilla 13 Jun '24

13 Jun '24

https://bugs.winehq.org/show_bug.cgi?id=56821 Bug ID: 56821 Summary: Keyboard modifiers behavior is unreliable Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: rikul(a)inbox.ru Distribution: --- Sometimes, modifiers are unreliable in combination with letters. The issue stems from Wine commit made 15 years ago: https://gitlab.winehq.org/wine/wine/-/commit/a4a5a2ec121eeb2a7cd4ffbb5ba7b2… Wine attempts to sync with the Linux SCIM keyboard state, leading to scenarios where processing modifiers KeyUp events cause the state of ignoring them. Attached example shows extra WM_KEYUP message of “Shift” in combination with “e”. Wine result: KeyDown: 16 KeyUp: 16 KeyDown: 69 KeyUp: 69 KeyUp: 16 Expected result: KeyDown: 16 KeyDown: 69 KeyUp: 69 KeyUp: 16 -- 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

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