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.
https://bugs.winehq.org/show_bug.cgi?id=52847
Bug ID: 52847
Summary: GetACP() returns CP_UTF8 on some debian VM
Product: Wine
Version: 7.6
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: eric.pouech(a)orange.fr
Distribution: ---
wine's tests in kernel32/tests/process.c fail on some Debian VM
(Dhivehi:Maldives and Hindi:India)
debugging it shows:
- conhost (in window.c) aborts at startup because TranslateCharsetInfo(
GetACP() ...) fails in Wine
- both locale return CP_UTF8 from GetACP()
- testing on windows vm (Hindi), show that GetACP() returns 1252 CP
- moreover, testing on Win11 TranslateCharsetInfo( CP_UTF8 ) succeeds
returning the Win11 values for CP_UTF8 in TranslateCharsetInfo let the
kernel32:process run "correctly" (ie no longer showing the specific errors
related to TranslateCharsetInfo)
--
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=48045
Bug ID: 48045
Summary: comdlg32:filedlg crashes or times out randomly
Product: Wine
Version: unspecified
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: comdlg32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Created attachment 65586
--> https://bugs.winehq.org/attachment.cgi?id=65586
comdlg32:filedlg: Traces to debug random crash / timeouts.
comdlg32:filedlg crashes randomly on all Windows versions from Vista to Windows
8 while Windows 10 (at least 1507, 1709 and 1809) gets random timeouts.
https://test.winehq.org/data/tests/comdlg32:filedlg.html
When successful comdlg32:filedlg does not print much so the standard reports
are pretty much useless to spot the place where the test gets stuck on Windows
10, assuming it gets stuck in a specific place rather than just being slow.
As for the crashes, they don't trigger the tests exc_filter() so there is no
indication of the last successful ok() call. Turning on 'Report successful
tests' may be preventing the crash (or these runs just got lucky).
It's possible to reproduce the crash while adding the traces in the attached
patch. This is not entirely fruitful as the crashes don't seem to always happen
in the same place. test_extension() is the place where most issues happen
though:
https://testbot.winehq.org/JobDetails.pl?Key=59060
-> wvistau64: Crash in test_extension(). Based on the test_extension_helper()
traces, it happened in the loop with i=1 so for "TestFilter
(*.abc;)\0*.abc;\0".
https://testbot.winehq.org/JobDetails.pl?Key=59086
-> w2008s64+exe: Crash on or after test_extension() return
https://testbot.winehq.org/JobDetails.pl?Key=59088
-> wvistau64+exe: Crash in test_DialogCancel()
https://testbot.winehq.org/JobDetails.pl?Key=59091
-> wvistau64_fr: Spent 39s in test_null_filename() but no timeout
https://testbot.winehq.org/JobDetails.pl?Key=59139
-> wvistau64: Crash in test_null_filename()
-> wvistau64_fr: Timeout in test_extension()
filedlg.c:1048: filter=[TestFilter (*.ab?) lpstrDefExt=NULL]
https://testbot.winehq.org/JobDetails.pl?Key=59151
-> wvistau64: Crash in test_extension()
filedlg.c:1048: filter=[TestFilter (*.abc.def)]
-> wvistau64_fr: Timeout in or after test_mru()
filedlg.c:637: 19 test_ok
filedlg.c:904: 29 test_getfolderpath
filedlg.c:986: 30 test_mru
-> w1064v1809_zh_CN: Two failures in test_extension()
filedlg.c:1053: Test failed: TestFilter (*.pt*;*.abc): expected TRUE
filedlg.c:1059: Test failed: TestFilter (*.pt*;*.abc): Filename is deadbeef,
expected deadbeef.xyz
Memory corruption, maybe happening quite early 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=52924
Bug ID: 52924
Summary: Guilty Gear XX #Reload: black screen since wine 5.0
Product: Wine
Version: 7.6
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: s.guidoni(a)tin.it
Distribution: ---
Since wine 5.0 the game "Guilty Gear XX ♯Reload" shows a black screen while
running.
The game starts, the introductory videos are displayed correctly, then the game
runs, but the screen is just black, with some blocky piece of graphics flashing
now and then across the screen. The sound plays, so one can browse the menu,
start a game and so on, but the screen stays black with some bright rectangular
shape flashing around.
The game is based on DirectX 8.1 and the last wine version that works is 4.21.
With wine 4.21, the console output is:
002d:fixme:win:EnumDisplayDevicesW ((null),0,0x33f798,0x00000000), stub!
002f:fixme:d3d:state_linepattern_w Setting line patterns is not supported in
OpenGL core contexts.
002d:err:quartz:GetClassMediaFile Media class not found
002d:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi
sound output probably won't work.
With wine 5.0.5, it is:
0033:fixme:ntdll:NtQuerySystemInformation info_class
SYSTEM_PERFORMANCE_INFORMATION
0033:fixme:d3d:wined3d_swapchain_init Unimplemented swap effect 0x5.
0035:fixme:d3d:state_linepattern_w Setting line patterns is not supported in
OpenGL core contexts.
0033:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi
sound output probably won't work.
With wine 7.6, it is:
012c:err:winediag:wined3d_dll_init Setting multithreaded command stream to 0x3.
012c:err:winediag:wined3d_dll_init Using the OpenGL renderer.
012c:fixme:imm:ImeSetActiveContext (0x266c88, 1): stub
012c:fixme:imm:ImmReleaseContext (0002010C, 00266C88): stub
012c:fixme:ntdll:NtQuerySystemInformation info_class
SYSTEM_PERFORMANCE_INFORMATION
012c:err:d3d_sync:wined3d_cs_create Forcing serialization of all command
streams.
012c:err:d3d_sync:wined3d_cs_create Forcing serialization of all command
streams.
012c:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi
sound output probably won't work.
--
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=52871
Bug ID: 52871
Summary: oleaut32:vartest has failures in Wine in the Arabic
and Hebrew locales
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: oleaut32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
oleaut32:vartest has failures in Wine in the Arabic and Hebrew locales:
vartest.c:3130: Test failed: VarAbs: expected 0x0,5,1.1, got
0x80020005,8,-1.#IND
vartest.c:4073: Test failed: wrong result 80020005
vartest.c:4188: Test failed: wrong result 80020005
vartest.c:4312: Test failed: wrong result 80020005
vartest.c:4444: Test failed: wrong result 80020005
vartest.c:7785: Test failed: VarCmp: 2|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 3|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 4|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 5|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 6|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 7|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 2|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 3|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 4|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 5|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 6|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 7|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 11|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 14|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 17|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 8|0x8000, 20|0x8000: Expected 0x0, got 0x2
vartest.c:7785: Test failed: VarCmp: 11|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 14|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 17|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 20|0x8000, 8|0x8000: Expected 0x2, got 0x0
vartest.c:7785: Test failed: VarCmp: 22|0x8000, 8|0x8000: Expected 0x2, got 0x0
https://test.winehq.org/data/patterns.html#oleaut32:vartest
These failures happen in test_VarAbs(), test_VarFix(), test_VarInt(),
test_VarNeg(), test_VarRound() and test_VarCmp() but a bisect shows that they
all start with this commit:
commit ba43e4cfca97a9bba3e6575af82acbf011685862
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Tue Mar 29 22:11:32 2022 +0200
kernelbase: Reimplement number formatting values in GetLocaleInfoW/Ex using
the locale.nls data.
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
It should be noted that this commit did fix another set of oleaut32:vartest
failures (which were likely introduced by 2cd33e6b0fd6).
--
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=52865
Bug ID: 52865
Summary: windows.media.speech:speech has a Windows 10
1507-specific failure
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
IAsyncOperation_SpeechRecognitionCompilationResult_get_Completed() unexpectedly
returns a handle on Windows 10 1507:
speech.c:979: Test failed: Handler had value 0029FC20.
https://test.winehq.org/data/patterns.html#windows.media.speech:speech
Unsurprisingly a bisect shows that the failures started with the commit that
introduced this new test:
commit 4926bb148b049f1b60e57091f4aa87a3957aa69e
Author: Bernhard Kölbl <besentv(a)gmail.com>
Date: Wed Apr 6 18:28:41 2022 +0200
windows.media.speech: Add tests for IAsyncOperation.
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com>
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=52845
Bug ID: 52845
Summary: Recent versions of chromium have broken sandbox again
Product: Wine
Version: 7.6
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Somewhere between
chromium-946247 (commit 4e7609b62147866fb7b226fd6efbe1ae4d2f1aca
and
chromium-946263 (commit 1bd694702105072e57b980512130a3212675ec19)
the sandbox got changes so it doesn't work under wine anymore. Result is a
black screen and soon a crash.
This affects both 32bit and 64bit chromium.
Note: chromium should be located inside the WINEPREFIX, it won't run outside!
Nightly versions to test with (chrome-win.zip)
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.h…https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.h…
I tried to build from source on my Win11 machine, but those versions don't run
under wine at all, even if compiling the same commit as the nightly versions.
--
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=52554
Bug ID: 52554
Summary: Serbian locale mapping cause crash on multiple
installshield wizards
Product: Wine
Version: 7.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: lei.pero(a)gmail.com
Distribution: ---
Since commits:
kernelbase: Map LANG_SERBIAN_NEUTRAL in ConvertDefaultLocale().
f51e44c1802338cdd41b38efe2757b642b619d6f
ntdll: Map LANG_SERBIAN_NEUTRAL in RtlLocaleNameToLcid().
db3e08770fe9bfb6f06a71761e48a40fe9764058
starting with wine-6.2 - when using locale sr_RS.UTF-8, some (specifically
older) installers do crash, for example 3DMark03, preventing installation,
passing LANG=en_US.UTF-8 EV works as expected with no crash.
Reverting those two specific commits solves the issue. Or changing line in:
dlls/ntdll/locale.c
from:
case MAKELANGID( LANG_SERBIAN, SUBLANG_NEUTRAL ):
*lcid = LANG_SERBIAN_NEUTRAL;
to:
case MAKELANGID( LANG_SERBIAN, SUBLANG_NEUTRAL ):
*lcid = MAKELCID( 0x02, SORT_DEFAULT );
solves the issue as well, but that basically renders all those commits useless
I assume?
On the topic, but unrelated to this bug, I can see changes in
dlls/kernel32/nls/srl.nls, with commit:
kernel32: Update sr-Latn locale definition.
3b3dfda59951b0f42e297f2b9a31ded04a98d4b4
that doesn't seem right to me, srl.nls should stand for Serbian Latin I assume,
srm.nls probably stands for m as Montenegro. So, if I'm correct, addition of
srm.nls with commit:
kernel32: Add sr-Latn-RS locale definition.
db2666e9d20f80968ff6b4b0ea1deae20c3c368b
should have changes made to srl.lns.
I don't know how this is solved for English for example, since neutral should
have a specific code not related to any country where language is used (e.g.
US, UK, CA etc.), and the code it seems to be sr_CS as it is changed for sr_RS
latin locale, where it shouldn't be changed I assume.
--
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=51181
Bug ID: 51181
Summary: d3d10core:d3d10core fails systematically on AMD GPUs
Product: Wine
Version: 6.8
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
test_instanced_draw() fails systematically in d3d10core:d3d10core on AMD GPUs
(and sometimes there is a crash that follows):
d3d10core.c:9275: Test failed: Got 0xfff0f010, expected 0xff80f010 at (160, 0),
sub-resource 0.
d3d10core.c:9275: Test failed: Got 0xfff0f040, expected 0xff80f040 at (240, 0),
sub-resource 0.
d3d10core.c:9275: Test failed: Got 0xffaaaacc, expected 0xffbbaacc at (480, 0),
sub-resource 0.
d3d10core.c:9275: Test failed: Got 0xffaaaa90, expected 0xffbbaa90 at (560, 0),
sub-resource 0.
Notice how this failure does not happen on the machines that have other GPUs
such as cw-gtx560 or QEmu VMs, and how this does not depend on the Windows
version or Radeon driver version for that matter:
https://test.winehq.org/data/patterns.html#d3d10core:d3d10core
So it looks like the test expects fails to account for the Radeon driver
results for some reason.
The commit that introduced this test is:
commit fcd549345d96109179b125d31baf9e9073ecf643
Author: Józef Kucia <jkucia(a)codeweavers.com>
AuthorDate: Mon Nov 6 10:55:20 2017 +0100
Commit: Alexandre Julliard <julliard(a)winehq.org>
CommitDate: Mon Nov 6 19:37:09 2017 +0100
d3d10core/tests: Add test for SV_InstanceID.
Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>
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=43995
Bug ID: 43995
Summary: Uplay - Assassin's Creed 4 Black Flag won't start
Product: Wine-staging
Version: 2.20
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mi.bar.2001(a)gmail.com
CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de,
sebastian(a)fds-team.de
Distribution: ---
Created attachment 59652
--> https://bugs.winehq.org/attachment.cgi?id=59652
Terminal log from `wine AC4BFSP.exe`
After clicking the "Play" button in Ubisoft Game Launcher (or launching `wine
AC4BFSP.exe`), a window pops up informing, that the game is starting, but it
disappears and the game doesn't launch. I don't have the Steam version, just
the Uplay one.
I've set Windows version to XP, wineprefix is 32-bit.
Wine version will probably be visible when I post this, but I'm going to
mention it just to be safe. Using Wine 2.20 staging
--
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.