https://bugs.winehq.org/show_bug.cgi?id=55200
Bug ID: 55200
Summary: MSVC cl.exe misbehaving (buggy/inconsistent behaviour)
wrt include paths since "ntdll: Default to Windows 10"
Product: Wine
Version: 8.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: martin(a)martin.st
Regression SHA1: 69154f0329aec4fb64886a0689da198b5323dcde
Distribution: ---
Background: I package MSVC with Wine wrapping, so that people can compile
software using MSVC on Unix systems - see
https://github.com/mstorsjo/msvc-wine.
Since Wine 8.1, specifically commit 69154f0329aec4fb64886a0689da198b5323dcde
"ntdll: Default to Windows 10", cl.exe in Wine started misbehaving with respect
to how it finds headers in some include paths. The misbehaviour isn't entirely
consistent and only appears in some fairly specific cases. (When compiling a
project of the size of LLVM, with ~3000 compiled translation units, the bug
appears in 3 of these translation units.)
I've managed to reproduce the situation with a fairly minimal testcase. To
reproduce, first install a fresh version of msvc-wine:
$ git clone https://github.com/mstorsjo/msvc-wine
$ cd msvc-wine
$ ./vsdownload.py --dest $HOME/msvc2022-17.6 --accept-license
$ ./install.sh $HOME/msvc2022-17.6
Then set up a minimal mock source project structure:
$ mkdir -p msvc-include-bug/subdir
$ touch msvc-include-bug/subdir/header.h
$ echo '#include "subdir/header.h"' > msvc-include-bug/subdir/file.cpp
Now test preprocessing file.cpp to see that it manages to find the header.
Bypass the msvc-wine wrapper scripts and call it with wine manually:
$ . $HOME/msvc2022-17.6/bin/x64/msvcenv.sh # Set up the
INCLUDE/LIB/WINEDLLOVERRIDES env vars as necessary
$ WINEDEBUG=-all wine64
$HOME/msvc2022-17.6/vc/tools/msvc/14.36.32532/bin/Hostx64/x64/cl.exe -P
-Fipreproc.cpp -I$(pwd)/msvc-include-bug/subdir -I$(pwd)/msvc-include-bug
z:$(pwd)/msvc-include-bug/subdir/file.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32532 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
file.cpp
This runs successfully, as reference example. Now update file.cpp to include
<corecrt_wio.h> before "subdir/header.h":
$ echo '#include <corecrt_wio.h>' > msvc-include-bug/subdir/file.cpp
$ echo '#include "subdir/header.h"' >> msvc-include-bug/subdir/file.cpp
Rerun the same compilation command:
$ . $HOME/msvc2022-17.6/bin/x64/msvcenv.sh
$ WINEDEBUG=-all wine64
$HOME/msvc2022-17.6/vc/tools/msvc/14.36.32532/bin/Hostx64/x64/cl.exe -P
-Fipreproc.cpp -I$(pwd)/msvc-include-bug/subdir -I$(pwd)/msvc-include-bug
z:$(pwd)/msvc-include-bug/subdir/file.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32532 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
file.cpp
z:/home/martin/msvc-include-bug/subdir/file.cpp(2): fatal error C1083: Cannot
open include file: 'subdir/header.h': No such file or directory
For some unknown reason, the extra set of headers included by <corecrt_wio.h>
make cl.exe no longer find "subdir/header.h" even though
-I$(pwd)/msvc-include-bug is passed to the compiler. The bug only appears when
both $(pwd)/msvc-include-bug and $(pwd)/msvc-include-bug/subdir are added to
the include path.
$(pwd) expanding to an absolute unix path should be resolvable as an
drive-relative (implicitly relative to z:) within Wine.
Now if we clarify the include paths, that previously were set up as
-I$(pwd)/... into fully absolute windows paths as -Iz:$(pwd)/..., then the test
succeeds again:
$ WINEDEBUG=-all wine64
$HOME/msvc2022-17.6/vc/tools/msvc/14.36.32532/bin/Hostx64/x64/cl.exe -P
-Fipreproc.cpp -Iz:$(pwd)/msvc-include-bug/subdir -Iz:$(pwd)/msvc-include-bug
z:$(pwd)/msvc-include-bug/subdir/file.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32532 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
file.cpp
Before the relevant Wine commit, this bug didn't appear at all in this case.
It's probably easy to work around this issue within msvc-wine by rewriting -I
arguments with absolute paths into Windows absolute paths like z:/... - but
it's curious why this is needed now when it wasn't needed before, and MSVC
cl.exe itself is acting very inconsistent here - it's only needed in this very
precise setup.
(For context, for future self: When compiling LLVM, this bug currently hits
three files under llvm/lib/Target/AArch64/MCTargetDesc -
AArch64WinCOFFObjectWriter.cpp, AArch64MCTargetDesc.cpp and
AArch64TargetStreamer.cpp.)
--
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=54135
Bug ID: 54135
Summary: JGlossator v5.0: Hovering textboxes not displaying
Product: Wine
Version: 8.0-rc1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: mshtml
Assignee: wine-bugs(a)winehq.org
Reporter: metcalsr(a)gmail.com
Distribution: ---
Created attachment 73666
--> https://bugs.winehq.org/attachment.cgi?id=73666
+mshtml
Application features hover-over translations for text in the search box. This
is not only an important QoL feature, but often provides alternative
translations which aid significantly in understanding the text. These hovering
boxes break under wine.
--
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=55024
Bug ID: 55024
Summary: Sims 4 Studio window flickering
Product: Wine
Version: 8.9
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ryu.ketsueki(a)outlook.com
Distribution: ---
This is something that was happening before for a while now but it was
tolerable. Now it's unusable.
Sims 4 Studio updated to the (Star) release, as in the 3.2.0.6 and it's
actually usable now. The application doesn't freeze when trying to render
anything 3D, which was apparently an issue on Sims 4 Studio itself, as even in
a virtual machine, it had the exact same error. Could only get around it by a
dual boot with Windows.
Not anymore. Sims 4 Studio runs relatively well and I can create and modify
game packages normally. That was until recently, when the flickering got so
much worse.
I'll explain what is happening. The window would hang frames for a bit and
flicker them instead of completely update to the newest frame. Now it doesn't
hang anymore. Instead, the window appears completely black, except when
hovering over buttons or menus, when the window flash its content for a split
second and goes black again. This is still on top of the flickering of before,
so it still hangs frames but still goes black constantly, making the
application unusable.
Now, to my knowledge, Sims 4 Studio requires .NET 6.0 to launch at all. I had
to install it to make it work, even when it was usable. Maybe this is related
Mono or .NET itself, I don't know.
I did observe a behavior that may be connected to what is going on. When the
window is flashing black, the center of the window has a square showing the
correct content but it's following the Windows 10/11 spinning wheel, so only
this loading wheel shows correctly. The behavior persists even when the wheel
is gone
--
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=55193
Bug ID: 55193
Summary: user32:sysparams - test_WM_DISPLAYCHANGE() fails on
Windows 8
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
user32:sysparams - test_WM_DISPLAYCHANGE() fails on Windows 8:
sysparams.c:2473: Test failed: ChangeDisplaySettingsExW returned -1
sysparams.c:2504: Tests skipped: bpp 8: ChangeDisplaySettingsExW returned -1
sysparams.c:2504: Tests skipped: bpp 16: ChangeDisplaySettingsExW returned -1
sysparams.c:2505: Test failed: bpp 16: ChangeDisplaySettingsExW returned -1
sysparams.c:2504: Tests skipped: bpp 24: ChangeDisplaySettingsExW returned -1
sysparams.c:2505: Test failed: bpp 24: ChangeDisplaySettingsExW returned -1
sysparams.c:2523: Test failed: ChangeDisplaySettingsExW returned -1
See https://test.winehq.org/data/patterns.html#user32:sysparams
Where -1 == DISP_CHANGE_FAILED (so not very helpful)
This is systematic and impacts the two TestBot Windows 8 VMs.
Also this check does not make sense: broken( DISP_CHANGE_FAILED && bpp == 8 )
and given that we get this res value for all bpps, maybe it should be:
broken( res == DISP_CHANGE_FAILED )
--
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=55195
Bug ID: 55195
Summary: wininet:http - test_http_connection() sometimes fails
with a SENDING_REQUEST status on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: wininet
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
wininet:http - test_http_connection() sometimes fails with a SENDING_REQUEST
status on Windows:
http.c:4126: Testing reading compressed content from cache
http.c:376: Test failed: unexpected status 30 (INTERNET_STATUS_SENDING_REQUEST)
http.c:376: Test failed: unexpected status 31 (INTERNET_STATUS_REQUEST_SENT)
http.c:376: Test failed: unexpected status 40
(INTERNET_STATUS_RECEIVING_RESPONSE)
http.c:376: Test failed: unexpected status 41
(INTERNET_STATUS_RESPONSE_RECEIVED)
http.c:376: Test failed: unexpected status 50
(INTERNET_STATUS_CLOSING_CONNECTION)
http.c:376: Test failed: unexpected status 51
(INTERNET_STATUS_CONNECTION_CLOSED)
http.c:3665: Test failed: expected status 30 (INTERNET_STATUS_SENDING_REQUEST)
1 times, received 2 times
http.c:3666: Test failed: expected status 31 (INTERNET_STATUS_REQUEST_SENT) 1
times, received 2 times
http.c:3667: Test failed: expected status 40
(INTERNET_STATUS_RECEIVING_RESPONSE) 1 times, received 2 times
http.c:3668: Test failed: expected status 41
(INTERNET_STATUS_RESPONSE_RECEIVED) 1 times, received 2 times
http.c:5908: Testing InternetReadFileExW with IRF_ASYNC flag...
See https://test.winehq.org/data/patterns.html#wininet:http
Sometimes some of the 41, 50 and 51 status failures do not happen.
These failures go back to at least 2022-11-29 and have happened a bit over once
per month since, impacting all Windows versions. But there have been months
with no failure too, and lately it has mostly been happening on Windows 8:
* 2022-11-29 win22H2_fgtb-w10pro64-rx550-64
* 2023-03-10 win21H1_newtb-w10pro64-32
* 2023-03-20 win7_newtb-w7pro64-64
* 2023-03-28 win22H2_fgtb-w10pro64-32
* 2023-04-06 win7_newtb-w7u-pt-PT
* 2023-04-28 win21H1_newtb-w10pro64-ru-64
* 2023-05-22 win21H1_newtb-w10pro64-fr-64
* 2023-06-08 win81_newtb-w8adm
* 2023-07-04 win81_newtb-w864-64
* 2023-07-04 win81_newtb-w8
--
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=54240
Bug ID: 54240
Summary: wineserver crash when calling an rpc stub
Product: Wine
Version: 8.0-rc2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rpc
Assignee: wine-bugs(a)winehq.org
Reporter: memory.thrasher(a)gmail.com
Distribution: ---
"M.A.R.S." game would immediately crash when attempting to launch due to a
missing (stubbed) function. I implemented the function in the linked merge
request. Game submitted to app db, also linked below.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1888https://appdb.winehq.org/objectManager.php?sClass=version&iId=41241&iTestin…
With the above patch, the game progresses to a splashscreen before crashing
without any helpful errors, likely due to "easy anti-cheat" software. With
tracing enabled, I was able to confirm the rpc endpoint generated by my patch
was functioning correctly.
--
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=55192
Bug ID: 55192
Summary: user32:sysparams - test_SPI_SETWALLPAPER() fails to
restore the '(None)' wallpaper
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
user32:sysparams - test_SPI_SETWALLPAPER() fails to restore the '(None)'
wallpaper:
sysparams.c:2442: Test failed: ***warning*** failed to restore the original
value: rc=0 err=2
sysparams.c:346: Test failed: Wrong value in registry: Control Panel\Desktop
Wallpaper '' instead of '(None)'
See https://test.winehq.org/data/patterns.html#user32:sysparams
Where 2 == ERROR_FILE_NOT_FOUND
This is systematic and specific to the w7u VM. The way I understand it that VM
does not have a wallpaper but instead of returning the like of an empty string,
SPI_GETDESKWALLPAPER returns '(None)' (maybe this is even the registry value).
Anyway when we try to restore the value, SPI_SETDESKWALLPAPER checks that the
'(None)' file exists and fails.
To investigate:
* Is '(None)' the actual registry value?
* Do our other VMs really all have a wallpaper? Is that why none of them
returns '(None)'?
* If another Windows version has no wallpaper does SPI_GETDESKWALLPAPER return
'None' or is that specific to Windows 7?
* To fix the test, check whether the oldvalue file exists and set the wallpaper
to an empty string if not? Or bypass SPI_SETDESKWALLPAPER to set the registry
directly in that case?
--
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=55171
Bug ID: 55171
Summary: Wine app does not run on openSUSE Leap
Product: Wine
Version: 7.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: niltongmedeiros(a)gmail.com
Distribution: ---
The Wine app does not run on openSUSE Leap 15.5 KDE 5.103.0, does not appear in
the menu, downloaded and installed from the Discover store.
How can I proceed?
--
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=47067
Bug ID: 47067
Summary: Font is too wide in RPGMaker game Hello Charlotte
Product: Wine
Version: 4.6
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Created attachment 64246
--> https://bugs.winehq.org/attachment.cgi?id=64246
Screenshot on Wine
The font in the game is too wide, meaning long lines are cut off.
Already tried winetricks allfonts, which doesn't help.
To reproduce, just download the game, run Game.exe and click Start in the
mainmenu.
--
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=53230
Bug ID: 53230
Summary: user32:win - test_activateapp() fails randomly with
fvwm
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
user32:win - test_activateapp() fails randomly with fvwm. The failures
themselves change quite a bit from one run to the next, depending on where in
the function the failures start. It looks a bit like a race condition between
the test and the window manager.
Here is a relatively complete set:
win.c:10976: Test failed: Expected foreground window 0, got 01DE007C
win.c:10982: Test failed: Expected foreground window 001A013C, got 01DE007C
win.c:10992: Test failed: Expected foreground window 001A013C, got 00000000
win.c:10999: Test failed: Expected foreground window 001A013C, got 01DE007C
win.c:11001: Test failed: GetActiveWindow() = 00000000
win.c:11001: Test failed: GetFocus() = 00000000
win.c:11003: Test failed: Received WM_ACTIVATEAPP(0), did not expect it.
win.c:11011: Test failed: Expected foreground window 001A013C, got 00000000
win.c:11013: Test failed: GetActiveWindow() = 00000000
win.c:11013: Test failed: GetFocus() = 00000000
win.c:11021: Test failed: Received WM_ACTIVATEAPP(1), did not expect it.
https://test.winehq.org/data/patterns.html#user32:win
The failures don't seem to depend on the locale or bitness. However they only
happen in the TestBot VMs which happen to run fvwm (with a specially curated
configuration file) and don't happen on my box which runs KDE for instance.
--
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.