https://bugs.winehq.org/show_bug.cgi?id=53121
Bug ID: 53121
Summary: IrfanView: In full screen mode the image title is not
correctly repainted when switching between images
Product: Wine
Version: 7.9
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 72576
--> https://bugs.winehq.org/attachment.cgi?id=72576
Example
Steps to reproduce:
1. Download IrfanView
2. File -> Open an image file (which matches or exceeds your display
resolution)
3. Press Enter (goes in full screen mode)
4. Press right arrow or left arrow (alternatively "Space" and "Back Space") to
browse through images forward or backward.
The area where the image path and name are being rendered starts to look bad
(i.e. it's not correctly repainted). It's in the left top corner.
The example 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.
http://bugs.winehq.org/show_bug.cgi?id=58196
Bug ID: 58196
Summary: d3d9:device WM_WINDOWPOSCHANGED test fails
consistently on Linux since Wine 10.5
Product: Wine
Version: 10.4
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: alexhenrie24(a)gmail.com
Distribution: ---
$ ./wine dlls/d3d9/tests/x86_64-windows/d3d9_test.exe device 2>&1 | grep
WM_WINDOWPOSCHANGED
device.c:4467: Test failed: Received WM_WINDOWPOSCHANGED but did not expect it,
i=0.
`git bisect` says:
3ae66c75cf443c0be403d9fe4e4da3c19b3ad9a8 is the first bad commit
commit 3ae66c75cf443c0be403d9fe4e4da3c19b3ad9a8
Author: Rémi Bernon <rbernon(a)codeweavers.com>
AuthorDate: Sat Mar 29 09:32:27 2025 +0100
Commit: Alexandre Julliard <julliard(a)winehq.org>
CommitDate: Wed Apr 2 22:25:37 2025 +0200
winex11: Use _NET_ACTIVE_WINDOW to request/track window activation.
When supported, instead of tracking window focus only.
dlls/user32/tests/win.c | 2 +-
dlls/winex11.drv/event.c | 32 ++++++++++++++++++++------------
dlls/winex11.drv/keyboard.c | 2 +-
dlls/winex11.drv/mouse.c | 2 +-
dlls/winex11.drv/window.c | 86
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------
dlls/winex11.drv/x11drv.h | 4 +++-
6 files changed, 102 insertions(+), 26 deletions(-)
--
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=42284
Bug ID: 42284
Summary: Enable using Wine with Wayland and without X on Linux
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: shtetldik(a)gmail.com
Distribution: ---
Currently, Wine on Linux is strongly dependent on X, and when used with the
desktop environment with new Wayland display server, Wine is forced to run
through XWayland, which so far remains a poor experience.
The whole Linux desktop is now strongly pushing the switch from X to Wayland,
and many major applications are now in the process of enabling this switch.
Is there some plan for such effort in Wine? Is it even feasible? I couldn't
find any bugs opened for it, so I'm opening one here to track this.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=58106
Bug ID: 58106
Summary: PrintDialog (System.Windows.Controls): does not set
PageRange and PageRangeSelection
Product: Wine
Version: 10.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: igor.ivanov.0501(a)gmail.com
Distribution: ---
Created attachment 78364
--> http://bugs.winehq.org/attachment.cgi?id=78364
Sample App for VS22 with executable
After opening PrintDialog and manually setting PageRange returned result will
be unchanged. See sample in attachment
--
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.
http://bugs.winehq.org/show_bug.cgi?id=58150
Bug ID: 58150
Summary: MusicBee: Inconsistent directory monitoring
performance on SMB mounts via CIFS compared to native
filesystem (Linux)/SMB mount (Windows)
Product: Wine-staging
Version: 10.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: v_winebugs(a)outlook.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
MusicBee has a feature to continuously monitor the library's directory for any
new files that have ended up in the library. On Windows, this is pretty
reliable both on native NTFS as well as network drives via SMB. On Linux,
however, only the native drive seems to be reliable.
With my SMB drive mounted via Linux's CIFS driver, even though performance is
good on WINE's built-in file picker as well as KDE Dolphin, the continuous
monitor on MusicBee seems to be lacking in performance in comparison to native
on Linux and the network drive on Windows. Having 10 albums being scanned and
imported into the inbox can take up to 2 minutes if at all (MusicBee will
sometimes work, but most times not, you have to restart it to get it to see the
files where you don't need to on Windows), while it's basically instant on
Windows.
Also, sometimes MusicBee's monitor will immediately import the tracks, then
think the tracks are gone. Doesn't seem to happen with native drives on Linux,
neither does it happen with MusicBee on an SMB setup in Windows.
OS is Bazzite 42, WINE Staging 10.4 layered on top, MusicBee version 3.6.9202.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=10941
Summary: Wine does not print in a newly allocated console window
Product: Wine
Version: 0.9.52.
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-console
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mail2benny(a)gmail.com
Created an attachment (id=9867)
--> (http://bugs.winehq.org/attachment.cgi?id=9867)
The binary which recreates the bug
Wine does not print in a newly allocated console window using the function
FreeConsole(); and AllocConsole();
I've written a program which recreates the bug. I'll post the binary and the
source.
(compiled on Dev-C++ 4.9.9.2, in Wine)
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58198
Bug ID: 58198
Summary: Wine missing WH_JOURNALPLAYBACK, required by VB
SendKeys
Product: Wine
Version: 8.0
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user16
Assignee: wine-bugs(a)winehq.org
Reporter: jxvhulzowyrobfwwze(a)nbmbb.com
Distribution: ---
Wine doesn’t implement WH_JOURNALPLAYBACK, which is required by the Visual
Basic SendKeys function. This makes the game “Mordor: The Depths of Dejenol”
unplayable after entering the dungeon.
I’ve confirmed with 32-bit Wine 8 and 16-bit VB3, but the logic seems unchanged
in more recent Wine (and VB) versions. Microsoft eventually released a VB6
runtime that reimplemented SendKeys using SendInput instead of
WH_JOURNALPLAYBACK, but that only fixes VB6 binaries.
https://archives.miloush.net/michkap/archive/2007/09/10/4850360.htmlhttps://web.archive.org/web/20130615064311/http://blogs.msdn.com/b/michkap/…
The story gets worse for programs that invoke DoEvents after SendKeys. Since
DoEvents “first clears all pending keystrokes from the SendKeys function,” it
enters an endless loop waiting for PeekMessage to return the expected
WH_JOURNALPLAYBACK messages. CPU usage goes to 100%, and it’s easy to run out
of stack space if DoEvents is invoked repeatedly.
https://nolongerset.com/how-doevents-works/
Thankfully, running with WINEDEBUG=warn emits a clear message,
“SetWindowsHookEx16 hook type 1 broken in Win16” pointing us to
https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/user.exe16/hook.c
This game is particularly creative, using SendKeys as some sort of input
filter. Many keyboard and mouse inputs are apparently translated to SendKeys
calls. I don’t fully understand the logic, except that the game is unplayable
without it.
I can’t say whether it’s worth fixing this or not. At the very least, it’s
helpful to know why this game doesn’t work, without having to keep trying each
new Wine release.
The free demo of “Mordor: The Depths of Dejenol” can be downloaded from
https://www.decklinsdemise.com/mordor.htm
--
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.