https://bugs.winehq.org/show_bug.cgi?id=45098
Bug ID: 45098
Summary: FrostPunk: multiple graphical glitches
Product: Wine
Version: 3.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: winehq(a)embed.me.uk
Distribution: ---
Created attachment 61268
--> https://bugs.winehq.org/attachment.cgi?id=61268
FrostPunk log
With patch posted in https://bugs.winehq.org/show_bug.cgi?id=45080 the game
sucessfully starts however there are severe graphical glitches which render it
unplayable. Log 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.
https://bugs.winehq.org/show_bug.cgi?id=50458
Bug ID: 50458
Summary: Tooltips block input in Foobar2000
Product: Wine
Version: 5.22
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: debilerpc(a)web.de
Distribution: ---
**Context:**
Like with most media players, Foobar2000's playlist view is essentially a
spreadsheet where each line is a track and each column displays a tag or
metadata field.
If the length of the tag exceeds the width of the column, it gets cut off. You
can see the full tag in a tooltip by hovering over it with a mouse in that
case.
**The problem:**
As long as the tooltip is displayed, the app registers neither keyboard nor
mouse input.
I suspect this problem exists in a variety of
[apps](https://bugs.winehq.org/show_bug.cgi?id=16227), not just Foobar2000, but
here it is especially annoying.
**Expected behavior:**
When input is sent, the tooltip should disappear, and Foobar2000 should react
to the input. This is what happens under Windows 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=52771
Bug ID: 52771
Summary: Wine console creation breaks comctl32:button,
dinput:keyboard, user32:dialog, user32:input,
user32:monitor and user32:win
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: programs
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The way Wine creates the window for console applications breaks
comctl32:button, dinput:keyboard, user32:dialog, user32:input, user32:monitor
and user32:win.
https://test.winehq.org/data/patterns.html#comctl32:buttonhttps://test.winehq.org/data/patterns.html#dinput:keyboardhttps://test.winehq.org/data/patterns.html#user32:dialoghttps://test.winehq.org/data/patterns.html#user32:inputhttps://test.winehq.org/data/patterns.html#user32:monitorhttps://test.winehq.org/data/patterns.html#user32:win
These all started failing in Wine on 2022-03-17 with the commit below (also
referenced in bug 52761):
commit f034084d49b354811096524d472ae5172ac1cebf
Author: Eric Pouech <eric.pouech(a)gmail.com>
Date: Thu Mar 17 08:27:28 2022 +0100
kernelbase: Handle corner case in CreateProcess.
In CreateProcess, if:
- parent isn't attached to a console
- CreateProcess's flag isn't set with DETACHED_PROCESS nor
CREATE_NEW_CONSOLE
- child is a CUI program
then a console must be allocated for the child.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52048
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
The way the TestBot starts the tests in Wine is this [1]:
testagentd (Unix, no terminal)
\- shell script (sh Unix, no terminal)
\- WineTest.pl (perl Unix, no terminal)
\- ./wine TestLauncher (Windows CUI, no console)
\- unit test (Windows CUI) -> creates a console
\- unit test can recurse upon itself (CUI)
I will now try to summarize the current understanding of the issue from the
wine-devel discussion [2], using the above figure as a reference:
1. testagentd is a daemon so it does not have an associated terminal.
2. When ./wine does not have a terminal it does not create a console window,
even when starting a console application. This is so wine can be used for
background (batch) tasks without requiring a X session or popping up windows
all over the place.
3. But when a Windows application calls CreateProcess() without
DETACHED_PROCESS, a console does get created. This is what happens when
TestLauncher starts a unit test.
4. While the console object is created synchronously in the wineserver process,
the actual window is created asynchronously (by wineconsole). This causes it to
pop up while the unit test as already started, which confuses the tests that
check the window hierarchy, the focus, etc.
There are two ways the above differ from Windows:
1. I believe Windows creates both the console object and the matching window
synchronously. So even if the console was created when starting the test unit
there should be no failure.
2. On Windows the shell script is replaced by a batch script which triggers the
console creation. So the console creation happens a bit earlier which could
also mask any window creation delay.
The reason why f034084d49b3 made a difference is that before Wine was not
creating console windows.
[1] More details on the different ways the TestBot starts the tests:
https://www.winehq.org/pipermail/wine-devel/2022-April/212550.html
[2] March: https://www.winehq.org/pipermail/wine-devel/2022-March/212330.html
April: https://www.winehq.org/pipermail/wine-devel/2022-April/212513.html
--
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=45388
Bug ID: 45388
Summary: user32:edit fails on Traditional Chinese and Korean
locales
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
user32:edit fails with the following errors on Traditional Chinese and Korean
locales:
edit.c:1489: Test failed: 0: got 1, 1
edit.c:1510: Test failed: 0: got 1, 1
edit.c:1524: Test failed: 0: got 1, 1
edit.c:1538: Test failed: 0: got 1, 1
See:
* Source matching the above
https://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/tests/edit.c;h…
* user32:edit WineTest failures
https://test.winehq.org/data/tests/user32:edit.html
The errors can be reproduced on the newtb-wvistau64-zh-cn TestBot VM, and also
happen on fg-win7u64-1spie9-ko.
--
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=52869
Bug ID: 52869
Summary: kernel32:locale - test_CompareStringA() fails in Wine
in Hindi
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
test_CompareStringA() started failing in Wine in Hindi recently:
locale.c:1884: Test failed: expected CSTR_LESS_THAN, got 2
locale.c:1886: Test failed: expected CSTR_GREATER_THAN, got 2
https://test.winehq.org/data/patterns.html#kernel32:locale
A bisect shows this failure started with the commit below:
commit 8993e15cfa5b77ac2487239354ffe63bbc5e562d
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Mon Apr 11 17:21:47 2022 +0200
kernelbase: Support UTF-7/8 codepages in get_codepage_table().
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
--
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=52743
Bug ID: 52743
Summary: regression cannot write to _fdopen'ed stdout
Product: Wine
Version: 7.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: xantares09(a)hotmail.com
Distribution: ---
since wine 7.2, opening stdout with _fdopen and printing into it crashes
```
#include <stdio.h>
#include <io.h>
#include <fcntl.h>
int main()
{
FILE * m_stdout = _fdopen(_fileno(stdout), "wb");
fprintf(m_stdout, "foo\n");
fclose(m_stdout);
return 0;
}
$ x86_64-w64-mingw32-gcc main.c
$ wine a.exe
...
wine: Unhandled page fault on read access to 0000000000000050 at address
0000000170059685 (thread 0128), starting debugger...
...
```
For context, this is what qt-xmlpatterns does:
https://github.com/qt/qtxmlpatterns/blob/dev/tools/xmlpatterns/main.cpp#L184
--
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=52362
Bug ID: 52362
Summary: Powershell Core 7 installer hangs forever on Chinese
locale (LC_ALL=zh_Han.UTF-8)
Product: Wine
Version: 7.0-rc3
Hardware: x86-64
URL: https://github.com/PowerShell/PowerShell/releases/down
load/v7.1.5/PowerShell-7.1.5-win-x64.msi
OS: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
Distribution: ---
Hi, someone i was trying to help someone to get this installed and he reported
this to me (I couldn`t reproduce it), that the installer hung for him, and in
fact he found that it was due to the fact he was running with
LC_ALL=zh_Han.UTF-8
I don`t know anything about these chinese locales, but report anyway as could
be a bug in wine (?).
reproduce: LC_ALL=zh_Han.UTF-8 5ine msiexec /i PowerShell-7.1.5-win-x64.msi
A +relay shows it`s looking for files in directory zh-CN which is not there,
though there is zn-Han(s) directories. But just copying zh-Han to zh-CN didn`t
help either.
Anyway, I guess someone with more knowledge about (Chinese) locales would have
lots more clues than i have...
--
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=52149
Bug ID: 52149
Summary: user32:dialog fails in test_DialogBoxParam() on
current Windows 10 21H1
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:dialog fails in test_DialogBoxParam() on current Windows 10 21H1:
dialog.c:1854: Test failed: got 1407
https://test.winehq.org/data/patterns.html#user32:dialog
So instead of failing with an error code of 0, the call below fails with
ERROR_CANNOT_FIND_WND_CLASS... which makes sense?
ret = DialogBoxParamA(GetModuleHandleA(NULL), "TEST_DIALOG_INVALID_CLASS",
0, DestroyDlgWinProc, 0);
It's interesting to note that this failure did not happen on the initial
Windows 10 21H1 test configurations (2021-08-23). As far as I can tell it's
only after KB5006670 was applied (on 2021-10-21) that the test started failing.
Unfortunately this is a cumulative update so it may not help narrow down the
cause very much.
--
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=52922
Bug ID: 52922
Summary: The Evil Within crashes before entering the main menu
using Vulkan renderer
Product: Wine
Version: 7.7
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
CC: z.figura12(a)gmail.com
Regression SHA1: e7d86d9c6e58e8e133c606099615b0d9e7940132
Distribution: ---
wine: Unhandled page fault on read access to 00007F3B54255B28 at address
00007F32CDDE5A09 (thread 0740), starting debugger...
--
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=52887
Bug ID: 52887
Summary: Get-Computerinfo from NoPowershell crashes
Product: Wine
Version: 7.7
Hardware: x86-64
URL: https://github.com/bitsadmin/nopowershell/releases/tag
/1.23
OS: Linux
Status: NEW
Keywords: dotnet, download
Severity: normal
Priority: P2
Component: wmi&wbemprox
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
Distribution: ---
Created attachment 72275
--> https://bugs.winehq.org/attachment.cgi?id=72275
patch
NoPowershell.exe provides a number of commandlets without the need to install
it(https://github.com/bitsadmin/nopowershell/releases/tag/1.23).
Prerequisite: winetricks -q dotnet48
The commandlet Get-Computerinfo acts as replacement of systeminfo.exe
Source:
https://github.com/bitsadmin/nopowershell/blob/master/Source/NoPowerShell/C…
Currently fails with:
Get-ComputerInfo : System.ArgumentOutOfRangeException: Index was out of range.
Must be non-negative and less than the size of
the collection.
Parameter name: index
at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument
argument, ExceptionResource resource)
at NoPowerShell.Commands.Management.GetComputerInfo.Execute(CommandResult
pipeIn)
at NoPowerShell.Program.Main(String[] args)
Attached patch fixes it, to run into next bug . Next bugs are some missing
props from various classes. After adding them (albeit quickly with some hacks)
the cmdlet runs.
I attach first three patches, rest follows later.
--
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.