August 2023 - Wine-Bugs - list.winehq.org

[Bug 54143] New: Chessbase 11 arrows draw too large
by WineHQ Bugzilla Aug. 29, 2023

Aug. 29, 2023

https://bugs.winehq.org/show_bug.cgi?id=54143 Bug ID: 54143 Summary: Chessbase 11 arrows draw too large Product: Wine Version: 8.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdiplus Assignee: wine-bugs(a)winehq.org Reporter: dav75uk(a)yahoo.co.uk Distribution: --- Created attachment 73675 --> https://bugs.winehq.org/attachment.cgi?id=73675 Picture of arrow on wine8.0-rc1 When arrows are drawn using Chessbase 11, they are too big. See attached screenshot and log. Compare with: https://www.youtube.com/watch?v=xvJd97ZnHAk At 4:58 an arrow is showing from g8 to f6 pointing to a knight that has just moved. I've also set up this arrow on chessbase 11 with wine 8.0-rc1. Note later chessbase draws arrows slightly different, so software like CBReader14 doesn't appear to be affecting by this issue. On wine 8.0-rc1 in CB 11 the stem of the arrow looks approx in the right place. It crosses f7/g7 (the squares occupied by pawns) at the right point. The tip of the arrow is in the right place on the knight between the white on the mane and the chin. On wine 7.22 the endcap square (some default catch in a switch statement maybe) is being drawn which is not on native chessbase (thus the arrow isn't meant to hide it). Finally the back of the arrow head is in the wrong place (some scaling maybe?) which is making it too large. On wine 7.22 the back of the arrow is drawn from the right shoulder of the pawn on f7 (the one nearest the king) to near (left of) the base of the one on g7. In the video the arrow appears from under the base of the f7 pawn (almost but not quite lined up horizontally the bishop on f8's cross right hand edge) to just inside the corner of the square the knight is on. -- 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 17

[Bug 51890] New: A lot more old games would be so much more usable if wine's virtual desktop had proper resizing
by WineHQ Bugzilla Aug. 29, 2023

Aug. 29, 2023

https://bugs.winehq.org/show_bug.cgi?id=51890 Bug ID: 51890 Summary: A lot more old games would be so much more usable if wine's virtual desktop had proper resizing Product: Wine-staging Version: 6.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: el(a)horse64.org CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- I have a really significant amount of older games around, none of which will launch on this machine without wine's virtual desktop feature because on a widescreen monitor, they determine there is no "expected" fullscreen resolution available and crash. Now I'd just use the virtual desktop, except it feels archaic and not very usable: why is it that for a 800x600 game on a 800x600 virtual desktop, I can't just maximize the virtual desktop window and get the virtual desktop SCALED UP with proper letterboxing so I can play in some other way than a tiny window with zero immersion and everything so small I can barely see it? Funnily enough I can even resize the virtual desktop window except the resizing is fully ignored and I just get black void with no scaling up all around with the game stuck in the top-left, and the maximizing is blocked. Scaling up (with automatic letterboxing), maximizing would seem like such obvious features to make virtual desktop gaming infinitely less clumsy and weird that I am a bit surprised it's not in there yet. Can it please be added?? -- 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 55496] New: World of Warships (12.7 update) - Graphical glitch - Water texture and effects at wrong sea level.
by WineHQ Bugzilla Aug. 27, 2023

Aug. 27, 2023

