wine-bugs

wine-bugs@winehq.org

1 participants
158748 discussions

[Bug 3930] HOMM/Deadlock shows black screen (game DLL calls SuspendThread inside WOM_OPEN winmm callback)
by WineHQ Bugzilla 02 Mar '25

02 Mar '25

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

02 Mar '25

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

02 Mar '25

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

02 Mar '25

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

01 Mar '25

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

01 Mar '25

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

01 Mar '25

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

01 Mar '25

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

01 Mar '25

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

01 Mar '25

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@16" export. The only place where WAIL32.DLL calls waveOutOpen() is in its function at address 0x20008f64, called from the "_AIL_waveOutOpen@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@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@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@0 and _AIL_waveOutOpen@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@0"); if (ail_startup != NULL) { ail_startup(); printf("called _AIL_startup@0\n"); } else printf("GetProcAddress() couldn't find _AIL_startup@0\n"); ail_waveOutOpen = GetProcAddress(dll, "_AIL_waveOutOpen@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@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 01 Mar '25

01 Mar '25

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

01 Mar '25

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

01 Mar '25

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

01 Mar '25

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

01 Mar '25

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 57891] New: Wine 10.2 can't find ntdll.so under linux.
by WineHQ Bugzilla 28 Feb '25

28 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=57891 Bug ID: 57891 Summary: Wine 10.2 can't find ntdll.so under linux. Product: Wine Version: 10.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: loader Assignee: wine-bugs(a)winehq.org Reporter: hibbsncc1701(a)gmail.com Distribution: --- Note: Not sure if this is a dupe of Bug 57874 or not given it's Linux and not a Mac.... After building wine with a custom --prefix, (E.x. configure --prefix=/opt/wine-git-build/wine_10.2), running wine from a home directory fails to find ntdll.so. :~$ wine explorer wine: could not load ntdll.so: /opt/wine-git-build/wine_10.2/bin/ntdll.so: cannot open shared object file: No such file or directory :~$ Running strace shows that no attempt is made to use the prefix's /lib directory at all for ntdll.so. It goes straight to using the wine binary's install directory, fails, then tries to read a wine symlink in the current working directory, before giving up. Given that it's blatantly ignoring FHS and using the wine binary's install directory as a root, I assumed there was something wrong with the given prefix argument. The generated Makefile has the exec_prefix variable emitted _before_ the prefix variable despite using it. I.e.: exec_prefix = ${prefix} prefix = /opt/wine-git-build/wine_10.2 I assume this won't work. Notably bindir and libdir are defined afterwards, and both use exec_prefix, which because I assume it's empty here, means they get a value of "/bin" and "/lib" respectively. I might be way off, but this bug occurs regardless of arch. I.e. Using a i686 or x86_64 build fails in the exact same way. -- 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 57893] New: Progress is not going until you move a mouse
by WineHQ Bugzilla 28 Feb '25

28 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=57893 Bug ID: 57893 Summary: Progress is not going until you move a mouse Product: Wine Version: 9.0 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: isakov-sl(a)bk.ru Created attachment 78123 --> https://bugs.winehq.org/attachment.cgi?id=78123 Progress bar This is a Game Editor which I had to launch under wine in the bug 57733. It is not really a wine-9.0, it is crossover-base v24.0.7 which is based on wine-9 but I don't know where it is better to report. The application is X64, DirectX9 using .Net 4.0 (dotnet48) and .Net Runtime (dotnet9). Not sure if other patches by CX or by me somehow influence. The is a new strange bug: At the program start it doesn't show toolbar waiting indefinite. But when I touch the mouse the interface became fullfilled. Then I choose to create a random map and wait. It requires 2 minutes in real windows but I wait very long with wine. Than I touch the mouse and the progress bar begin moving. To make the work I have to move mouse again and again. It looks like the game or the wine going to sleep every 2 seconds and wakes after I move the mouse. How it possible? I can't check with any other wine version or flavour as the my engine the only working for this game. The log contains very many shaders errors but I see nothing concerning the bug. -- 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 57516] New: Heroes of Might and Magic 4 campaign editor: can't cycle through hero's portrait with left mouse button
by WineHQ Bugzilla 28 Feb '25

28 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=57516 Bug ID: 57516 Summary: Heroes of Might and Magic 4 campaign editor: can't cycle through hero's portrait with left mouse button Product: Wine Version: 7.6 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: jacek(a)codeweavers.com Regression SHA1: d42888f07c6e3e491c99bb5c8b62b568264e990c Distribution: ArchLinux Created attachment 77550 --> https://bugs.winehq.org/attachment.cgi?id=77550 short video depicting the problem In the campaign editor for HoMM4 I can't use the left mouse button to select from the available portraits because only 2 of images can be selected: the first one and the last one.That is when clicking on the up and down arrows with the mouse button, next to the hero's portrait. However if I use the mouse wheel to cycle through the available images then any of the available portraits can be selected. The last Wine version where the mouse button still worked: Wine-7.5. This is the commit where the problem first occured: commit d42888f07c6e3e491c99bb5c8b62b568264e990c user32: Use NtUserMessageCall for SendMessageA implementation. Plain terminal output doesn't show anything related. Demo version is not available. I tested with the GOG.com version of the game. Still present in Wine-10.0-rc1. -- 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 57886] New: Context menus may be positioned using the wrong window when a window is reparented
by WineHQ Bugzilla 28 Feb '25

28 Feb '25

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

[Bug 57758] New: Starcraft Brood War regression on Wine 10
by WineHQ Bugzilla 28 Feb '25

