https://bugs.winehq.org/show_bug.cgi?id=54008
Bug ID: 54008
Summary: d3d9:device sometimes fails to create a D3D object in
Wine, crashes
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: ---
d3d9:device sometimes fails to create a D3D object on the TestBot VMs, crashes.
The failure and ensuing crash can happen in many locations:
test_get_rt():
device.c:4821: Test failed: Received unexpected WM_SIZE message.
device.c:3016: Test failed: Failed to create a D3D object.
Unhandled exception: page fault on read access to 0x0000000000000000 in 64-bit
code (0x000000004154d5).
test_multi_adapter():
device.c:14264: Test failed: Failed to create a D3D object.
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code
(0x00459a93).
test_cursor_pos():
device.c:5241: Test failed: Failed to create a D3D object.
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code
(0x0041816a).
See https://test.winehq.org/data/patterns.html#d3d9:device
This failure can probably happen anywhere in the test.
--
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=54621
Bug ID: 54621
Summary: Wine 8.3 64-bit is missing in the Debian bookworm repo
Product: Wine
Version: 8.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: shtetldik(a)gmail.com
Distribution: ---
For some reason recent build of Wine 8.3 is missing 64-bit version in the
Debian repo (for bookworm):
https://dl.winehq.org/wine-builds/debian/dists/bookworm/main/binary-amd64/
Note how wine-devel_8.3~bookworm-1_amd64.deb is there, but
wine-devel-amd64_8.3~bookworm-1_amd64.deb is not.
--
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=54593
Bug ID: 54593
Summary: gdi32:dc - The SetDeviceGammaRamp() tests fails on
Windows 10 1909
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: gdi32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
gdi32:dc - The SetDeviceGammaRamp() fails on Windows 10 1909:
dc.c:1271: Test failed: SetDeviceGammaRamp succeeded
dc.c:1276: Test failed: SetDeviceGammaRamp succeeded
dc.c:1288: Test failed: SetDeviceGammaRamp succeeded
See https://test.winehq.org/data/patterns.html#gdi32:dc
The tests tries to set 3 types of invalid gamma ramps and expects Windows to
reject them. These failures are 100% reproducible even when running the test on
its own (so the failures are not caused by interference from another test).
Up until Windows 10 1809 all the tests are skipped:
dc.c:1262: Tests skipped: SetDeviceGammaRamp failed, skipping tests
And on Windows 10 2004+ the tests succeed. So it looks like 1909 just did not
perform all the gamma ramp validation checks.
Except that on 2022-07-12 and 2022-11-11, the test had the exact same failures
(same lines too) on w1064-tsign which is Windows 10 21H2.
--
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=54298
Bug ID: 54298
Summary: d3d12:d3d12 - test_desktop_window() fails on Windows
10 1709
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
d3d12:d3d12 - test_desktop_window() fails on Windows 10 1709:
d3d12.c:1412: Test failed: Got unexpected hr 0x8007000e.
See https://test.winehq.org/data/patterns.html#d3d12:d3d12
Where 0x8007000e == E_OUTOFMEMORY.
* On w1064v1507 and w1064v1607 this test is skipped because init_test_context()
fails to create a device.
* On w1064v1809 and greater this specific test just succeeds (and another fails
instead).
* So w1064v1709 supports just enough of d3d12 to run the test, but not enough
to succeed.
Maybe just add a broken()?
https://gitlab.winehq.org/wine/wine/-/merge_requests/1961
--
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=54052
Bug ID: 54052
Summary: winhttp:notification times out randomly in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: winhttp
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
winhttp:notification times out randomly in Wine.
First, on 2022-11-24 Paul Gofman got a series of patches in that probably fixed
a bunch of these random timeouts (the situation on fg-deb64 and fgtb-debian11
seems better for one).
However the following merge requests got timeouts after the patches went in:
* MR!1553 on 2022-11-26
...
notification.c:117: Test failed: 892: expected status 0x20000 got 0x200000
winhttp:notification:0b98 done (258) in 120s 1148B
* MR!1557 on 2022-11-27
...
notification.c:117: Test failed: 988: expected status 0x80000 got 0x200000
winhttp:notification:06d0 done (258) in 120s 1148B
* MR!1560 on 2022-11-27
...
notification.c:1184: Test marked todo: got 3
winhttp:notification:052c done (258) in 120s 1118B
Where:
0x20000 == WINHTTP_CALLBACK_STATUS_HEADERS_AVAILABLE
0x80000 == WINHTTP_CALLBACK_STATUS_READ_COMPLETE
0x200000 == WINHTTP_CALLBACK_STATUS_REQUEST_ERROR
So there may still be some issue left.
--
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=53975
Bug ID: 53975
Summary: d3drm:d3drm sometimes fails to create an immediate
mode device in Wine
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: ---
d3drm:d3drm sometimes fails to create an immediate mode device in Wine:
d3drm.c:5843: Test failed: Cannot create IM device, skipping tests.
This can happen in either test_create_device_from_d3d2() or
test_create_device_from_d3d3() and always comes with the following winediag
message repeated 3 times in the Wine log:
063c:err:winediag:d3d_device_create The application wants to create a Direct3D
device, but the current DirectDrawRenderer does not support this.
See https://test.winehq.org/data/patterns.html#d3drm:d3drm
So far this has only been seen on debian11 and debiant so it may be related to
their dual-screen configuration. Also this failure first happened on 2022-11-07
and there are 4 known instances so far (2 in the nightly runs and 2 TestBot job
false positives). So it is probably caused by some recent Wine change.
--
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=53270
Bug ID: 53270
Summary: test_WSARecv() fails when using wow64 thunks
[Wow64ApcRoutine() overwrites return value set by
NtContinue()]
Product: Wine
Version: 7.11
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: source, testcase
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: z.figura12(a)gmail.com
Distribution: ---
Created attachment 72642
--> https://bugs.winehq.org/attachment.cgi?id=72642
test diff
This might be a bit early since the wow64 path isn't exactly supported, but
(with a couple patches to ntdll to enable it in the first place) it works well
enough to expose a bug in its own implementation, which is more than a little
tricky to solve.
I'm attaching a diff to the tests, which I will submit upstream, which
demonstrates the root of the problem.
KiUserApcDispatcher can be called from three-ish places: wait functions,
NtTestAlert, and NtContinue. In the case of the former two KiUserApcDispatcher
will be passed a wow64 context which, among other things, has its %rax/%eax set
to STATUS_USER_APC or STATUS_SUCCESS respectively. In the latter case %rax/%eax
comes from the passed-in context.
Wow64ApcRoutine tries to translate the %rax from the 64-bit context into the
%eax that the 32-bit context will restore to. In the former two cases this is
STATUS_USER_APC or STATUS_SUCCESS and things work fine. In the latter case,
however, this overwrites %eax from the passed-in 32-bit context. Note that we
don't get the right %eax from ntdll either, because (a) ntdll gives us a 64-bit
context anyway, and (b) we don't use NtContinue but rather NtTestAlert. That
does mean we could fix it by using NtContinue and putting the %eax value into
%rax, which is a bit weird but I don't know if there's a better option.
This is wrong inherently, as the attached tests show, but it more saliently
ends up breaking LdrInitializeThunk, because on i386 RtlUserThreadStart is
called with %eax pointing to the thread procedure, and we then overwrite that
with zero.
--
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=49266
Bug ID: 49266
Summary: Amazon Games installs but won't start
Product: Wine
Version: 5.8
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: maiktapwagner(a)aol.com
Distribution: ---
Created attachment 67270
--> https://bugs.winehq.org/attachment.cgi?id=67270
Console Output (wine 5.8)
Hello everyone,
I download the Amazon games installer from:
https://download.amazongames.com/AmazonGamesSetup.exe
and got it installed with wine 5.8 - Unfortunately the application doesn't
launch. Console output 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.
https://bugs.winehq.org/show_bug.cgi?id=54491
Bug ID: 54491
Summary: regedit/regproc.c - export_key() is unable to return
TRUE
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: programs
Assignee: wine-bugs(a)winehq.org
Reporter: gonzomdx(a)gmail.com
Distribution: ---
export_key() function should return either TRUE if succeeded or FALSE if
failed.
Values are returned in lines 1459 and 1463 (hardcoded FALSE) as well as line
1471 (BOOL ret).
Due to the fact that ret get its value returned from the function
export_registry_data() (line 1466) which EVER returns an int of value 0, there
is no possibility that export_key() succeeds.
The easiest solution would be to simply return TRUE instead of ret.
The most elegant solution would be to let export_registry_data() sane data.
--
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=54168
Bug ID: 54168
Summary: kernel32:console - test_wait() sometimes fails on
Windows 8+
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:console - test_wait() sometimes fails on Windows 8+:
console.c:1198: Test failed: WaitForSingleObject returned 0
console.c:1200: Test failed: WaitForSingleObject returned 0
console.c:1202: Test failed: WaitForSingleObject returned 0
console.c:1204: Test failed: WaitForSingleObject returned 0
console.c:1206: Test failed: WaitForSingleObject returned 0
console.c:1208: Test failed: NtWaitForSingleObject returned 0
console.c:1211: Test failed: NtWaitForSingleObject returned 0
See https://test.winehq.org/data/patterns.html#kernel32:console
This happens a bit less that twice per month.
--
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=53236
Bug ID: 53236
Summary: d3d9:device - test_wndproc() sometimes gets an
unexpected WM_DISPLAYCHANGE in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
d3d9:device - test_wndproc() sometimes gets an unexpected WM_DISPLAYCHANGE in
Wine:
device.c:4349: Test failed: Expected message 0x7e for window 0x1, but didn't
receive it, i=1.
device.c:4359: Test failed: Got unexpected hr 0x88760869.
https://test.winehq.org/data/patterns.html#d3d9:device
Where 0x007e == WM_DISPLAYCHANGE.
The second failure is not always present but does not seem to happen without
the first one so they are probably related.
These failures:
* Happen on my Debian 11 + Intel + KDE box (fg-deb64)
* Don't seem to happen on my Debian 11 + QXL + fvwm + single monitor VM
* Happen on the TestBot's Debian 11 + QXL + fvwm + dual monitor VM
* Happen on the TestBot's Debian Testing + QXL + fvwm + dual monitor VM
(very rarely but two wow64 instance have been seen)
--
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=47407
Bug ID: 47407
Summary: Hard Truck 2: King of The Road (GOG version): movies
don't play
Product: Wine
Version: 4.11
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: t6zm3v62fkp7fe5(a)yandex.ru
Distribution: ---
Created attachment 64755
--> https://bugs.winehq.org/attachment.cgi?id=64755
Screenshot from intro movie
In Hard Truck 2: King of The Road (GOG version), movies don't play: e.g. intro
logos and movie (screenshot-from-intro-movie.png) and movies when you're
arrested or robbed by mafia.
Lubuntu 18.04.2, Wine 4.11 from official PPA.
--
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=7585
Alexandre Julliard <julliard(a)winehq.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #73 from Alexandre Julliard <julliard(a)winehq.org> ---
Closing bugs fixed in 8.4.
--
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=54645
Bug ID: 54645
Summary: TextPad 9.1 installation fails in Wine 6 from Linux
Mint repo
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: nouvel.aubergiste(a)gmail.com
Distribution: ---
Created attachment 74174
--> https://bugs.winehq.org/attachment.cgi?id=74174
backtrace file
TextPad 9.1 installation fails using Wine 6 from Linux Mint repository. TextPad
8+ works fine. I tried it several times and the error is always the same
The graphic error is :
SpellCheckerFactory
Unknown error 0x80040154
--
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=54505
Bug ID: 54505
Summary: psapi:psapi_main - The 64-bit
test_EnumProcessModules() gets unexpected Notepad case
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_EnumProcessModules() gets unexpected Notepad
case on Windows 11:
psapi_main.c:160: Test failed: got Notepad.exe
psapi_main.c:164: Test failed: got C:\Program Files\WindowsApps\Microsoft.
See https://test.winehq.org/data/patterns.html#psapi:psapi_main
This failure is specific to the 64-bit tests running on Windows 11, that is the
32-bit test has other (possibly related) failures, and Windows 10 and lower
don't have failures.
Also this failure has been present ever since the Windows 11 VM was added.
This looks like a simple case issue. If so it's strange that it only happens in
64-bit but it could be cured by a simple strcasecmp() or equivalent.
--
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=54299
Bug ID: 54299
Summary: d3d12:d3d12 - test_create_device() gets an unexpected
0 refcount on Windows 10 1909+
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
d3d12:d3d12 - test_create_device() gets an unexpected 0 refcount on Windows 10
1909+:
d3d12.c:888: Test failed: Got unexpected refcount 0.
See https://test.winehq.org/data/patterns.html#d3d12:d3d12
This test
* is skipped on Windows 10 < 1709,
* succeeds on Windows 10 1709 and 1809,
* and fails on Windows 10 1909+ because the refcount is 0.
The test seems unsure about the exact refcount value since it only tests for
"refcount >= 1".
Maybe it should be something like "refcount == 0 || broken(refcount >= 1)",
possibly with a todo_wine?
Or that test could just be removed entirely?
--
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=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.