- Wine-Bugs - list.winehq.org

[Bug 3930] HOMM/Deadlock shows black screen (game DLL calls SuspendThread inside WOM_OPEN winmm callback)
by WineHQ Bugzilla March 1, 2025

March 1, 2025

https://bugs.winehq.org/show_bug.cgi?id=3930 --- Comment #82 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- (In reply to Dmitry Timoshkov from comment #81) > (In reply to Damjan Jovanovic from comment #80) > > In other words, Windows probably checks something like "if emulating Windows > > 9x and the WINMM callback is located in a file called WAIL32.DLL", then it > > runs the callback in a separate thread. (I say that because Windows does not > > use a separate callback thread when you set Windows 95 compatibility and > > call waveOutOpen() directly, but does use it when WAIL32.DLL calls it.) > > > > So that's why HOMM works on recent Windows versions, but doesn't work on > > Wine: Windows has application-specific workarounds :-(. > > What happens if you rename WAIL32.DLL to something else? With Windows 95 compatibility set, Windows successfully avoids the deadlock in my test regardless of the WAIL DLL name. Either Windows detects the WAIL DLL some other way (DLL checksum, some resource string, presence of SuspendThread in the DLL's import table, etc.), or I missed something and WINMM behaves differently based on some parameter that differs between WAIL's waveOutOpen() call and my direct waveOutOpen() call. -- 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 3930] HOMM/Deadlock shows black screen (game DLL calls SuspendThread inside WOM_OPEN winmm callback)
by WineHQ Bugzilla March 1, 2025

March 1, 2025

https://bugs.winehq.org/show_bug.cgi?id=3930 --- Comment #81 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Damjan Jovanovic from comment #80) > In other words, Windows probably checks something like "if emulating Windows > 9x and the WINMM callback is located in a file called WAIL32.DLL", then it > runs the callback in a separate thread. (I say that because Windows does not > use a separate callback thread when you set Windows 95 compatibility and > call waveOutOpen() directly, but does use it when WAIL32.DLL calls it.) > > So that's why HOMM works on recent Windows versions, but doesn't work on > Wine: Windows has application-specific workarounds :-(. What happens if you rename WAIL32.DLL to something else? -- 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 57596] New: Chessbase 17 no board sounds
by WineHQ Bugzilla March 1, 2025

March 1, 2025

https://bugs.winehq.org/show_bug.cgi?id=57596 Bug ID: 57596 Summary: Chessbase 17 no board sounds Product: Wine Version: 10.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dav75uk(a)yahoo.co.uk Distribution: --- Even when board sounds are enabled, no sound is made when expected - would expect probably piece moves and illegal move to sound. Illegal move on CBase11 was an annoying shrill whistle, so maybe it's actually a blessing. -- 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 3930] HOMM/Deadlock shows black screen (game DLL calls SuspendThread inside WOM_OPEN winmm callback)
by WineHQ Bugzilla March 1, 2025

March 1, 2025

