wine-bugs July 2023

wine-bugs@winehq.org

1 participants
3139 discussions

[Bug 53806] New: Archicad 26: crash at launch
by WineHQ Bugzilla 31 Jul '23

31 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=53806 Bug ID: 53806 Summary: Archicad 26: crash at launch Product: Wine Version: 7.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: doubleboogieblues(a)yahoo.it Distribution: --- Created attachment 73316 --> https://bugs.winehq.org/attachment.cgi?id=73316 terminal output Wine crash when launched archicad.exe installation ok, but the software does not start installed: dotnet452, vcrun2019, vcrun2013 download DEMO Archicad 26: https://graphisoft.com/dl/AC/26/INT/Archicad-26-INT-3001-1.1.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.

1 6

[Bug 52844] New: Call of Duty: Black Ops II stucks with a black screen after intro
by WineHQ Bugzilla 31 Jul '23

31 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=52844 Bug ID: 52844 Summary: Call of Duty: Black Ops II stucks with a black screen after intro Product: Wine Version: 7.6 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- Created attachment 72240 --> https://bugs.winehq.org/attachment.cgi?id=72240 log wine-7.6-211-ge254680ed15 -- 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 55346] New: ddraw:ddraw2 - test_coop_level_mode_set() sometimes gets unexpected screen size in Wine
by WineHQ Bugzilla 31 Jul '23

31 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55346 Bug ID: 55346 Summary: ddraw:ddraw2 - test_coop_level_mode_set() sometimes gets unexpected screen size in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- ddraw:ddraw2 - test_coop_level_mode_set() sometimes gets unexpected screen size in Wine: ddraw2.c:3237: Test failed: Got unexpected screen size 320x240. ddraw2.c:3243: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:3292: Test marked flaky: Expected message 0x46, but didn't receive it. ddraw2.c:3295: Test marked flaky: Expected screen size 1024x768, got 0x0. ddraw2.c:3302: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). [the messages above don't always happen] ddraw2.c:3326: Test failed: Expected surface width 1024, got 320. ddraw2.c:3328: Test failed: Expected surface height 768, got 240. ddraw2.c:3333: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3341: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3346: Test failed: Expected surface width 1024, got 320. ddraw2.c:3348: Test failed: Expected surface height 768, got 240. ddraw2.c:3361: Test failed: Expected surface width 1024, got 320. ddraw2.c:3363: Test failed: Expected surface height 768, got 240. ddraw2.c:3368: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3384: Test marked todo: Got unexpected hr 0. ddraw2.c:3392: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3412: Test failed: Got unexpected hr 0. ddraw2.c:3414: Test failed: Got unexpected hr 0. ddraw2.c:3422: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3427: Test failed: Expected surface width 1024, got 320. ddraw2.c:3429: Test failed: Expected surface height 768, got 240. ddraw2.c:3449: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3464: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:3470: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3483: Test failed: Expected resolution 1024x768, got 320x240. ddraw2.c:3500: Test failed: Expected surface width 1024, got 320. ddraw2.c:3502: Test failed: Expected surface height 768, got 240. ddraw2.c:3507: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3518: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3523: Test failed: Expected surface width 1024, got 320. ddraw2.c:3525: Test failed: Expected surface height 768, got 240. ddraw2.c:3538: Test failed: Expected surface width 1024, got 320. ddraw2.c:3540: Test failed: Expected surface height 768, got 240. ddraw2.c:3545: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3561: Test marked todo: Got unexpected hr 0. ddraw2.c:3569: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3582: Test failed: Got unexpected hr 0. ddraw2.c:3584: Test failed: Got unexpected hr 0. ddraw2.c:3592: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3597: Test failed: Expected surface width 1024, got 320. ddraw2.c:3599: Test failed: Expected surface height 768, got 240. ddraw2.c:3619: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3634: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:3640: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3653: Test failed: Expected resolution 1024x768, got 320x240. ddraw2.c:3670: Test failed: Expected surface width 1024, got 320. ddraw2.c:3672: Test failed: Expected surface height 768, got 240. ddraw2.c:3678: Test marked flaky: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3695: Test failed: Expected message 0x5, but didn't receive it. ddraw2.c:3697: Test failed: Expected screen size 1024x768, got 0x0. ddraw2.c:3704: Test failed: Expected (0,0)-(1024,768), got (0,0)-(320,240). ddraw2.c:3716: Test failed: Expected surface width 1024, got 320. ddraw2.c:3718: Test failed: Expected surface height 768, got 240. ddraw2.c:3765: Test failed: Expected message 0x47, but didn't receive it. ddraw2.c:3769: Test failed: Expected screen size 2 1024x768, got 0x0. ddraw2.c:3777: Test failed: Expected (0,0)-(1024,768), got (0,0)-(119,100). ddraw2.c:3789: Test failed: Expected surface width 1024, got 320. ddraw2.c:3791: Test failed: Expected surface height 768, got 240. See https://test.winehq.org/data/patterns.html#ddraw:ddraw2 Where 0x46 == WM_WINDOWPOSCHANGING 0x7e == WM_DISPLAYCHANGE Both the expected and unexpected resolutions change from one run to the next: 1024x768 / 320x240 like here or 3840x2160 / 640x480 or 640x480 / 720x480 or 1024x768 / 640x480 or 1024x768 / 400x300. Note that these WineTest reports have no prior test failure. There are not too many instances of this in the nightly tests besides the rbernon-* machines where it happens regularly. However it can also happen for merge requests (3 known cases but there may be more): * 2023-07-26 MR3413 * 2023-06-15 gitlab-debian-32 * 2023-05-12 MR2792 * 2023-02-22 fg-deb64-t32 * 2022-11-29 fgtb-debian11-win32 * 2022-11-28 MR1561 -- 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 21448] New: RollerCoaster Tycoon 3 does not accept the original disc
by wine-bugs＠winehq.org 31 Jul '23

