March 2025 - 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 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=3930 --- Comment #85 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Damjan Jovanovic from comment #84) > (In reply to Dmitry Timoshkov from comment #83) > > Could SuspendThread() fail in win9x mode when called for the same thread? > > Yes, SuspendThread(GetCurrentThread()): > - deadlocks on all Windows versions, even 95, when running as is. > - returns 0 instead, when newer Windows versions emulate Windows 95 or 98/ME. It would be helpful to know what last error is set to for the failing case. > What should Wine do? Add a check to SuspendThread() and fail in the win9x mode? -- 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 42308] New: LTspice XVII: some checkboxes not shown or being overlapped by labels
by wine-bugs＠winehq.org March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=42308 Bug ID: 42308 Summary: LTspice XVII: some checkboxes not shown or being overlapped by labels Product: Wine Version: 2.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: Rakusan2(a)gmail.com Distribution: --- Created attachment 57042 --> https://bugs.winehq.org/attachment.cgi?id=57042 Missing checkboxes and their labels bellow the textboxes In LTspice XVII when opening "Edit Simulation cmd" the checkboxes and their labels are not shown. After switching tabs the labels appear but some slightly overlap their checkbox This problem does not occur in native windows -- 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 9

[Bug 57898] New: Witcher 3 choppy sound
by WineHQ Bugzilla March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=57898 Bug ID: 57898 Summary: Witcher 3 choppy sound Product: Wine Version: 10.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: BattyRoy(a)protonmail.com Distribution: --- Hello, I got (again :( ) glitchy, choppy sound in The Witcher 3 Next Gen game. Wine 10.1 introduced this regression. I use wine-wow64 on arch. I tried wine 10.2, latest wine-git and the issue remains. The only solution of the problem is downgrade to wine 10.0, then everything is OK. I have older intel cpu 3.5Ghz (2/2), there was same sound problem a few years before. Did someone fiddle with wine/cpu threads recently?. Could you please check it. Have a good day. -- 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 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=3930 --- Comment #84 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- (In reply to Dmitry Timoshkov from comment #83) > Could SuspendThread() fail in win9x mode when called for the same thread? Yes, SuspendThread(GetCurrentThread()): - deadlocks on all Windows versions, even 95, when running as is. - returns 0 instead, when newer Windows versions emulate Windows 95 or 98/ME. What should Wine do? -- 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 57897] New: Chessbase 11 media plays inside vlc rather than application
by WineHQ Bugzilla March 1, 2025

March 1, 2025

https://bugs.winehq.org/show_bug.cgi?id=57897 Bug ID: 57897 Summary: Chessbase 11 media plays inside vlc rather than application 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: dav75uk(a)yahoo.co.uk Distribution: --- Media should open up in Chessbase's media player, so that the video syncs up with the board which is moved along with the video. Without that the media is mostly useless. Unfortunately a new vlc Window opens and media is played there. This affects Chessbase 11, but maybe other versions. -- 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 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 #83 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Damjan Jovanovic from comment #82) > (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. Could SuspendThread() fail in win9x mode when called for the same thread? -- 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 #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