https://bugs.winehq.org/show_bug.cgi?id=3930 --- Comment #80 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- So I tried to run HOMM again recently, and was disappointed to see this bug still hasn't been fixed. And so I began digging even deeper to discover what's wrong. The game has the following binaries: EDITOR.EXE - the map editor, unaffected by this bug. HEROES.EXE - the game, affected by this bug. SMACKW32.DLL - SMACK video codec (https://www.radgametools.com/smkmain.htm) SMKWAI32.DLL - SMACK video codec (https://www.radgametools.com/smkmain.htm) WAIL32.DLL - Miles Sound System ("Audio Interface Library"). Both HEROES.EXE and the SMACK libraries can call WAIL32.DLL, but this deadlock clearly happens when HEROES.EXE calls it, via the "_AIL_waveOutOpen(a)16" export. The only place where WAIL32.DLL calls waveOutOpen() is in its function at address 0x20008f64, called from the "_AIL_waveOutOpen(a)16" exported function. The flags to waveOutOpen() specify 0x30000 == CALLBACK_FUNCTION, and the callback is at address 0x20008e6d. This callback unconditionally calls SuspendThread() on the thread that previously called "_AIL_startup(a)0" (which is the same thread in the game), and then calls ResumeThread() if the message isn't WOM_DONE (ie. if it is WOM_OPEN or WOM_CLOSE), or if certain other complicated conditions are met. But there is no way that this callback at 0x20008e6d can avoid deadlocking if it is called on the same thread as waveOutOpen() (and _AIL_waveOutOpen(a)16). But how is it that on Windows, in my "winmm test" attachment, the callback happens on the same thread as the thread that I call waveOutOpen() on? Wouldn't that deadlock WAIL32.DLL like Wine does? I decided to test something else: load WAIL32.DLL from the game, and call _AIL_startup(a)0 and _AIL_waveOutOpen(a)16 myself to see what happens: ---snip--- #include <stdio.h> #include <stdlib.h> #include <windows.h> static void test_wail(void) { HINSTANCE dll = LoadLibraryA("WAIL32.DLL"); printf("LoadLibraryA() returned %p, GetLastError()=%d\n", dll, GetLastError()); if (dll != NULL) { void (*ail_startup)(void); int (*ail_waveOutOpen)(HWAVEOUT** phWaveOut, HWAVEOUT** phWaveOut2, UINT uDeviceId, WAVEFORMATEX *waveFormatEx); ail_startup = GetProcAddress(dll, "_AIL_startup(a)0"); if (ail_startup != NULL) { ail_startup(); printf("called _AIL_startup(a)0\n"); } else printf("GetProcAddress() couldn't find _AIL_startup(a)0\n"); ail_waveOutOpen = GetProcAddress(dll, "_AIL_waveOutOpen(a)16"); if (ail_waveOutOpen != NULL) { HWAVEOUT *hWaveOut; WAVEFORMATEX waveFormatEx; int ret; waveFormatEx.wFormatTag = 1; waveFormatEx.nChannels = 1; waveFormatEx.nSamplesPerSec = 22050; waveFormatEx.nAvgBytesPerSec = 22050; waveFormatEx.nBlockAlign = 1; waveFormatEx.wBitsPerSample = 8; waveFormatEx.cbSize = 0; printf("calling ail_WaveOutOpen()...\n"); ret = ail_waveOutOpen(&hWaveOut, NULL, 0, &waveFormatEx); printf("ail_WaveOutOpen() returned %d\n", ret); } else printf("GetProcAddress() couldn't find _AIL_waveOutOpen(a)16"); system("pause"); FreeLibrary(dll); } } int main(int argc, char *argv[]) { test_wail(); return 0; } ---snip--- Compile this, and run it with WAIL32.DLL in the same directory, and SURPRISE SURPRISE: 1. It deadlocks on Wine. 2. IT DEADLOCKS ON WINDOWS TOO!!! Just like on Wine, the last line printed is "calling ail_WaveOutOpen()...", and it never returns from ail_waveOutOpen(). 3. If you right-click the executable, select "Properties" from the dropdown menu, go to the "Compatibility" tab, check "Run this program in compatibility mode for:" and select "Windows 95", click "OK", and run it again, it will successfully run and exit, no longer deadlocking! In other words, Windows probably checks something like "if emulating Windows 9x and the WINMM callback is located in a file called WAIL32.DLL", then it runs the callback in a separate thread. (I say that because Windows does not use a separate callback thread when you set Windows 95 compatibility and call waveOutOpen() directly, but does use it when WAIL32.DLL calls it.) So that's why HOMM works on recent Windows versions, but doesn't work on Wine: Windows has application-specific workarounds :-(. I am not sure how to proceed at this point. Should we use the Windows version to determine which thread to call WINMM callback functions on? Should we also have application-specific workarounds? Or rewrite a better open-source WAIL32.DLL that would be used in preference to the dodgy one games ship? -- 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 57895] New: Some game crash witch wine damavand in native wayland mode
by WineHQ Bugzilla March 1, 2025

March 1, 2025

https://bugs.winehq.org/show_bug.cgi?id=57895 Bug ID: 57895 Summary: Some game crash witch wine damavand in native wayland mode Product: Wine Version: 10.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: nicoloverwhelming(a)rustyload.com Distribution: --- Created attachment 78126 --> https://bugs.winehq.org/attachment.cgi?id=78126 signalis Some game crash witch wine damavand in native wayland mode.This does not happen when working through xwayland. These games also work when using wined3d and wine wayland games that break down: signalis Dread Delusion Deus Ex Revision games that work fine: WILL A Wonderful World terraria Mondealy tested wine: 10.0-10.2 / staging/ wow64 Linux: Manjaro 25.0 KDE Plasma Version: 6.3.2, wayland Nvidia video driver: 570.124.04 witch close kernel module start command: WINE_D3D_CONFIG=renderer=vulkan DISPLAY= mangohud wine signalis.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 1

[Bug 55257] New: Excel Viewer 2007 title bar is not rendered correctly
by WineHQ Bugzilla March 1, 2025

March 1, 2025

https://bugs.winehq.org/show_bug.cgi?id=55257 Bug ID: 55257 Summary: Excel Viewer 2007 title bar is not rendered correctly Product: Wine Version: 8.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: aros(a)gmx.com Distribution: --- Created attachment 74869 --> https://bugs.winehq.org/attachment.cgi?id=74869 With Wine native decoration Files to download and install (md5sum): ExcelViewer2007.exe (cb4f2202fc368af9476effed5cc7b8a4) ExcelViewer2007sp3-kb2526302-fullfile-en-us.exe (df16f0c83d87465e5f7ee332c64f7861) Check the attached screenshots. -- 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 57894] New: In some games on opengl you can see the part of the desktop, when using native wayland
by WineHQ Bugzilla March 1, 2025