31 Jul '23

http://bugs.winehq.org/show_bug.cgi?id=21448 Summary: RollerCoaster Tycoon 3 does not accept the original disc Product: Wine Version: 1.1.36 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: thomas.mertes(a)gmx.at Created an attachment (id=25828) --> (http://bugs.winehq.org/attachment.cgi?id=25828) Error log and content of message box when starting RollerCoaster Tycoon 3 When starting RollerCoaster Tycoon 3 it asks for the original disc although the original disk is in. There are some errors logged (see attachment) and then a message box appears: Please insert the original disc instead of a backup. See www.securom.com/copy for more details Greetings Thomas -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 46

[Bug 55364] New: Shadow Empire crashes on startup with an error related to SharpDX and Direct2D.
by WineHQ Bugzilla 31 Jul '23

31 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55364 Bug ID: 55364 Summary: Shadow Empire crashes on startup with an error related to SharpDX and Direct2D. Product: Wine Version: 8.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: kindaro(a)gmail.com Distribution: --- _Shadow Empire_ is a computer game. It can be obtained, for example, from Steam or Good Old Games. I installed what I believe to be version 1.21.00. This is the gist of the error message that the game gives me: ``` SharpDX.SharpDXException: HRESULT: [0x88990028], Module: [SharpDX.Direct2D1], ApiCode: [D2DERR_EFFECT_IS_NOT_REGISTERED/EffectIsNotRegistered], Message: Unknown ``` When I run it as `WINEDEBUG=+d2d wine ShadowEmpire.exe`, I see the following warning from Wine: ``` 0114:warn:d2d:d2d_effect_create Effect id {9daf9369-3846-4d0e-a44e-0c607934a5d7} not found. ``` I shall be attaching the full text of the error and Wine's output. My operating system is Arch Linux, recently updated. The failure occurs both with `wine` and `wine-staging`. -- 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 55232] New: Sierra Chart (All versions): Out of order overlapped network I/O receive buffers
by WineHQ Bugzilla 30 Jul '23

30 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55232 Bug ID: 55232 Summary: Sierra Chart (All versions): Out of order overlapped network I/O receive buffers Product: Wine Version: 6.0.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: winsock Assignee: wine-bugs(a)winehq.org Reporter: sc(a)sierrachart.com Distribution: --- Created attachment 74837 --> https://bugs.winehq.org/attachment.cgi?id=74837 Terminal output We have a code which is working fine for years on Windows OS, but on Linux using Wine it produces an IO error. Investigation shows that IO Completion/Overlapped of Wine provides some buffers with received data out of order. Our code relies on correct order of the received buffers. Our code provides to OS some minimum number of buffers available to receive a data. We expect the FIFO logic of the buffer processing: the first provided available buffer will first receive the data. Invoke `WSARecv` with a buffer to receive data. The operation is overlapped using Completion Port. In a worker thread the function `GetQueuedCompletionStatus` is used to get the completion notification about received data in the buffer. At this point we observe a buffer, received out of order. Usually it is happened at beginning of handling buffers: we provide to OS some set of buffers (in common 16), handle all of them with received data, reuse available buffers again to OS to support the minimum set of buffers for OS and most probably the first (or close to first) reused buffer will be received out of the order. Also we observe the out-of-order buffer is returned in the same time slot as it was issued to OS. Relevant WindowsOS functions used: CreateIoCompletionPort WSARecv GetQueuedCompletionStatus Download link: https://www.sierrachart.com/downloads/ZipFiles/SierraChart2522.zip -- 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 55365] New: ntdll:file - test_file_full_size_information() sometimes gets a bad AvailableAllocationUnits value on Windows and Wine
by WineHQ Bugzilla 30 Jul '23