https://bugs.winehq.org/show_bug.cgi?id=55496 Bug ID: 55496 Summary: World of Warships (12.7 update) - Graphical glitch - Water texture and effects at wrong sea level. 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: --- Created attachment 75058 --> https://bugs.winehq.org/attachment.cgi?id=75058 Screenshots with glitch highlighted in red. Hello, Since the game update to 12.7, water textures and effects are rendered below the sea level. All objects are rendered at the same 'sea' level and the physics are respected, but the water texture and effects are drawn below the sea surface, as if it was painted at the bottom of a perfectly transparent sea, instead of the top. I'm joining screenshots that show the issue. The glitches are highlighted with red arrows. On the first screenshot, the splash of the water drains are visibly shifted below the ship in the port. On the second screenshot, the space between the island in the distance and the water texture below them is visible. Water trails from moving ships are shifted below them. On the third screenshot, the water trail from the player ship is shifted, as are the splashes from artillery shells. The fourth screenshot shows more shifted water trails and shells splashes, from a dead player's observation camera (higher in the sky). The height of the glitch is proportional to the distance of the camera zoom. The farthest the camera is of the ship, the lower the water texture is drawn. When the camera is zoomed to the closest, the water texture and effects are nearly perfectly placed (it's still shifted by a small amount). The glitch is easier to see when turning the camera around, as the water texture doesn't match the ship position (because of perspective). The water trails and splash effects do match the water texture position, but not their respective objects. Objects matches their relative positions. Note that on the screenshots, the horizon curve to the edge is magnified by my ultra-wide resolution. Don't worry about the calculator on the first screenshot. I had trouble getting a non-transparent screenshot of the Wine full-screen window. After that capture, I found another way that didn't require a non-full-screen window to be active. 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 1

[Bug 53371] New: 0024:fixme:ntdll:create_logical_proc_info stub
by WineHQ Bugzilla Aug. 27, 2023

Aug. 27, 2023

https://bugs.winehq.org/show_bug.cgi?id=53371 Bug ID: 53371 Summary: 0024:fixme:ntdll:create_logical_proc_info stub Product: Wine Version: 7.12 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: yklaxds(a)gmail.com Created attachment 72755 --> https://bugs.winehq.org/attachment.cgi?id=72755 log FreeBSD 13.1 release amd64 KDE plasma 5 emulators/wine-devel 7.12 not work at all. -- 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 55495] New: ntdll:threadpool - test_tp_wait() sometimes gets an unexpected timeout in Wine
by WineHQ Bugzilla Aug. 27, 2023

Aug. 27, 2023

https://bugs.winehq.org/show_bug.cgi?id=55495 Bug ID: 55495 Summary: ntdll:threadpool - test_tp_wait() sometimes gets an unexpected timeout in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- ntdll:threadpool - test_tp_wait() sometimes gets an unexpected timeout in Wine: threadpool.c:1715: Test failed: WaitForSingleObject returned 258 threadpool.c:1720: Test failed: expected info.userdata = 0, got 65536 threadpool.c:1729: Test failed: WaitForSingleObject returned 0 See See https://test.winehq.org/data/patterns.html#ntdll:threadpool 1715 & 1720: The timeout can also happen on Windows 8 and in that case the test expects info.userdata to still be zero. But in Wine info.userdata still gets set despite the timeout so the test fails. A hacky fix would be to expect the correct behavior if (!broken(result == WAIT_TIMEOUT)) but it would be much better to fix Wine's implementation. Then the next WaitForSingleObject() does not time out which sounds a bit similar to bug 55493. The oldest known instance happened at the start of May and this seems to mostly happen on the GitLab CI: * 2023-07-28 MR!3441 (only the last two failures?) * 2023-06-01 MR!2951 (only the last two failures?) * 2023-05-31 fg-deb64-t32 * 2023-05-24 gitlab-debian-32 * 2023-05-02 MR!2734 -- 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 55493] New: ntdll:threadpool - test_tp_timer() sometimes fails in Wine
by WineHQ Bugzilla Aug. 27, 2023

Aug. 27, 2023

https://bugs.winehq.org/show_bug.cgi?id=55493 Bug ID: 55493 Summary: ntdll:threadpool - test_tp_timer() sometimes fails in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- ntdll:threadpool - test_tp_timer() sometimes fails in Wine: threadpool.c:1439: Test failed: WaitForSingleObject returned 0 threadpool.c:1441: Test failed: WaitForSingleObject returned 258 See https://test.winehq.org/data/patterns.html#ntdll:threadpool So instead of getting a timeout then a success, the test first gets an unexpected WaitForSingleObject() success and then a timeout. That means it's not a simple issue of the test running too slow. There are only three known instances so far: * 2023-08-23 MR!3621 * 2023-07-03 MR!3218 * 2023-06-09 fg-deb64-t32 -- 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 55491] New: imm32:imm32 - test_ImmTranslateMessage() sometimes fails on the GitLab CI
by WineHQ Bugzilla Aug. 27, 2023

Aug. 27, 2023

