https://bugs.winehq.org/show_bug.cgi?id=53386
Bug ID: 53386
Summary: cmd.exe: FOR /F USEBACKQ doesn't handle UTF-16 output
of commands.
Product: Wine
Version: 7.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: cmd
Assignee: wine-bugs(a)winehq.org
Reporter: ahiler(a)codeweavers.com
Distribution: ---
Used by installation script of Septerra Core on Steam.
Easy reproducer:
FOR /F USEBACKQ %F IN (`wmic os get osarchitecture`) DO ECHO %F
Wmic output is UTF-16 and starts with BOM. On Windows the above snipped echoes
whatever wmic spits out. Currently on Wine it gets stuck in infinite loop.
The infinite loop is addressed by
https://gitlab.winehq.org/wine/wine/-/merge_requests/352 but UTF-16 is still
not handled at all.
--
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=54435
Bug ID: 54435
Summary: Installation Error With Make
Product: Wine
Version: 8.0-rc2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: peterweyand0(a)gmail.com
Distribution: ---
Using make does not work and results in an error
<inline asm>:305:2: error: conditional branch requires assembler-local label.
'.L__wine_syscall_dispatcher_return' is external.
cbnz w16, .L__wine_syscall_dispatcher_return
I don't know what .L__wine_syscall_dispatcher_return is or how to fix this.
I've used configure successfully with default params on macOS Ventura.
--
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=54434
Bug ID: 54434
Summary: Crash upon loading document in Toonboom Harmony 17
Premium
Product: Wine
Version: 6.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mnmemma5(a)gmail.com
Distribution: ---
Created attachment 73980
--> https://bugs.winehq.org/attachment.cgi?id=73980
generated backtrace log upon crash.
Upon loading a document in Toonboom Harmony 17 Premium, the application crashes
with a WINE prompt to create a backtrace file.
This should not occur. On Windows - the application's start menu will freeze
with a "Toonboom Harmony 17 Premium is not responding" dialogue box for a few
moments before loading into program with the document open, as (possibly?)
intended.
This may only be an issue with a cracked copy of Harmony, however, as backtrace
states one of the problems is with module toonboomnetwork - which I'm pretty
sure the countryboy crack patches (likely so that it never reaches intended
licensing server and thus never verifies whether the license is legit or not) -
so if this doesn't happen with a legitimate copy, let me know (unfortunately,
I'm not paying for a full license because the prices Toonboom set are, frankly,
a bit ridiculous... at least, for someone poor - and they don't allow download
of Harmony 17 nor Storyboard 7 anymore anyways.)
However, I have used a trial license before on Windows, obtained legitimately
via the Toonboom website, and from my recollection, it appears to freeze the
same way regardless, so take that as you will.
Now, I actually set up my WINE prefixes and such through PlayOnLinux, so this
could also just be some weird issue with the way POL sets things up (I've had
an unrelated error installing Storyboard 7 relating to a lack of simulated All
Users\Documents folder) - in which case, uh, disregard this bug report, I
guess, and I'll head over to the POL forums - but this does appear to be a
problem with WINE and the way it handles programs freezing.
Running on Ubuntu MATE, version 21.10 (Impish Indri) 64 bit, if that helps
anything.
--
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=54433
Bug ID: 54433
Summary: user32:input often fails to set the foreground window
on w7u-adm, gets 800+ failures
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:input often fails to set the foreground window on w7u-adm, gets 800+
failures. Only the first five are shown below:
input.c:954: Tests skipped: Failed to set foreground window; some tests will be
skipped.
input.c:872: Test failed: 0 (a4/0): the msg sequence is not complete: expected
0104 - actual 0000
input.c:872: Test failed: 1 (46/0): the msg sequence is not complete: expected
0104 - actual 0000
input.c:872: Test failed: 2 (46/2): the msg sequence is not complete: expected
0105 - actual 0000
input.c:872: Test failed: 3 (a4/2): the msg sequence is not complete: expected
0101 - actual 0000
input.c:872: Test failed: 4 (a2/0): the msg sequence is not complete: expected
0100 - actual 0000
Among the 800+ failures some cause persistent false positives:
input.c:2929: Test failed: 9: Unexpected cursor movement
input.c:2921: Test failed: 10: expected WM_INPUT message
input.c:2929: Test failed: 10: Unexpected cursor movement
input.c:2921: Test failed: 11: expected WM_INPUT message
input.c:2929: Test failed: 11: Unexpected cursor movement
input.c:2929: Test failed: 12: Unexpected cursor movement
---> the above message look new mostly because of message order issues
input.c:1751: Test failed: expected to get 64 mouse move points but got 5
input.c:1757: Test failed: expected to get 64 mouse move points but got 5
See https://test.winehq.org/data/patterns.html#user32:menu
So the root of the issue is some previous test that messes up the environment;
most likely by triggering a UAC prompt since this only impacts the tests run
without elevated privileges. And this test changed behavior on 2023-01-09 since
that's when these massive failures started.
Also user32:input should probably be better at skipping tests when that
happens.
--
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=54427
Bug ID: 54427
Summary: Improve Wine desktop file entry generation
Product: Wine
Version: 8.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: rizalmart98(a)gmail.com
Distribution: ---
I noticed that Wine generates one desktop file entry (*.desktop) per file
extension. Which cause a lot of desktop menu entry duplicates when launching
"OPEN WITH" window for selecting file associations. Is it possible merge those
*.desktop file entry into one desktop file if they have the same program name?
--
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=54425
Bug ID: 54425
Summary: user32:clibpoard - test_string_data_process() fails on
Windows in mixed locales
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:clibpoard - test_string_data_process() fails on Windows in mixed
locales:
clipboard.c:2351: Test failed: 7: wrong size 2 / 3
clipboard.c:2352: Test failed: 7: wrong data "a\x00", expected "\x83\xbf\x00"
1020:clipboard: 7 tests executed (0 marked as todo, 0 as flaky, 2 failures), 0
skipped.
clipboard.c:231: 2 failures in child process
clipboard.c:2351: Test failed: 8: wrong size 3 / 5
clipboard.c:2352: Test failed: 8: wrong data "a\xdf\x00", expected
"\x83\xbf\x83\xc0\x00"
2024:clipboard: 7 tests executed (0 marked as todo, 0 as flaky, 2 failures), 0
skipped.
clipboard.c:231: 2 failures in child process
clipboard.c:2351: Test failed: 9: wrong size 3 / 5
clipboard.c:2352: Test failed: 9: wrong data "a\xdf\x00", expected
"\x83\xbf\x83\xc0\x00"
1a7c:clipboard: 7 tests executed (0 marked as todo, 0 as flaky, 2 failures), 0
skipped.
clipboard.c:231: 2 failures in child process
clipboard.c:2351: Test failed: 10: wrong size 4 / 7
clipboard.c:2352: Test failed: 10: wrong data "a\xdf?\x00", expected
"\x83\xbf\x83\xc0\x83\xc1\x00"
1538:clipboard: 7 tests executed (0 marked as todo, 0 as flaky, 2 failures), 0
skipped.
clipboard.c:231: 2 failures in child process
clipboard.c:2351: Test failed: 11: wrong size 4 / 7
clipboard.c:2352: Test failed: 11: wrong data "a\xdf?\x00", expected
"\x83\xbf\x83\xc0\x83\xc1\x00"
05bc:clipboard: 7 tests executed (0 marked as todo, 0 as flaky, 2 failures), 0
skipped.
clipboard.c:231: 2 failures in child process
See https://test.winehq.org/data/patterns.html#user32:clipboard
The failures happen in the w10pro64-mx-MX test configuration. What's special
about it is that it uses a mix of locales:
SystemDefaultLCID 0411
UserDefaultLCID 040c
ThreadLocale 0411
SystemPreferredUILanguages 0412,0409
UserDefaultUILanguage 0412
ThreadUILanguage 0412
Country 231
ACP 932
The failures started happening with the commit below:
commit 605ecafa67a4e034328b69396581e2f9b60d7af3
Author: Francois Gouget <fgouget(a)codeweavers.com>
Date: Wed Dec 21 18:48:29 2022 +0100
user32: Fix a SetClipboardData() buffer overflow.
Wine would append a correctly aligned NUL Unicode character to
terminate the string but overflow the buffer by one byte for odd-sized
strings.
Windows instead overwrites the last two buffer bytes with a NUL Unicode
character which ends up being misaligned for odd-sized strings.
The clipboard data has a size field anyway so match the Windows
behavior.
Tweak the tests to show that SetClipboardData() can overwrite half of
the Unicode string's last character.
--
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.