30 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55365 Bug ID: 55365 Summary: ntdll:file - test_file_full_size_information() sometimes gets a bad AvailableAllocationUnits value on Windows and Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com ntdll:file - test_file_full_size_information() sometimes gets a bad AvailableAllocationUnits value on Windows and Wine: file.c:1320: Test failed: [ffsi] CallerAvailableAllocationUnits error fsi:0x12dbfb5, ffsi: 0x12dbfb6 See https://test.winehq.org/data/patterns.html#ntdll:file This is very rare as there are only 3 known instances: * 2023-03-27 linux_gitlab-debian-32 * 2023-06-23 linux_gitlab-debian-32 * 2023-07-27 win21H2_gitlab-win10-21h2-64 This looks very much like a race condition with some other process allocating or freeing disk space in between the FileFsFullSizeInformation and FileFsSizeInformation calls. So this is something that should be fixable with the tryok() API. https://gitlab.winehq.org/wine/wine/-/merge_requests/3418 -- 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

[Bug 55363] New: Wine depends on a manual user intervention to increase the soft limit of file descriptors.
by WineHQ Bugzilla 30 Jul '23

30 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55363 Bug ID: 55363 Summary: Wine depends on a manual user intervention to increase the soft limit of file descriptors. Product: Wine Version: 8.11 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: o.dierick(a)piezo-forte.be Distribution: --- Hello, I recently installed Debian 12 after using Debian 8 for years. After I reproduced my building environment and successfully build the same Wine version as the last built on Debian 8, a game that was working fine in Debian 8 did fail to run on Debian 12 with the error 'too many file descriptors open, you should probably increase ulimit -n'. The difference is that the default soft/hard limit in Debian 12 is 1024/1048576. In Debian 8 it was 65536/65536. I can increase the soft limit by running 'ulimit -n 65536' before hand and then the game runs fine. I could not set the soft limit increase to be permanent and I filed a bug at Debian for that, but that's not what this bug is about. After reading a bit about the reason why the soft limit was reduced to 1024 (for compatibility with select()), my understanding is that a program that is more modern and doesn't use select(), should be aware of its file descriptor needs and ask for a higher soft limit. That's what Debian says about its choice to set the soft limit of 1024 and a hard limit of 1048576 by default. Since the hard limit permits it, I wondered why Wine couldn't increase the soft limit itself. We know that 1024 is not a reasonable amount of file descriptors in this time and day and that a number of windows applications requires more than that. Maybe Wine should set the soft limit to something reasonable itself, rather than requiring the user to set it like explained in the FAQ? It would even be better if it was configurable per-application. 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.

1 2

[Bug 55324] New: AllDup doesn't start in win10 mode: "OS not supported"
by WineHQ Bugzilla 29 Jul '23

29 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55324 Bug ID: 55324 Summary: AllDup doesn't start in win10 mode: "OS not supported" Product: Wine Version: 8.13 Hardware: x86-64 URL: https://www.alldup.info/download/AllDupSetup.zip OS: Linux Status: NEW Keywords: download, patch Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: Debian Created attachment 74920 --> https://bugs.winehq.org/attachment.cgi?id=74920 patch for IsOS This program was tried out by someone on the forum. In default windows 10 mode it pops up a messagbox "OS not supported" and exits. The attached patch is enough to fix this bug. -- 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

[Bug 55352] New: NtTerminateThread should accept handle==0 as current thread
by WineHQ Bugzilla 29 Jul '23

29 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55352 Bug ID: 55352 Summary: NtTerminateThread should accept handle==0 as current thread Product: Wine Version: 8.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: ake.rehnman(a)gmail.com Distribution: --- Created attachment 74936 --> https://bugs.winehq.org/attachment.cgi?id=74936 Example using thread handle 0 to NtTerminateThread Windows accepts thread handle 0 as current thread. See attached example Output from example: c:\temp>test_ntterminatethread.exe h=0000000000000020 call NtTerminateThread h=0 thread exitcode=1234 -- 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

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 July 2023