https://bugs.winehq.org/show_bug.cgi?id=55491 Bug ID: 55491 Summary: imm32:imm32 - test_ImmTranslateMessage() sometimes fails on the GitLab CI Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: imm32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- imm32:imm32 - test_ImmTranslateMessage() sometimes fails on the GitLab CI: imm32.c:7147: Test marked todo: default: 1: got hkl E020047F, himc 02970116, IME_TO_ASCII_EX vkey 0x51, vsc 0xffffc010, flags 0 imm32.c:3496: Test marked todo: default: got msgs->uMsgCount 10 imm32.c:3496: Test marked todo: default: got msgs->uMsgCount 10 imm32.c:7166: Test failed: default: 1: got hkl E020047F, himc 00000000, MSG_IME_UI msg WM_IME_STARTCOMPOSITION, wparam 0x1, lparam 0 imm32.c:7166: Test failed: default: 3: got hkl E020047F, himc 00000000, MSG_IME_UI msg WM_IME_ENDCOMPOSITION, wparam 0x1, lparam 0 imm32.c:7168: Test failed: default: 1: got hkl E020047F, himc 00000000, MSG_IME_UI msg WM_IME_STARTCOMPOSITION, wparam 0x2, lparam 0 imm32.c:7168: Test failed: default: 3: got hkl E020047F, himc 00000000, MSG_IME_UI msg WM_IME_ENDCOMPOSITION, wparam 0x2, lparam 0 imm32.c:3496: Test marked todo: default: got msgs->uMsgCount 10 imm32.c:3496: Test marked todo: default: got msgs->uMsgCount 10 imm32.c:7179: Test failed: default: 1: got hkl E020047F, himc 00000000, MSG_IME_UI msg WM_IME_STARTCOMPOSITION, wparam 0x2, lparam 0 imm32.c:7179: Test failed: default: 3: got hkl E020047F, himc 00000000, MSG_IME_UI msg WM_IME_ENDCOMPOSITION, wparam 0x2, lparam 0 imm32.c:3496: Test marked todo: default: got msgs->uMsgCount 10 imm32.c:3496: Test marked todo: default: got msgs->uMsgCount 10 imm32.c:7191: Test failed: default: 1: got hkl E020047F, himc 00000000, MSG_IME_UI msg WM_IME_STARTCOMPOSITION, wparam 0x1, lparam 0 imm32.c:7191: Test failed: default: 3: got hkl E020047F, himc 00000000, MSG_IME_UI msg WM_IME_ENDCOMPOSITION, wparam 0x1, lparam 0 imm32.c:3496: Test marked todo: kbd_char_first: got msgs->uMsgCount 10 imm32.c:3496: Test marked todo: kbd_char_first: got msgs->uMsgCount 10 imm32.c:7147: Test marked todo: kbd_char_first: 1: got hkl E020047F, himc 02970116, IME_TO_ASCII_EX vkey 0x51, vsc 0xffffc010, flags 0 See https://test.winehq.org/data/patterns.html#imm32:imm32 This first happened on 2023-05-04 and is specific to the gitlab-debian-* test environment. As such it may be caused by the GitLab CI's (lack of) fvwm configuration. -- 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 55490] New: Halo Online / Eldewrito - Dedicated Server
by WineHQ Bugzilla Aug. 26, 2023

Aug. 26, 2023

