http://bugs.winehq.org/show_bug.cgi?id=58749
Bug ID: 58749
Summary: Delayed startup of wine processes in Wine-10.16
Product: Wine
Version: 10.16
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: regression, source
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: z.figura12(a)gmail.com
Regression SHA1: 7bb835b3482de5e66515b5a0bd8dce8dc9844c93
Distribution: ArchLinux
There is a noticeable delay (8-10s) when starting any applications in
Wine-10.16, e.g. wine regedit. No disk activity or high cpu usage from
wineserver can be seen with htop, there is just a delay before the actual
program appears on the screen.
Reproduced with 32bit-only, shared WOW and the new WOW64 prefixes alike.
Started happening after
commit 7bb835b3482de5e66515b5a0bd8dce8dc9844c93
ntdll: Use in-process synchronization objects.
The issue doesn't exist with the previous commit or when the ntsync kernel
module is not loaded.
I'm using Arch Linux and tested with both the current official kernel on Arch
(6.16.10-zen1-1-zen) and with kernel-6.17-cachyos-bore.
--
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=58852
Bug ID: 58852
Summary: Minimised applications are restored with -4 vertical
pixels (redux).
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: win32u
Assignee: wine-bugs(a)winehq.org
Reporter: chiitoo(a)gentoo.org
Regression SHA1: be60f77909fc9ce2c9b6f1abd005e3b4aabaafec
Distribution: Gentoo
It seems be60f77909f [1] is the return of the bug 57577, with anything so far I
have tried, including the Wine notepad, reducing in vertical size by 4 pixels
when restored.
Only tested with KWin-X11 so far.
Thank you!
1.
https://gitlab.winehq.org/wine/wine/-/commit/be60f77909fc9ce2c9b6f1abd005e3…
2. https://bugs.winehq.org/show_bug.cgi?id=57577
--
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=58828
Bug ID: 58828
Summary: Configure (build) fails since commit db2e157, if
autoreconf needs to be applied before
Product: Wine
Version: 10.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: tools
Assignee: wine-bugs(a)winehq.org
Reporter: luti(a)gmx.net
Distribution: ---
Build of wine 10.17 fails on Rocky Linux 9.6 (autoconf-2.69-39.el9.noarch), if
autoreconf needs to be applied (as wine-staging build for instance).
After autoreconf, configure fails with:
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.."
"./../.."
Previous versions were built fine, as well as 10.17 without autoreconf, or wine
10.17 with commit db2e157
(https://gitlab.winehq.org/wine/wine/-/commit/db2e157c68d5b1ced965e2ac90ecb9…)
reverted.
It may be autoconf issue in fact (related to this:
https://www.mail-archive.com/autoconf-patches@gnu.org/msg06599.html ?), but as
RHEL 9 is not the only major distribution still shipped with autoconf 2.69 (I
guess), this should probably be considered?
--
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=58795
Bug ID: 58795
Summary: The Witcher 2 crashes on start
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: julliard(a)winehq.org
Regression SHA1: ad9dfe8bcc0ad048dc044694969e13235caadf46
Distribution: ArchLinux
Created attachment 79440
--> http://bugs.winehq.org/attachment.cgi?id=79440
terminal output
Starting The Witcher 2 (GOG) using current git HEAD
(wine-10.16-212-g6124fea1dde) results in an immediate crash. Couldn't get a
backtrace.
Present in 32bit-only, shared WOW and WOW64 prefixes alike.
The game starts properly in Wine-10.16, the crash occurs since
commit ad9dfe8bcc0ad048dc044694969e13235caadf46
ntdll: Use the export name if any to find the corresponding builtin.
There is no demo version available. Let me know if you need debug logs.
wine-10.16-212-g6124fea1dde
--
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=58752
Bug ID: 58752
Summary: assembly:Z:\usr\share\wine\mono\wine-mono-10.2.0\lib\m
ono\4.5\mscorlib.dll type:DllNotFoundException
Product: Framework Mono
Version: 6.12.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: mono
Assignee: wine-bugs(a)winehq.org
Reporter: schusr(a)gmail.com
CC: madewokherd(a)gmail.com
Distribution: ---
Installed a 64 bit application that uses System.Media.SoundPlayer.
When starting the application fails with DllNotFoundException but the file is
present on the system.
dir Z:\usr\share\wine\mono\wine-mono-10.2.0\lib\mono\4.5\mscorlib.dll
Volume in drive Z is fedora
Volume Serial Number is 4979-a18d
Directory of Z:\usr\share\wine\mono\wine-mono-10.2.0\lib\mono\4.5
08/28/2025 07:00 PM 4,677,632 mscorlib.dll
1 file 4,677,632 bytes
0 directories 486,067,679,232 bytes free
Running wine from Fedora 42
002c:fixme:winediag:loader_init wine-staging 10.15 is a testing version
containing experimental patches.
002c:fixme:winediag:loader_init Please mention your exact version when filing
bug reports on winehq.org.
rpm -qa | grep mono-core
mono-core-6.12.0-19.fc42.x86_64
--
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=57376
Bug ID: 57376
Summary: Permission denied vs No such file or directory when
opening folders with trailing backslash
Product: Wine
Version: 9.20
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: alex+winehq(a)cogarr.net
Distribution: ---
Created attachment 77346
--> https://bugs.winehq.org/attachment.cgi?id=77346
A zip file containing a minimal example.c, and log files wine.txt and win.txt
There's a subtle difference when calling fopen(3) between Wine configured for
win10, and real Windows 10. When attempting to open a folder (e.g. AppData),
wine correctly sets errno to 13 (Permission denied), but when opening a folder
with a trailing backslash(e.g. AppData\), Windows sets errno to 2 (No such file
or directory) while Wine sets it to 13 (Permission denied). The attached
example.c shows this behavior. I compile it with mingw32-x86_64-gcc and run it
through cmd.exe with my current directory set to C:\users\user on Wine and get
wine.txt, then run it on Windows 10, and get win.txt (COPY a.exe C:\users\user
&& C: && cd users\user && a.exe > win[e].txt)
This behavior exists on current Wine 9.20 and has existed since at least Wine
9.0 .
I have tried the winecfg versions: win10, win11, win8.1, vista, and all seem to
work the same.
My actual use case is running the Luarocks package
manager(https://github.com/luarocks/luarocks) compiled for Windows on Wine for
testing. Luarocks uses this behavior to check if something is a folder
(https://github.com/luarocks/luarocks/blob/master/src/luarocks/fs/win32.lua#…).
--
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=58331
Bug ID: 58331
Summary: Wait cursor does not display
Product: Wine
Version: 9.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: win32u
Assignee: wine-bugs(a)winehq.org
Reporter: rikul(a)inbox.ru
Distribution: ---
Created attachment 78705
--> http://bugs.winehq.org/attachment.cgi?id=78705
Example
Starting from Wine version 9.0, the waiting cursor no longer appears when
attempting to set it to indicate a long-running operation in MFC applications
or other programs. The issue appears to have started after the commit on June
13, 2023.
Steps to Reproduce:
1. Run the attached simple MFC application.
2. Click the button "Start Long Operation"
Expected Result:
The waiting cursor should appear for the duration of the 3-second sleep.
Actual Result:
The waiting cursor does not appear during the Sleep call. The cursor remains
the default arrow.
Example Application:
The example application has been attached. It uses the most basic
implementation of the CWaitCursor class, as described in the official Microsoft
documentation:
https://learn.microsoft.com/en-us/cpp/mfc/reference/cwaitcursor-class?view=…
Regression Commit:
The issue seems to have started with the commits made on June 13, 2023:
https://github.com/wine-mirror/wine/commits/master/dlls?author=rbernon&sinc…
Notes:
This issue does not occur in Windows, where the waiting cursor appears as
expected.
Environment:
Wine version: 9.0+ (possibly Wine 8.x, but not 8.0)
Operating System: RHEL 7.9, RHEL 8.10
--
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=48787
Bug ID: 48787
Summary: WineD3D C&C Generals Zero Hour takes a lot time to
load or maximize
Product: vkd3d
Version: 1.1
Hardware: x86-64
OS: Windows
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: vkd3d
Assignee: wine-bugs(a)winehq.org
Reporter: moceap(a)hotmail.com
As you know (C&C Generals Zero Hour) is an old game. And it use DirectX 8.1.
These type of games don't stable in current Windows' versions.
So WineD3D used to valid run them on Windows.
Using: C&C Generals Zero Hour (Last Version 1.04)
Windows 10 (1909)
WineD3D (From Wine 5.4)https://fdossena.com/?p=wined3d/index.frag
Both (Intel and AMD) cards tested
Expected Result: Works fine with high speed.
Actual Result: Very long time on maximize the game after minimize or switch to
another application
Long time on loading the game (Not happen on MS DirectX)
--
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=55981
Bug ID: 55981
Summary: Dragon Age Origins: Runs slowly when using the
experimental wow64 mode
Product: Wine
Version: 8.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: berillions(a)gmail.com
Distribution: ---
Created attachment 75572
--> https://bugs.winehq.org/attachment.cgi?id=75572
Dragon Age : Origins main menu with new wow64 + OpenGL renderer
Dragon Age : Origins works with the new wow64 experimental mode but it's very
slowly and unplayable. This bug affect "Beyond Good & Evil" too.
Use DXVK fix this issue so something wrong with new wow64 + opengl renderer ?
--
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=58839
Bug ID: 58839
Summary: kernel32.timeGetTime error when enabling speedhack in
Cheat Engine
Product: Wine
Version: 10.17
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: alexhenrie24(a)gmail.com
Distribution: ---
Steps to reproduce:
1. Compile Wine with https://gitlab.winehq.org/wine/wine/-/merge_requests/9256
to work around Bug 58837
2. Run `wine CheatEngine76.exe` and when prompted to install additional
software, click "Skip All"
3. Run `wine 'C:\Program Files\Cheat Engine\Cheat Engine.exe'`
4. Click File, then Open Process, then double-click Cheat Engine
5. On the right side of the window, click the "Enable Speedhack" checkbox
An error dialog appears that says "Failure hooking
kernel32.gettickcount64:Error in line 77 (kernel32.timeGetTime:) :This address
specifier is not valid"
$ sha256sum CheatEngine76.exe
7f57ab6697f2d27604be2d63d03768612e6022a1c3b708507af8fb23d461428a
--
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.