- Wine-Bugs - list.winehq.org

[Bug 33092] New: Melodyne Studio demo crashes on startup
by wine-bugs＠winehq.org May 15, 2025

May 15, 2025

http://bugs.winehq.org/show_bug.cgi?id=33092 Bug #: 33092 Summary: Melodyne Studio demo crashes on startup Product: Wine Version: 1.4.1 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: jules.bernable(a)laposte.net Classification: Unclassified Created attachment 43757 --> http://bugs.winehq.org/attachment.cgi?id=43757 wine backtrace Could the same issue as #16650, however this is happening with wine 1.4.1 on debian wheezy. -- 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 16

[Bug 24514] New: LVM_SUBITEMHITTEST fails on Chinese and Japanese Versions of XP
by wine-bugs＠winehq.org May 15, 2025

May 15, 2025

http://bugs.winehq.org/show_bug.cgi?id=24514 Summary: LVM_SUBITEMHITTEST fails on Chinese and Japanese Versions of XP Product: Wine Version: 1.3.3 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: austin.lund(a)gmail.com In the test_hittest function for the listview test the following test fails for the Chinese and Japanese versions on the test bot: /* subitem returned with -1 item too */ x = pos.x + 150; y = -10; test_lvm_subitemhittest(hwnd, x, y, -1, 1, LVHT_NOWHERE, FALSE, FALSE, FALSE); The failures read: listview.c:3056: Test failed: Expected -1 retval, got -2 listview.c:3056: Test failed: Expected -1 item, got -2 listview.c:3056: Test failed: Expected flags 0x1, got 0x4 This basically says that the message returned -2 (undocumented ?) and set the flags to LVHT_ONITEMLABEL. Is y = -10 relative to the control client area or the parent window? How can you be on the item label in either case? Should the above values be added as successes to this test? -- 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 17

[Bug 58044] New: Realm Grinder freezes/crashes after a very long run
by WineHQ Bugzilla May 15, 2025

May 15, 2025

https://bugs.winehq.org/show_bug.cgi?id=58044 Bug ID: 58044 Summary: Realm Grinder freezes/crashes after a very long run Product: Wine Version: 10.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: galtgendo(a)o2.pl Distribution: --- Created attachment 78299 --> https://bugs.winehq.org/attachment.cgi?id=78299 output of two failed runs This I strongly suspect is a regression, yet I can't really pin down the time when this started happening. The problem happens with little to no human interaction, yet the timeframes make it unreasonable to actively reproduce. I suspect it started around 10.0 release, but with a -/+ 2 months margin (so close to useless). Anyway, what's the problem ? If Realm Grinder is run for long enough (but 'long enough' here is measured in *days*), it tends to eventually either freeze with a completely black window or crash with an X server error. The attachment has output of two such runs, second chunk is when it just froze, the first when it crashed. 'fixme:d3d:swapchain_blit_gdi Using GDI present.' at the end of both seems to be the moment the problem triggers. It seems to be some kind of a resource leak, but it doesn't affect any other apps running besides it, not even those run by wine. No user action is really required to trigger this - I've seen it freeze after a desktop switch, I've seen it crash when the window was just displayed, but not really interacted with. (Realm Grinder here is still at v4.2.27.0, though I'll likely update it shortly for Easter event) -- 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 58192] New: dozen Vulkan driver fails due to missing/minimal dxcore implementation (both MacOS and Linux)..
by WineHQ Bugzilla May 15, 2025

May 15, 2025

http://bugs.winehq.org/show_bug.cgi?id=58192 Bug ID: 58192 Summary: dozen Vulkan driver fails due to missing/minimal dxcore implementation (both MacOS and Linux).. Product: Wine Version: 10.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: rtfss1(a)gmail.com Distribution: --- Hi, in brief my request expand dxcore.dll support in Wine to a minimal dxcore implementation that allows to run Dozen via Wine.. on both Macos and Linux.. on MacOS for Dozen+D3DMetal testing on Linux for Dozen+VKD3D testing.. details: just wanting to test Dozen (Mesa Vulkan over D3D12 library) in Macos with Crossover 25.0 (bottle setup to using D3DMetal 2.1 as D3D12 driver).. for that I just download: mesa3d-25.0.4-release-msvc.7z from: https://github.com/pal1000/mesa-dist-win/releases/tag/25.0.4 and then adjust ICD loader to find the vulkan_dzn.dll driver and run vulkaninfo.exe.. I check I have all enviroment correctly as also extract lavapipe Vulkan driver from that package and it works correctly with vulkaninfo.exe using dozen on Crossover 25.0 (setup to use D3DMetal 2.1) I see bug that is not related to D3DMetal D3D12 driver: MESA: error: Failed to retrieve D3D12GetInterface MESA: error: Failed to create DXCore adapter factory so would fail also on Linux.. seeing Dozen source code I find in: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/microsoft/vulkan/d… fails in dzn_enumerate_physical_devices_dxcore function.. code below.. that is using dxcore and fails with DXCoreCreateAdapterFactory being a stub currently: https://github.com/wine-mirror/wine/blob/master/dlls/dxcore/main.c perhaps it's better to use as reference if wanting to implement dxcore Wine support checking it works with a minimal sample provided "Minimal DXCore application": https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/dxcore/dxcore-… dxcore microsoft docs: https://learn.microsoft.com/en-us/windows/win32/dxcore/dxcore-enum-adapters dxcore seems the "future" to enumerate adapters on Windows due to enumeration possibly NPU devices also.. dozen source code where it fails: util_dl_library *dxcore = util_dl_open(UTIL_DL_PREFIX "dxcore" UTIL_DL_EXT); if (!dxcore) { mesa_loge("Failed to load DXCore\n"); return VK_ERROR_INITIALIZATION_FAILED; } using PFNDXCoreCreateAdapterFactory = HRESULT (APIENTRY*)(REFIID, void **); PFNDXCoreCreateAdapterFactory create_func = (PFNDXCoreCreateAdapterFactory)util_dl_get_proc_address(dxcore, "DXCoreCreateAdapterFactory"); if (!create_func) { mesa_loge("Failed to load DXCoreCreateAdapterFactory\n"); return VK_ERROR_INITIALIZATION_FAILED; } IDXCoreAdapterFactory *factory; if (FAILED(create_func(IID_PPV_ARGS(&factory)))) { mesa_loge("Failed to create DXCore adapter factory\n"); return VK_ERROR_INITIALIZATION_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 0

