March 2025 - Wine-Bugs - list.winehq.org

[Bug 40495] New: Impossible to function at 64 bit on FreeBSD
by wine-bugs＠winehq.org March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=40495 Bug ID: 40495 Summary: Impossible to function at 64 bit on FreeBSD Product: Wine Version: 1.7.46 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexandrosperdikomatis(a)gmail.com Created attachment 54269 --> https://bugs.winehq.org/attachment.cgi?id=54269 the regular backtrace report I've compiled wine64 several times in many ways at FreeBSD. 32 bit version always works fine. This is the port emulators/wine-devel from RELEASE ports collection at FreeBSD 10.2 Application tried was Wow-64.exe I am really disappointed with wine64 at FreeBSD. On Linux it flies. -- 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 2

[Bug 57788] New: "You have been unsubscribed from the wine-bugs mailing list"
by WineHQ Bugzilla March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=57788 Bug ID: 57788 Summary: "You have been unsubscribed from the wine-bugs mailing list" Product: WineHQ Bugzilla Version: 3.2.3 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com CC: austinenglish(a)gmail.com, jnewman(a)codeweavers.com Distribution: --- Twice now, I've gotten an email that I've been unsubscribed from the wine-bugs mailing list (I've been subscribed for years without issue). The first time was January 22, and again just now. @Newman, is this related to recent site upgrades? -- 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

[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 #88 from zebra2745(a)vibzi.net --- > That doesn't work, because GetCurrentThread() only returns a pseudo handle, > "a special constant that is interpreted as the current thread handle" > (MSDN). I think we have to compare the globally unique thread IDs to be sure: https://www.codeproject.com/Tips/5350589/The-Current-Thread-Handle says: > What to do when you want to use the current thread handle > This tip shows a side effect of GetCurrentThread and explains what to do when you need to avoid that. > Introduction > When you need to get a handle to the current thread, you can use > GetCurrentThread which gives you a pseudo handle which you don't need to close > because it is not a real reference counted handle. This is mentioned clearly in > the documentation. However, I recently bumped my head against this. I wanted to > share it so that others can avoid having to chase this down. > My Headbump > Consider the following example: > ------------------------------ snip ------------------------------ DWORD worker(void* ctx) { std::cout << "Thread id: " << GetThreadId((HANDLE)ctx) << std::endl; return 0; } int main() { HANDLE hMainThread = GetCurrentThread(); std::cout << "Thread id: " << GetThreadId(hMainThread) << std::endl; HANDLE hThread = CreateThread(NULL, 0, worker, hMainThread, 0, NULL); WaitForSingleObject(hThread, INFINITE); } > ------------------------------ snip ------------------------------ > This is what happens: > Thread id: 44068 > Thread id: 36376 > Without thinking, I had assumed that the pseudo handle was just a weak copy of > the actual handle (a non reference counted copy of the current handle), and I > could reference it in a worker thread. Instead, it is a special constant that > literally means 'when this handle value is supplied, use the current thread'. > And if you pass that special value to another thread, then that value will > translate to the thread handle of 'that' thread. > If you read the documentation, then this is exactly what it says. Only I > didn't stop to think about what that actually meant. > Getting the Real Thread Handle > If you want to get a real handle that you can pass to another thread, do this: > ------------------------------ snip ------------------------------ HANDLE hMainThread = NULL; if (!DuplicateHandle( GetCurrentProcess(), GetCurrentThread(), GetCurrentProcess(), &hMainThread, 0, FALSE, DUPLICATE_SAME_ACCESS)) { cout << "Error " << GetLastError() << " cannot duplicate main handle." << endl; return GetLastError(); } > ------------------------------ snip ------------------------------ > Of course, when you do this, you get a HANDLE value that you do need to close > when you no longer need it. -- 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 #87 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- (In reply to Dmitry Timoshkov from comment #86) > Created attachment 78138 [details] > patch > > Something like this may work. That doesn't work, because GetCurrentThread() only returns a pseudo handle, "a special constant that is interpreted as the current thread handle" (MSDN). I think we have to compare the globally unique thread IDs to be sure: ---snip--- if (GetCurrentThreadId() == GetThreadId(thread) && (GetVersion() & 0x80000000)) return 0; ---snip--- That fixes all the tests, but doesn't fully fix the game: it no longer deadlocks and even plays music (it was silently frozen before), but shows badly corrupted video (bottom ~2/3 of the screen are black, and the top 1/3 has randomly colored pixels), which makes it completely unplayable. Running it with "wine HEROES.EXE /s0" (which disables all sound) gets the graphics fully functional. This however, seems to be a separate issue, probably a regression as this WINMM fix was enough in earlier Wine versions, but now isn't. -- 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 #86 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- Created attachment 78138 --> https://bugs.winehq.org/attachment.cgi?id=78138 patch Something like this may work. -- 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 #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 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