28 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=57758 Bug ID: 57758 Summary: Starcraft Brood War regression on Wine 10 Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: louis(a)qdcec.co.za Distribution: --- Running on Fedora 40 using packages wine-10.0-1.fc40.x86_64 and wine-10.0-0.7rc4.fc40.x86_64 I am unable to successfully run a previously "platinum" running package: StarCraft / Brood Wars by Blizzard. If I downgrade to wine-9.1-1.fc40.x86_64 the application works once again. I also have a very simple tool that decodes Cisco level 7 ascii passwords - useful when I forget what I assigned an account - that works on version 9 but not 10. (I've tried to file this regression a few days ago, but cannot find it anywhere on "My Bugs" or anywhere on this site. If I have inadvertently created a duplicate, please forgive me.) -- 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 15

[Bug 55399] New: .NET 4.8 application cannot download (by browser launch) from the Internet
by WineHQ Bugzilla 28 Feb '25

28 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=55399 Bug ID: 55399 Summary: .NET 4.8 application cannot download (by browser launch) from the Internet Product: Wine Version: 8.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: brian(a)interlinx.bc.ca Distribution: --- Created attachment 74958 --> https://bugs.winehq.org/attachment.cgi?id=74958 Screenshot of stack trace in error dialog I am trying to use an application called GenuTax (https://www.genutax.ca/Home/Download) with .NET 4.8 and Wine 8.12. Once I created a 32-bit prefix and installed .NET 4.8 with winetricks the application installs and runs successfully. I was optimistic at this point. At some point though the application wants to launch a browser to a certain URL to log into an information portal. At that point it fails with a System.Runtime.InteropServices.COMException. I have attached a screenshot (sorry for a screenshot, but I was unable to copy the text from the dialog to be able to paste here). There is a working iexplore.exe in this installation, so there should be a browser for .NET to use. -- 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 8

[Bug 57890] New: 3DMark11 is not working
by WineHQ Bugzilla 27 Feb '25

27 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=57890 Bug ID: 57890 Summary: 3DMark11 is not working Product: Wine Version: 10.0 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: isakov-sl(a)bk.ru Created attachment 78118 --> https://bugs.winehq.org/attachment.cgi?id=78118 Log of the fail Unlike bug 42119 I can't start this DirectX11 benchmark in the same wine. The application started with empty windows. The last line in the log ~~~~ 0024:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0000000001233510, format DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, flags 0x3, mode_count 000000000011FC58, modes 00000000009908F0 partial stub! ~~~~ So the problem is in dxgi? -- 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 57603] New: Interacting with yabridge plugins after moving the window broken
by WineHQ Bugzilla 27 Feb '25

27 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=57603 Bug ID: 57603 Summary: Interacting with yabridge plugins after moving the window broken Product: Wine Version: 9.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mbarriolinares(a)gmail.com Distribution: --- Issue: When opening a plugin window via yabridge in carla patchbay or ardour8, the mouse input is registered at an incorrect position. After moving the plugin window, mouse interaction stops working entirely, making the interface unusable. Steps to Reproduce: 1. Open a yabridge plugin window in carla patchbay or ardour. 2. Attempt to interact with the plugin using the mouse. 3. Observe that clicks and movements are registered at incorrect positions. 4. Move the plugin window. 5. Try interacting with the plugin again. 6. Observe that the mouse no longer interacts with the plugin. Additional info: wine version: 9.22-1 yabridge version: 5.1.1-1 xorg-server version: 21.1.15-1 ardour 8.10 carla 2.5.9-1 --- Dwngrading to wine 9.21 fixed the issue -- 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 23

[Bug 39120] New: Right-clicking on IE 8 causes a crash
by wine-bugs＠winehq.org 27 Feb '25

27 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=39120 Bug ID: 39120 Summary: Right-clicking on IE 8 causes a crash Product: Wine Version: 1.7.49 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tblodt(a)icloud.com Created attachment 52128 --> https://bugs.winehq.org/attachment.cgi?id=52128 backtrace When you install IE 8 (either using winetricks, or by creating a bunch of dll overrides and running the installer), run it, and right click anywhere on a web page, IE crashes. Backtrace is attached. -- 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 4

[Bug 46201] New: Xenia fails to initialize graphics pipeline
by wine-bugs＠winehq.org 27 Feb '25

27 Feb '25

https://bugs.winehq.org/show_bug.cgi?id=46201 Bug ID: 46201 Summary: Xenia fails to initialize graphics pipeline Product: vkd3d Version: 1.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vkd3d Assignee: wine-bugs(a)winehq.org Reporter: chridye(a)gmail.com Distribution: --- Created attachment 62874 --> https://bugs.winehq.org/attachment.cgi?id=62874 backtrace from today (nov 26 2018) the latest build of xenia can be found at https://ci.appveyor.com/api/projects/benvanik/xenia/artifacts/xenia-d3d12.z… I got this error in the terminal window: vkd3d_dxbc_compiler_get_register_info: Assertion `reg->idx[0].offset < compiler->temp_count' failed. A quick search on google says this was some graceful way of dealing with unimplemented registers. That change was proposed on Jan 9. http://wine.1045685.n8.nabble.com/PATCH-vkd3d-1-7-libs-vkd3d-shader-Handle-… The version of vkd3d I'm using was built from source using a commit from today (nov 26). I'm on ubuntu 18.10 without vkd3d installed via package manager. wine was ran in 64-bit mode and was also built from source today after doing a `git pull`. The exact command I ran was `wine64 xenia.exe.` I have attached the back trace. -- 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 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs