May 2025 - Wine-bugs - list.winehq.org

[Bug 33092] New: Melodyne Studio demo crashes on startup
by wine-bugs＠winehq.org 02 May '25

02 May '25

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 58044] New: Realm Grinder freezes/crashes after a very long run
by WineHQ Bugzilla 02 May '25

02 May '25

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 58193] New: Dragon Quest X Online fails to play livestream video
by WineHQ Bugzilla 02 May '25

02 May '25

http://bugs.winehq.org/show_bug.cgi?id=58193 Bug ID: 58193 Summary: Dragon Quest X Online fails to play livestream video Product: Wine Version: 10.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)winehq.org Reporter: achurch+wine(a)achurch.org Distribution: --- Created attachment 78496 --> http://bugs.winehq.org/attachment.cgi?id=78496 +mfplat,+dmo debug log Dragon Quest X Online has a feature in which official livestreams can be viewed in-game, but this fails under Wine when using the FFmpeg backend for Media Foundation: 0530:trace:mfplat:source_resolver_CreateObjectFromByteStream 43D86A20, 43E8B754, L"C:/users/dqx/Documents/My Games/DRAGON QUEST X/work/Bin/hls00000470010000058d.aac", 0x1, 00000000, 4573FDE4, 4573FDE8. [...] 0530:trace:mfplat:async_result_SetStatus 43DCBC58, 0xc00d36c4. (This file is an AAC audio chunk downloaded from the livestream. An MPEG-TS video chunk with a similar filename and .ts extension is also stored but never referenced, presumably because this initialization fails.) The MF_E_UNSUPPORTED_BYTESTREAM_TYPE error appears to be returned by mfplat/main.c:resolver_get_bytestream_handler(); this iterates through registry keys for specific supported MIME types and extensions and then falls back to resolver_create_gstreamer_handler(), which naturally fails because Wine is built without GStreamer support. I can get past that error by adding a registry key for .aac (HKCU/Software/Microsoft/Windows Media Foundation/ByteStreamHandlers/.aac) with values copied from an existing bytestream handler (I arbitrarily chose the .mp3 handler), and FFmpeg (via winedmo) appears to correctly recognize the bytestream as AAC audio, but the game's livestream playback thread immediately crashes with a divide-by-zero exception (the game itself is still playable, but an error dialog pops up and no stream is played). Unfortunately, this issue may be difficult to track down because the relevant code is only executed when an official livestream is actually running, and the game does not have any "test" functionality for the livestream viewer. -- 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 58192] New: dozen Vulkan driver fails due to missing/minimal dxcore implementation (both MacOS and Linux)..
by WineHQ Bugzilla 02 May '25

02 May '25

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 02 May '25

02 May '25

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 01 May '25

01 May '25

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 01 May '25

01 May '25

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 01 May '25

01 May '25

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