- Wine-bugs - list.winehq.org

[Bug 58483] New: Burnout Paradise has rendering issues
by WineHQ Bugzilla 12 Dec '25

12 Dec '25

http://bugs.winehq.org/show_bug.cgi?id=58483 Bug ID: 58483 Summary: Burnout Paradise has rendering issues Product: Wine Version: 10.1 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com CC: z.figura12(a)gmail.com Regression SHA1: 96fb128efdbf8d92f6b4d63a7db0346659b08969 Distribution: --- Created attachment 78933 --> http://bugs.winehq.org/attachment.cgi?id=78933 examples Some scenes are black rendered. -- 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 58491] New: Flickering on video-surveilance-app is back
by WineHQ Bugzilla 12 Dec '25

12 Dec '25

http://bugs.winehq.org/show_bug.cgi?id=58491 Bug ID: 58491 Summary: Flickering on video-surveilance-app is back Product: Wine Version: 10.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: andreas.franz(a)arcor.de Distribution: --- Created attachment 78948 --> http://bugs.winehq.org/attachment.cgi?id=78948 started from terminal Flickering on viewing a camera stream with activated hardware accelerated d3d11 setting is back. Desktop picture and camera picture is swapping. It was gone with 10.0 stable - it's back with 10.12 (maybe some versions earlier). Software rendering works still fine. regards, Andy -- 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 25

[Bug 59129] New: Parallel Port Tester fails to detect the parallel port's base I/O address
by WineHQ Bugzilla 12 Dec '25

12 Dec '25

http://bugs.winehq.org/show_bug.cgi?id=59129 Bug ID: 59129 Summary: Parallel Port Tester fails to detect the parallel port's base I/O address Product: Wine Version: 11.0-rc1 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: wmi&wbemprox Assignee: wine-bugs(a)list.winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Steps to reproduce: 1. Use a computer with a motherboard-attached or PCI-attached parallel port. USB-attached parallel ports do not have base I/O addresses and Parallel Port Tester ignores them. 2. Ensure that /dev/lp0 exists and works outside of Wine, for example by connecting the parallel port to a printer or to an LED tester, running `echo hello > /dev/lp0`, and seeing the word printed on the printer or seeing different LEDs light up on the tester. 3. (Optional) Figure out what the base address of the parallel port is by looking at DEVNAME in /sys/class/printer/lp0/device/ppdev/parport0/uevent, then reading the first number in /proc/sys/dev/parport/<DEVNAME>/base-addr. You will need to convert the value to hexadecimal and prepend "0x" if you want to manually enter it into Parallel Port Tester. 4. Run `wine ParallelPortTesterSetup-1.0.0.2.exe` 5. Run `wine 'C:\Program Files (x86)\Parallel Port Tester\ParallelPortTester.exe'` 6. Click the drop-down labeled "Port" in the lower-right corner of the window. When my desktop computer is booted into Windows and I click the drop-down in Parallel Port Tester, it offers "LPT3 (0xEFF8)" as an option. When the same computer is booted into Linux and I run Parallel Port Tester on Wine, the drop-down is empty. However, if I run it on Wine with https://gitlab.com/alexhenrie/ioperm and enter the parallel port's base address manually, the program correctly displays the states of the parallel port's pins and can manipulate them. That means that the main part of the program works, it's just failing to automatically detect the port. The author helpfully wrote up an explanation of what the program does to find parallel ports and their base addresses: https://www.downtowndougbrown.com/2014/11/detecting-parallel-ports-and-thei… $ sha256sum ParallelPortTesterSetup-1.0.0.2.exe 9e9b399dd92ac48433af2061eb8491d1d68a6134eaeab2efcdcd36361e723d09 -- 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 59096] New: GLX backend doesn't work with Nvidia binary drivers since Wine-10.19
by WineHQ Bugzilla 12 Dec '25

12 Dec '25

http://bugs.winehq.org/show_bug.cgi?id=59096 Bug ID: 59096 Summary: GLX backend doesn't work with Nvidia binary drivers since Wine-10.19 Product: Wine Version: 10.19 Hardware: x86-64 URL: https://archive.org/download/Highway_Pursuit/HighwayPu rsuit1_1.exe OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: 349a6e31506f8392c8d37ddf4f02ae89ffcd61a1 Distribution: ArchLinux When falling back to the GLX backend on my Nvidia card using the binary drivers (NVIDIA 580.105.08) all the games that try to access hardware acceleration fail to start. They show a message about missing/unavailable D3D features or simply crash right away. In the terminal I have: 0024:err:d3d:wined3d_adapter_init_gl_caps Received a NULL GL_VENDOR. 0024:err:d3d:wined3d_adapter_gl_init Failed to initialize GL caps for adapter 00EE5510. 0024:err:d3d:wined3d_adapter_init_gl_caps Received a NULL GL_VENDOR. 0024:err:d3d:wined3d_adapter_gl_init Failed to initialize GL caps for adapter 00EE5510. This started happening after commit 349a6e31506f8392c8d37ddf4f02ae89ffcd61a1 win32u: Return the native OpenGL vendor name as GL_VENDOR string. The bug doesn't occur with nouveau vulkan drivers (NVK) and with Mesa-25.3.1 (A more recent regression does affect nouveau/Mesa though: bug #59093) To reproduce, you can try the small freeware game Highway Pursuit. Still present in Wine-11.0-rc1 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: NVIDIA GeForce GTX 1660 SUPER/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 580.105.08 X.Org X Server 1.21.1.21 -- 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 3