[Bug 42898] New: Listbox keyboard input
by wine-bugs＠winehq.org May 15, 2025

May 15, 2025

https://bugs.winehq.org/show_bug.cgi?id=42898 Bug ID: 42898 Summary: Listbox keyboard input Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: janwinehq(a)gmail.com Distribution: --- A listbox widget in Wine does not react the same way to keyboard input as in Windows. In Windows, you can type the first characters of a word and the cursor will jump to the first item matching *all* the characters you typed. This allows you to drill down quickly to the item you want. In Wine, when you start typing it only considers the *last* character you typed when looking for a match. On listboxes where you have lots of items starting with the same character, this can make it problematic to drill down to the correct item. This may be better explained with a simple example. Suppose you have a listbox with the following items, sorted alphabetically: * AMBER * BLUE * BROWN * GREEN * ORANGE * RED * YELLOW Windows behavior: * if you type "B", it will drill down to "BLUE" * if you type "BR", it will drill down to "BROWN" * if you type "BRO", it will drill down to "BROWN" Wine behavior: * if you type "B", it will drill down to "BLUE" * if you type "BR", it will drill down to "RED" * if you type "BRO", it will drill down to "ORANGE" -- 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 10

[Bug 58180] New: CaptureAge 1.17.1: fails to GetSharedHandle
by WineHQ Bugzilla May 15, 2025

May 15, 2025

http://bugs.winehq.org/show_bug.cgi?id=58180 Bug ID: 58180 Summary: CaptureAge 1.17.1: fails to GetSharedHandle Product: Wine Version: 10.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: eabesea(a)rambler.ru Distribution: Ubuntu Created attachment 78475 --> http://bugs.winehq.org/attachment.cgi?id=78475 captureage log When I run CaptureAge, it fails to start rendering. It appears that the fail is because dxgi_resource_GetSharedHandle is not implemented. I'm not attaching full wine terminal output since it's very large and appears to be mostly irrelevant. -- 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 58188] New: CreateProcessW fails for executables with a dot in their name
by WineHQ Bugzilla May 15, 2025

May 15, 2025

http://bugs.winehq.org/show_bug.cgi?id=58188 Bug ID: 58188 Summary: CreateProcessW fails for executables with a dot in their name Product: Wine Version: 10.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: paosz(a)vestas.com Distribution: --- Created attachment 78491 --> http://bugs.winehq.org/attachment.cgi?id=78491 Archive with relevant logs, reproduction program and a proposed patch If an exe file has a name that contains a dot that's not part of the extension (e.g. SomeProgram.Component.exe), then call to CreateProcessW using only lpCommandLine (lpApplicationName = NULL) with the extension of the executable omitted (SomeProgram.Component arguments) will fail on wine, but succeed on Windows. This was observed in wine compiled from source (10.6) and packaged in Ubuntu 24.04 (9.0). The issue was originally thought to be caused by SearchPathW, but further investigation showed that this function behaves as it should. There just simply seems to be a special case or different logic in CreateProcessW that isn't captured in wine. Reproduction: Attached are two C programs used to investigate and reproduce the issue. They test behavior of CreateProcessW and SearchPathW. Both .c files are meant to be compiled and placed in the same folder in the following way: - BugTest.exe (BugTest.c) - SomeApp.exe (SomeApp.c) - SomeApp.Component.exe (SomeApp.c) Afterwards, BugTest.exe is run in the same folder. Attached are the outputs of running that program in Windows and wine (output_wine.txt, output_windows.txt). The obvious difference is the failure whe calling CreateProcessW for SomeApp.Component . Proposed patch: Attached is a patch with proposed fix for the above mentioned issue. There is also on output of BugTest.exe on wine compiled with the attached patch (output_wine_with_patch.txt), which is the same as what's produced on Windows. PS: I just noticed that there can only be one attachment. I have packed all the mentioned files into a zip archive. If that is undesirable I will upload the files separately. -- 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 58164] New: WINTAB32.dll: When the pen is pressed against the board, pkStatus is given TPS_QUEUE_ERR after a second or two and Queue overflows.
by WineHQ Bugzilla May 15, 2025

