https://bugs.winehq.org/show_bug.cgi?id=54637
Bug ID: 54637
Summary: riched20:txtsrv - test_TxGetNaturalSize fails if
system GUI font's glyph widths are wider than expected
by the test
Product: Wine
Version: 8.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: richedit
Assignee: wine-bugs(a)winehq.org
Reporter: jinoh.kang.kr(a)gmail.com
CC: huw(a)codeweavers.com, jzeng(a)codeweavers.com
Regression SHA1: 6e264bbd1ddf0d271d4506462ecd4f20f4a20597
Distribution: ---
Today, test_TxGetNaturalSize() creates a pop-up window with a fixed size
(extent) of 100 x 100. The test function then proceeds to compute the
natural size of rich edit control that fits the sample text
"TestSomeText" and compare it to the RECT calculated by DrawText.
It appears that this test fails if the text width exceeds the width of
the test window's client area. In this case, DrawText() with
DT_WORDBREAK breaks the text into the two lines due to text wrapping;
however, Rich Edit's ITextServices::TxGetNaturalSize implementation does
not seem to perform text wrapping on overflow. This results in extent
mismatch.
In conclusion, the test may fail if the rendered width of the sample
text "TestSomeText" is larger than what the test expects. This depends
on the current font used for DEFAULT_GUI_FONT.
Omitting DT_WORDWRAP for the DrawText() call seems to fix this test failure.
--
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=54506
Bug ID: 54506
Summary: psapi:psapi_main - The 64-bit
test_EnumProcessModulesEx() gets pcs-6464 and pcs-6432
failures on Windows 11
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: psapi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
psapi:psapi_main - The 64-bit test_EnumProcessModulesEx() gets pcs-6464 and
pcs-6432 failures on Windows 11:
psapi_main.c:303: Test failed: pcs-6464: 2: expecting
C:\windows\system32\notepad.exe but got C:\Program
Files\WindowsApps\Microsoft.WindowsNotepad_10.2102.13.0_x64__8wekyb3
psapi_main.c:303: Test failed: pcs-6464: 0: expecting
C:\windows\system32\notepad.exe but got C:\Program
Files\WindowsApps\Microsoft.WindowsNotepad_10.2102.13.0_x64__8wekyb3
psapi_main.c:303: Test failed: pcs-6464: 3: expecting
C:\windows\system32\notepad.exe but got C:\Program
Files\WindowsApps\Microsoft.WindowsNotepad_10.2102.13.0_x64__8wekyb3
psapi_main.c:448: Test failed: pcs-6432: expecting 32bit modules
psapi_main.c:299: Test failed: pcs-6432: 1: got error 6
psapi_main.c:300: Test failed: pcs-6432: 1: expecting notepad.exe but got e{u
psapi_main.c:302: Test failed: pcs-6432: 1: got error 6
psapi_main.c:303: Test failed: pcs-6432: 1: expecting
C:\windows\syswow64\notepad.exe but got e{u
psapi_main.c:306: Test failed: pcs-6432: 1: got error 6
psapi_main.c:307: Test failed: pcs-6432: 1: expected 00000000DEADBEEF, got
00007FF8DF7EF800
psapi_main.c:309: Test failed: pcs-6432: 1: got entry point 000000000040BDF8
psapi_main.c:303: Test failed: pcs-6432: 0: expecting
C:\windows\syswow64\notepad.exe but got C:\Program
Files\WindowsApps\Microsoft.WindowsNotepad_10.2102.13.0_x64__8wekyb3
psapi_main.c:303: Test failed: pcs-6432: 3: expecting
C:\windows\syswow64\notepad.exe but got C:\Program
Files\WindowsApps\Microsoft.WindowsNotepad_10.2102.13.0_x64__8wekyb3
See https://test.winehq.org/data/patterns.html#psapi:psapi_main
Where 6 == ERROR_INVALID_HANDLE, hence the presumable uninitialized strings
too.
These tests and failures were introduced by the commit below:
commit 84a9a1c8fbc1e8ccc9c34cf0db375813b3ac2955
Author: Eric Pouech <eric.pouech(a)gmail.com>
AuthorDate: Mon Jan 30 13:45:46 2023 +0100
psapi: Add tests for EnumProcessModulesEx().
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
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=54313
Bug ID: 54313
Summary: HS_hevo_gc 8.8.1.1 fails to launch
Product: Wine
Version: 8.0-rc4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dean-chen(a)qq.com
Distribution: ---
Created attachment 73873
--> https://bugs.winehq.org/attachment.cgi?id=73873
log info copied from terminal
HS_hevo_gc 8.8.1.1 fails to launch
THS_hevo_gc8.8.1.1.exe can be dowloaded from THS web site on Windows system.
http://activity.ths123.com/html/xb/160809/index.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=54058
Bug ID: 54058
Summary: user32:input - test_ToAscii() fails in the Hindi UTF-8
locale
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
Created attachment 73613
--> https://bugs.winehq.org/attachment.cgi?id=73613
user32/tests: Skip a ToAscii() test in UTF-8 code pages.
user32:input - test_ToAscii() fails in the Hindi UTF-8 locale:
input.c:3133: Test failed: ToAscii for character 'A' didn't return 1 (was 0)
See https://test.winehq.org/data/patterns.html#user32:input
Note that this did not happen before 2022-11-21 because some unknown Windows
quirk caused the UserDefaultLCID and ThreadLocale to be reset to English before
the test was started.
In any case it seems ToAscii() does not depend just on the keyboard layout but
also on the current code page which makes sense. So then maybe we should limit
the test to non-UTF-8 code pages as in the attached patch?
--
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=54020
Bug ID: 54020
Summary: The 32-bit ntdll:wow64 fails on Windows 11
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
The 32-bit ntdll:wow64 fails on Windows 11:
wow64.c:254: Test failed: wrong len 0
wow64.c:255: Test failed: wrong teb 0000004C / 00000000
wow64.c:258: Test failed: GdiBatchCount not set
wow64.c:282: Test failed: wrong peb 00000000 / 00000002
wow64.c:285: Test failed: wrong len 0
wow64.c:295: Test failed: wrong len 0
wow64.c:301: Test failed: wrong ImagePathName ptr 00000000 / 00000000-00000000
wow64.c:302: Test failed: wrong CommandLine ptr 00000000 / 00000000-00000000
wow64.c:303: Test failed: wrong WindowTitle ptr 00000000 / 00000000-00000000
wow64.c:304: Test failed: wrong Desktop ptr 00000000 / 00000000-00000000
wow64.c:305: Test failed: wrong ShellInfo ptr 00000000 / 00000000-00000000
wow64.c:331: Test failed: debugging failed
wow64.c:333: Test failed: wrong len 0
wow64.c:460: cs 0023 ss 002b fs 0053
wow64.c:782: Test failed: unknown module 7ffb1ed00000 L"wow64base.dll" found
wow64.c:782: Test failed: unknown module 7ffb20100000 L"wow64con.dll" found
See https://test.winehq.org/data/patterns.html#ntdll:wow64
The values are pretty stable from one run to the next but do change from time
to time (causing false positives). Note also that the 64-bit version fails on
Windows 11 too but the failures there are pretty different (see bug 54019).
--
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=53818
Bug ID: 53818
Summary: foobar2000 crashes shortly after startup
Product: Wine
Version: 7.19
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: matthias.grobarek(a)posteo.de
Distribution: ---
Created attachment 73344
--> https://bugs.winehq.org/attachment.cgi?id=73344
winedbg output
After starting foobar2000, it quickly crashes after a few seconds, no matter
what you do. Wine 7.18 and 7.17 are not affected.
I’m using wine-staging (no matter the version) on Gentoo Linux (kernel 6.0.2),
compiled for both 32bit and 64bit, with the following flags activated: x, alsa,
fontconfig, mshtml, gstreamer, mingw, mscoree, gettext, openal, opengl, sdl,
gnutls, freetype, udev, dbus, unwind, usb, vulkan, xcomposite.
I attached the output of winedbg and also the crash log and dump that
foobar2000 itself produces. If you need any more information, please tell me
what exactly I should 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.
https://bugs.winehq.org/show_bug.cgi?id=53526
Bug ID: 53526
Summary: kernel32:sync - test_timer_queue() occasionally fails
to delete the timer on Windows 10
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
kernel32:sync - test_timer_queue() occasionally fails to delete the timer on
Windows 10:
sync.c:1135: Test failed: DeleteTimerQueueTimer
https://test.winehq.org/data/patterns.html#kernel32:sync
This failure happened twice:
* 2022-05-27 w10pro64-de-64
* 2022-08-04 w10pro64-he-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=53488
Bug ID: 53488
Summary: The dxgi:dxgi output is too big on debiant
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The dxgi:dxgi output is too big in Wine.
It used to be about 24 KB but the commit below pushed it to 34 KB, over the 32
KB limit.
Then on 2022-07-22 another commit improved the situation on debian11 but not on
debiant where the size has not changed since the commit below.
commit 184ff3bfbb4be3e3fbcfaaba3ec7095d2d885882
Author: Nikolay Sivov <nsivov(a)codeweavers.com>
Date: Sat Jun 11 19:36:20 2022 +0300
dxgi: Create DXGI resource object, optionally supporting surface
interfaces.
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
dlls/d3d11/d3d11_private.h | 4 +-
dlls/d3d11/tests/d3d11.c | 7 -
dlls/d3d11/texture.c | 130 +++++++-------
dlls/dxgi/Makefile.in | 2 +-
dlls/dxgi/device.c | 24 +--
dlls/dxgi/dxgi_private.h | 11 +-
dlls/dxgi/resource.c | 423 +++++++++++++++++++++++++++++++++++++++++++++
dlls/dxgi/surface.c | 296 -------------------------------
dlls/dxgi/tests/dxgi.c | 34 ++--
include/wine/winedxgi.idl | 7 +-
10 files changed, 526 insertions(+), 412 deletions(-)
create mode 100644 dlls/dxgi/resource.c
delete mode 100644 dlls/dxgi/surface.c
--
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=54553
Bug ID: 54553
Summary: mmdevapi:propstore - The 32-bit
test_setvalue_on_wow64() fails on Windows 10 2004+
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: mmdevapi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
mmdevapi:propstore - The 32-bit test_setvalue_on_wow64() fails on Windows 10
2004+:
propstore.c:186: Test failed: Wrong error when opening mmdevices Render key: 0
See propstore.c:186: Test failed: Wrong error when opening mmdevices Render
key: 0
As far as I can tell what this means is that the assumption that "should NOT
find the key in 32-bit view" is incorrect on Windows 10 2004+.
So maybe the old behavior should be considered to be broken() nowadays?
--
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=54078
Bug ID: 54078
Summary: ntdll:pipe - test_blocking() sometimes fails in Wine
when the pipe is not signaled
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
ntdll:pipe - test_blocking() sometimes fails in Wine when the pipe is not
signaled:
pipe.c:1769: Test marked todo: client is not signaled
pipe.c:1751: Test failed: pipe is not signaled
pipe.c:1769: Test marked todo: client is not signaled
pipe.c:1770: Test failed: pipe is not signaled
See https://test.winehq.org/data/patterns.html#ntdll:pipe
Here is this failure's nightly WineTest run history:
* There was no failure in June and July.
* The first known failure happened on 2022-08-13, the next on 2022-08-18.
* The third failure happened on 2022-09-23.
* The fourth on 2022-11-04 which was followed by 9 more in November.
So it's likely something changed in early August-ish that introduced this
failure. But there has been a further change in November that makes it more
frequent (maybe the latter is because the TestBot now runs two VMs at a time so
the host is more busy, though that started a bit earlier, on 2022-10-25).
This failure also happens in the GitLab CI.
--
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.