[Bug 58790] New: specops the line doesnt get past splash screen
by WineHQ Bugzilla 12 Dec '25

12 Dec '25

http://bugs.winehq.org/show_bug.cgi?id=58790 Bug ID: 58790 Summary: specops the line doesnt get past splash screen Product: Wine Version: 10.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: zlice(a)crtdrift.us Distribution: --- JWM, fluxbox and openbox do not start "specops: the line" - they are stuck on splash screen. my fork of fluxbox (shynebox) does pass the splash screen, but, alt-tabbing breaks the window, at first it will be a 'smooshed' version of the fullscreen window, then alt-tabbing back and forward again will make a 1/4 of the screen window that isnt usable. -- 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 9

[Bug 59128] New: Call of Cthulhu: Dark Corners of the Earth closes its process on launch
by WineHQ Bugzilla 12 Dec '25

12 Dec '25

http://bugs.winehq.org/show_bug.cgi?id=59128 Bug ID: 59128 Summary: Call of Cthulhu: Dark Corners of the Earth closes its process on launch Product: Wine Version: 11.0-rc1 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs(a)list.winehq.org Reporter: andrey.goosev(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: 7780f259d11d3a2f2906e66d423850fe640376f8 Distribution: --- Before mentioned commit launching leads to crash: 0188:err:opengl:DllMain Failed to load unixlib, status 0xc0000005 0188:err:module:loader_init "opengl32.dll" failed to initialize, aborting 0188:err:module:loader_init Initializing dlls for L"Z:\\home\\andrey\\Call of Cthulhu\\Engine\\CoCMainWin32.exe" failed, status c0000142 -- 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 0

[Bug 59108] New: Steam: Client starts up, but all window content is black or white.
by WineHQ Bugzilla 12 Dec '25

12 Dec '25

http://bugs.winehq.org/show_bug.cgi?id=59108 Bug ID: 59108 Summary: Steam: Client starts up, but all window content is black or white. Product: Wine Version: 11.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: chiitoo(a)gentoo.org Regression SHA1: 6048ac5dfebd7090672ec1c26e6e15dfd51d5a8d Distribution: Gentoo The Steam client windows start showing up with white content only after commit 6048ac5dfeb [1], if reporting Windows 7 to it. Reporting Windows 10 instead will make things black instead. After commit b5e59c09d4a [2], the windows are black for both Windows 7 and 10. The whiteness itself seems to be related to commit 18339eb0f50 [3], though the window content still shows up at that point, it's just that, for example, the initial opening of a menu flashes the menu area in white instead of black as it usually does. It also introduces a white flash for when launching Final Fantasy XI Online, so maybe it will receive its own bug too. This with the open-source amdgpu/mesa driver and KWin-X11. Last tested at d60f82860565 [4]. 1. https://gitlab.winehq.org/wine/wine/-/commit/6048ac5dfebd7090672ec1c26e6e15… 2. https://gitlab.winehq.org/wine/wine/-/commit/b5e59c09d4a5ebdd1171bd12733eb6… 3. https://gitlab.winehq.org/wine/wine/-/commit/18339eb0f5048500efb668e6a9b679… 4. https://gitlab.winehq.org/wine/wine/-/commit/d60f8286056559233e992c4084f319… -- 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 56572] New: GraalOnline Worlds 612+: doesn't lunch and hangs
by WineHQ Bugzilla 12 Dec '25

12 Dec '25

https://bugs.winehq.org/show_bug.cgi?id=56572 Bug ID: 56572 Summary: GraalOnline Worlds 612+: doesn't lunch and hangs Product: Wine Version: 9.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: baconkami02(a)gmail.com Distribution: --- Created attachment 76325 --> https://bugs.winehq.org/attachment.cgi?id=76325 Output when running the game This is a new (beta) client for the game GraalOnline, which is a unity wrapper around their already existing client. This bug occurs from version 612 and onward (now at 613), which basically doesn't open the window at all (but the process isn't killed, so it just hangs in the terminal and I'm unable to terminate it). I was told the developers changed 2 main things between the previous version and the one that breaks: - Switched to unity version 2023.2.13f1 - Added Firebase According to guidelines, I shouldn't post the download link as it's from google drive (even if it's the only official way to download it), let me know if you'd still want it. -- 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 4