March 1, 2025

https://bugs.winehq.org/show_bug.cgi?id=57894 Bug ID: 57894 Summary: In some games on opengl you can see the part of the desktop, when using native wayland Product: Wine Version: 10.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: nicoloverwhelming(a)rustyload.com Distribution: --- Created attachment 78124 --> https://bugs.winehq.org/attachment.cgi?id=78124 noita glitch In some games on opengl you can see the part of the desktop, when using native wayland.This does not happen when working through xwayland. For example in Noita game you can see the part of the desktop in the game menu. I wanted to check the work through zink, but it looks like it doesn’t work in native wayland. tested wine: 10.0-10.2 / staging/ wow64 Linux: Manjaro 25.0 KDE Plasma Version: 6.3.2, wayland Nvidia video driver: 570.124.04 witch close kernel module start command: DISPLAY= mangohud wine noita.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 1

[Bug 57246] New: TeraTerm 5.3 / Serial communication not functional
by WineHQ Bugzilla March 1, 2025

March 1, 2025

https://bugs.winehq.org/show_bug.cgi?id=57246 Bug ID: 57246 Summary: TeraTerm 5.3 / Serial communication not functional Product: Wine Version: 9.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: janne.kekkonen(a)gmail.com Distribution: --- When data is sent to serial port that is opened with TeraTerm, GUI becomes very sluggish and data received is not shown on the terminal. When sending data is stopped. Received data is shown and GUI responsiveness becomes normal. This behavior seems very similar that is described in bug 50591. -- 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 57450] New: The cursor position does not match the position in application’s . Invisible borders of the wine wayland full screen
by WineHQ Bugzilla March 1, 2025

March 1, 2025

https://bugs.winehq.org/show_bug.cgi?id=57450 Bug ID: 57450 Summary: The cursor position does not match the position in application’s . Invisible borders of the wine wayland full screen Product: Wine Version: 9.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: nicoloverwhelming(a)rustyload.com Distribution: --- Created attachment 77447 --> https://bugs.winehq.org/attachment.cgi?id=77447 log Hello. when the game is started in fullscreen mode via wine wayland, the cursor position on the screen does not match where the game thinks it is.For example, to select a menu item you need to place the cursor in a different place than above it.The cursor cannot be moved to the bottom or right of the screen. This problem only occurs in a full screen game, if you start the game in window mode, everything works well. Enabling desktop emulation does not solve the problem. Unfortunately I can not add a screenshot (when creating the application goes into window mode and position of the cursor changes). I didn’t find a suitable topic and created a new one, sorry if this is a duplicate. info: game: bg3_dx11.exe run command: DISPLAY= wine bg3_dx11.exe wine: 9.22 wow64 NVIDIA GeForce RTX 3060 Driver : NVIDIA 565.57.1 DE: KDE Plasma 6.2.3 wayland vulkan: Vulkan Instance Version: 1.3.295 -- 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 57886] New: Context menus may be positioned using the wrong window when a window is reparented
by WineHQ Bugzilla Feb. 28, 2025

Feb. 28, 2025

https://bugs.winehq.org/show_bug.cgi?id=57886 Bug ID: 57886 Summary: Context menus may be positioned using the wrong window when a window is reparented Product: Wine Version: 9.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: irischer.posaunist(a)gmail.com Distribution: --- Created attachment 78112 --> https://bugs.winehq.org/attachment.cgi?id=78112 Log output while opening context menus in nested, reparented windows Context menus do not open in the expected location. Since 9.22, there was a mouse bug (#57603) affecting yabridge-host.exe, an X11 bridge which uses several reparented windows to show a VST/CLAP plugin running in Windows inside of a Linux DAW view: Mouse events (clicks, etc.) were being located using the entire screen, and the small plugin window was using this (fullscreen absolute) coordinate from its origin to remap each mouse event. In clearer terms, a plugin window dragged to the upper-left of the screen would function normally. Drag the window right by five centimeters, and mouse events would land five centimeters right of the cursor. While there have been patches and a merge request (https://gitlab.winehq.org/wine/wine/-/merge_requests/7429) in progress fixing the cursor offset, context menus now have the opposite behavior. Their position is calculated as an offset in the smaller plugin window, and then they are drawn with this offset from the absolute screen origin. Open a context menu while the plugin window is in the upper-left of the screen? It shows up in the correct place. Drag the window 5 centimeters right? The context menu will open 5 centimeters to the LEFT of the cursor. I am attaching a log where I open a menu, move the window to the left, and open the menu again. WINEDEBUG=+x11drv,+event,+cursor,+win,+msg,+message,+hid YABRIDGE_DEBUG_LEVEL=1+editor -- 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