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.
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.
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.
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.
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.
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.
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.
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.
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.
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.