https://bugs.winehq.org/show_bug.cgi?id=55490 Bug ID: 55490 Summary: Halo Online / Eldewrito - Dedicated Server Product: Wine Version: 8.0.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bogdan17(a)garglob.com Distribution: --- When I try to run a dedicated server on a computer that does not have a GPU (AMD or NVIDIA), it will not launch the dedicated server, even though the dedicated server does not require any graphical. I was able to run this on the same computer running Windows 10 without any issues which also did not have a AMD or NVIDIA GPU. This is the terminal output when trying to run the dedicated server. Not sure wine insists I need a GPU. john(a)pc:~$ env WINEPREFIX="/path/to/wine/prefix/" "wine "C:\windows\command\start.exe" /Unix "/path/to/wine/prefix/drive_c/HaloOnline/eldorado.exe" "-dedicated -window -height 200 -width 200 -minimized" 002c:err:wineboot:process_run_key Error running cmd L"C:\\windows\\system32\\winemenubuilder.exe -a -r" (2). 0074:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0074:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0074:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0074:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 john(a)pc:~$ 00d4:err:vulkan:wine_vk_init Failed to load libvulkan.so.1. 00cc:err:winediag:ntlm_check_version ntlm_auth was not found. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution. 00cc:err:ntlm:ntlm_LsaApInitializePackage no NTLM support, expect problems 011c:fixme:ver:GetCurrentPackageId (0D5AFEF0 00000000): stub 00cc:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION 00cc:err:vulkan:wine_vk_init Failed to load libvulkan.so.1. 00cc:err:wgl:init_opengl Failed to load libGL: libGL.so.1: cannot open shared object file: No such file or directory 00cc:err:wgl:init_opengl OpenGL support is disabled. 00cc:err:d3d:wined3d_caps_gl_ctx_create Failed to find a suitable pixel format. 00cc:err:d3d:wined3d_adapter_gl_init Failed to get a GL context for adapter 06AF6DD0. john(a)pc:~$ -- 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 55485] New: FindFirstFileA fails on \\.\pipe\*
by WineHQ Bugzilla Aug. 26, 2023

Aug. 26, 2023

https://bugs.winehq.org/show_bug.cgi?id=55485 Bug ID: 55485 Summary: FindFirstFileA fails on \\.\pipe\* Product: Wine Version: 8.12 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Created attachment 75043 --> https://bugs.winehq.org/attachment.cgi?id=75043 test.c Split from bug 53961. On windows you can use FindFirstFileA with "\\.\pipe\*", on wine this fails. -- 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 52235] New: Many surfaces in the game Obduction look black
by WineHQ Bugzilla Aug. 25, 2023

Aug. 25, 2023

https://bugs.winehq.org/show_bug.cgi?id=52235 Bug ID: 52235 Summary: Many surfaces in the game Obduction look black Product: Wine Version: 7.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: zerooneo(a)01101001.net Distribution: --- Created attachment 71338 --> https://bugs.winehq.org/attachment.cgi?id=71338 Screenshot When running the game Obduction in wine, an interesting effect occurs where most surfaces are pure black, yet with some lighting etc. applied, leaving the game looking extremely dark. This effect does not occur when running the game with DXVK, meaning there's a very specific difference the two implementations that has a large effect on this game. The log shows a few DirectX and Direct3D-messages initially (counts on the left): 1 03d8:fixme:dxgi:DXGID3D10CreateDevice Ignoring flags 0x1. 1 03d8:fixme:dxgi:DXGID3D10CreateDevice Ignoring flags 0x20. 1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x12d2cad0, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8d30, modes 0x7fe90cc3ac00 partial stub! 1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x12d2cad0, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8d30, modes (nil) partial stub! 1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xed354e0, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8ad0, modes 0x18fa4d80 partial stub! 1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xed354e0, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8ad0, modes (nil) partial stub! 1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xed39050, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8ab0, modes 0x1aece780 partial stub! 1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xed39050, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8ab0, modes (nil) partial stub! 1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xf0f51c0, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8d50, modes 0x1af84680 partial stub! 1 03d8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0xf0f51c0, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x4e8d50, modes (nil) partial stub! 2 04a8:fixme:d3d:create_texture_view Depth slice (0-1) not supported. 10 04a8:fixme:d3d_shader:shader_glsl_handle_instruction Backend can't handle opcode dcl_stream. 46 03d8:fixme:d3d11:d3d11_device_CheckFeatureSupport Unhandled feature 0x3. 432 04a8:fixme:d3d_shader:shader_glsl_interpolation_qualifiers Unhandled interpolation mode 0x3. And then thousands of these: 1080 04a8:err:d3d:wined3d_debug_callback 0x578c00: "GL_INVALID_ENUM in glTexBufferRange(internalFormat GL_RGBA16_SNORM)". 4632 04a8:err:d3d:wined3d_debug_callback 0x578c00: "GL_INVALID_ENUM in glTexBufferRange(internalFormat GL_RGBA8_SNORM Might it be that certain textures or shaders aren't supported, and that that leads to them being rendered as black? This game also requires some other features in order to work fully, but it might be worth it to fix this issue either for the sake of other games, or in case further support for this game is added in the future. -- 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