[Bug 59127] New: ntdll: manifest activeCodePage Legacy value handling doubts (hardcoding)
by WineHQ Bugzilla 12 Dec '25

12 Dec '25

http://bugs.winehq.org/show_bug.cgi?id=59127 Bug ID: 59127 Summary: ntdll: manifest activeCodePage Legacy value handling doubts (hardcoding) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: andi(a)rhlx01.fht-esslingen.de Distribution: --- Hi, filing this from an outside context (simply from observations made with some app, on _Windows_ - NOT _Wine_) - hrmm "bug writing guidelines"? ;-). https://gitlab.winehq.org/wine/wine/-/commit/967ef0bf41fc6742398313ebdebd68… implemented _activeCodePage_ _Legacy_ value handling as such: ` + else if (!wcsicmp( locale, L"legacy" )) + { + if (ansi_cp == CP_UTF8) ansi_cp = 1252; + if (oem_cp == CP_UTF8) oem_cp = 437; + } ` _AFAIK_ this does not match actual behaviour, on Windows 10/11. With manifest `activeCodePage` value `Legacy` config and ACP UTF-8 config setting state enabled (regional settings UTF-8 Beta checkbox *checked*) on a German system (i.e. the manifest properly influencing app-specifically-scoped state), one will get: `GetACP()` 1252 `GetOEMCP()` 850 This quite possibly is because the system (well, _Windows_) in case of _Legacy_ possibly simply does the sensible/expected thing: possibly something like grabbing the default locale state, its corresponding locale map container index, and getting `idefaultansicodepage` and `idefaultcodepage` state of that container element. _IOW_, probably very much like `locale_init()`s handling: entry = find_lcid_entry( locale_table, system_lcid ); ansi_cp = get_locale_data( locale_table, entry->idx )->idefaultansicodepage; oem_cp = get_locale_data( locale_table, entry->idx )->idefaultcodepage; Assigning Severity major since this seems to be a relatively important/global CORRUPTION-level bug (all non-CP1252 system configurations - e.g. Asia, Russia, or whatever - running with an encoding that could be characterized as unexpected/improper *)). NOPE, not assigning major (since this is more limited scope: only relevant to manifest-enabled applications) *) while with properly obeyed _ACP_ protocol behaviour (i.e., application obeying _ACP_ state and properly doing transcoding where it matters), there shouldn't be raw CORRUPTION occurring, this still is problematic (especially since legacy encodings very often do not have fully precise and bijective mapping capabilities when transcoding) Greetings Andreas -- 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 59126] New: NtFsControlFile(FSCTL_PIPE_WAIT) fails to detect infinite timeout
by WineHQ Bugzilla 12 Dec '25

12 Dec '25

http://bugs.winehq.org/show_bug.cgi?id=59126 Bug ID: 59126 Summary: NtFsControlFile(FSCTL_PIPE_WAIT) fails to detect infinite timeout Product: Wine Version: 10.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: services(a)mlugg.co.uk Distribution: --- When calling NtFsControlFile with the FSCTL_PIPE_WAIT control code, the Timeout field in the FILE_PIPE_WAIT_FOR_BUFFER structure is not interpreted correctly. An infinite timeout (equivalent to NMPWAIT_WAIT_FOREVER in kernel32's WaitNamedPipeW) is, on Windows proper, specified by the minimum signed 64-bit integer value, i.e. 0x8000_0000_0000_0000. This behavior is not documented, but can be observed by tracing the ntdll calls triggered by WaitNamedPipeW; and ReactOS also agrees with this value. However, Wine instead represents an infinite timeout using the value 0x7FFF_FFFF_FFFF_FFFF (the *maximum* signed 64-bit integer, aka TIMEOUT_INFINITE). This logic is internally consistent: the WaitNamedPipeW implementation converts NMPWAIT_WAIT_FOREVER to that value, and the server detects it in async_set_timeout (called from named_pipe_device_ioctl in server/named_pipe.c). However, it causes direct usage of this ntdll API to incorrectly return STATUS_IO_TIMEOUT when the correct "infinite timeout" value is passed. I suspect the logic in named_pipe_device_ioctl should be modified to detect the special value 0x8000_0000_0000_0000 and avoid setting a timeout in that case, and that WaitNamedPipeW should be modified to translate NMPWAIT_WAIT_FOREVER to that value rather than 0x7FFF_FFFF_FFFF_FFFF. -- 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 1