May 15, 2025

http://bugs.winehq.org/show_bug.cgi?id=58164 Bug ID: 58164 Summary: WINTAB32.dll: When the pen is pressed against the board, pkStatus is given TPS_QUEUE_ERR after a second or two and Queue overflows. Product: Wine Version: 10.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wintab32 Assignee: wine-bugs(a)winehq.org Reporter: axis6404(a)proton.me Distribution: --- When the pen is pressed against the board, pkStatus is given TPS_QUEUE_ERR after a second or two and Queue overflows. After the queue overflows, no signal is sent. (After raising the pen again, until it is pressed against the board again) Cannot draw anything or the line thickness is messed up. https://github.com/wine-mirror/wine/blob/f7503d0a996ae1243dd6c87b39a9143624… Macromedia Flash MX X11 Section "InputClass" Identifier "Tablet" Driver "wacom" MatchDevicePath "/dev/input/event*" MatchUSBID "28bd:0905" Option "Suppress" "0" Option "Threshold" "1" Option "RawSample" "1" EndSection -- 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 58162] New: GetPrivateProfileIntA/W and WritePrivateProfileStringA/W does not detour properly.
by WineHQ Bugzilla May 15, 2025

May 15, 2025

http://bugs.winehq.org/show_bug.cgi?id=58162 Bug ID: 58162 Summary: GetPrivateProfileIntA/W and WritePrivateProfileStringA/W does not detour properly. Product: Wine Version: 10.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: hibbsncc1701(a)gmail.com Distribution: --- Created attachment 78443 --> http://bugs.winehq.org/attachment.cgi?id=78443 sone_patch's debug log under Windows 10. When trying to detour a Recettear - An Item Shop's Tale's custom.exe using https://gitlab.com/redpolline/sone_patch, all attempts to update the game's config ini file fail under Wine, but work under Windows. The game's custom.exe uses the GetPrivateProfileIntA() and WritePrivateProfileStringA() functions to access the game's ini file instead of calling CreateFileA(), ReadFile(), and WriteFile() directly. I assume that the cause is Wine possibly having GetFullPathNameW() as a statically linked symbol within the context of GetPrivateProfileIntA() and WritePrivateProfileStringA(). (As all three of them are exported by kernel32.dll, and therefore the compiler would not need to search for the symbol at build time.) But I could be wrong here. What matters is that when sone_patch detours GetFullPathNameA/W(), GetPrivateProfileIntA() and WritePrivateProfileStringA() should be affected by that detour without being detoured themselves. A good way to see this is by using sone_patch's debug build, as it logs when a detoured function is hit, along with the given arguments. Under Windows 10, multiple calls to GetFullPathNameA/W() are seen in the log. (But no CreateFileA/W() for the ini file.) Under Wine, no calls are logged at all for the ini file. The only call to GetFullPathNameW() seen under Wine is for C:\windows\resources\themes\light\light.msstyles. Which isn't present under the Windows log, so that one is Wine specific.) As a result, the game's button config and display settings cannot be altered by the game's custom.exe. As it gets the original (developer intended) file which is read-only (and owned by another user) on my system. Which sone_patch is supposed to workaround through the detouring of GetFullPathNameA/W() to point custom.exe to an accessible file elsewhere. -- 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 57672] New: Knights of the Old Republic II - Rendering issues and crashes when using new WoW64 mode
by WineHQ Bugzilla May 15, 2025

May 15, 2025

https://bugs.winehq.org/show_bug.cgi?id=57672 Bug ID: 57672 Summary: Knights of the Old Republic II - Rendering issues and crashes when using new WoW64 mode Product: Wine Version: 10.0-rc5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs(a)winehq.org Reporter: info(a)fdossena.com Distribution: --- Created attachment 77849 --> https://bugs.winehq.org/attachment.cgi?id=77849 Screenshot of how the game looks with the new WoW64 mode I'm testing the "classic" version of KOTOR 2 (not the 2015 remaster from steam) and I noticed a strange behavior. When building Wine using the new WoW64 mode, the game has visual artifacts in the character creation screen, and freezes when trying to start a new game. When building Wine with the old WoW64, the game works correctly. The first game, based on the same engine, works correctly with both versions of WoW64. Tested on: * Arch Linux x86_64, Kernel 6.12 * AMD Radeon RX6900XT with Mesa 24.3.3 * KDE Plasma on Wayland (wine is running with the x11 backend) I'm attaching screenshots of Wine 10.0-rc5. Logs don't show anything out of the ordinary or different between the two builds. -- 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