https://bugs.winehq.org/show_bug.cgi?id=52188
Bug ID: 52188
Summary: Could not load file or assembly
'Windows.Foundation.UniversalApiContract
Product: Wine
Version: 6.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: julianhoyos94(a)gmail.com
Distribution: ---
hi everybody, i am creating scrpit for use xboxgamepass on linux, im very close
but i have this error
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or
assembly 'Windows.Foundation.UniversalApiContract, Version=7.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. file not
found
I would like to know if anyone has already experienced this problem,
and if they have solved it since I looked on the internet, but I can't find the
problem reported in wine.
and I'm also looking for what it is, and I can't find anything about what
program or what the error is based on, apparently it is part of Windows
development libraries, I thought it was through .net but apparently it has
nothing to do with it.
--
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=53011
Bug ID: 53011
Summary: Multithreaded compilation fails sometimes due to race
conditions
Product: Wine
Version: 7.7
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: ---
Created attachment 72380
--> https://bugs.winehq.org/attachment.cgi?id=72380
Sample of the two broken files
Sometimes the compilation fails with a message like the following:
/usr/bin/i686-w64-mingw32-dlltool: dlls/mfplat/libmfplat.cross.a: error reading
mfplat_dll_t.o: No such file or directory
/usr/bin/i686-w64-mingw32-dlltool: dlls/rpcrt4/librpcrt4.cross.a: error reading
rpcrt4_dll_h.o: file truncated
/usr/bin/i686-w64-mingw32-dlltool: dlls/rpcrt4/librpcrt4.delay.a: error reading
rpcrt4_dll_t.o: No such file or directory
/usr/bin/i686-w64-mingw32-dlltool: bfd_open failed reopen stub file:
wintrust_dll_s00009.o: No such file or directory
Or sometimes files are broken:
/usr/lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld:
dlls/iphlpapi/libiphlpapi.delay.a: error adding symbols: file in wrong format
/usr/lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld:
dlls/wintrust/libwintrust.cross.a: error adding symbols: file format not
recognized
If the file doesn't exist / is truncated, then trying again usually makes it
work. For broken files, they need to be deleted and then you can try again.
I usually compile wine like this:
ALLFLAGS="-g -O0"
PKG_CONFIG_PATH=/usr/lib32/pkgconfig CC="ccache gcc" CFLAGS="$ALLFLAGS"
CROSSCC="ccache i686-w64-mingw32-gcc" CROSSCFLAGS="$ALLFLAGS"
../wine-git/configure --without-cups --enable-silent-rules
make -j15 -sw
I don't think ccache causes this, but possibly it exacerbates it..
--
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=52969
Bug ID: 52969
Summary: mshtml:script fails on up-to-date Windows 8.1 machines
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: mshtml
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
mshtml:script fails on up-to-date Windows 8.1 machines:
script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [0] got
0.00"
script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [1] got
1,234.50"
script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [2] got
-1,337.73"
script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [3] got
-0.01"
script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [5] got
0.00"
script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [6] got
99.00"
script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [7] got
99.00"
script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [8] got
65,536.50"
script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: called
on string threw 2148144009"
script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: called
on undefined threw 2148144009"
script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: called
on nullDisp threw 2148144009"
https://test.winehq.org/data/patterns.html#mshtml:script
These failures only happen on the cw-gtx560 and cw-rx460 Windows 8.1 machines.
I suspect this is because these have more recent Windows updates than the
TestBot's w8 and w864 machines (see bug 52858). More specifically cw-rx460 has
had more recent updates than cw-gtx560 for quite some time and I further
updated both on 2022-05-02.
I further plan to update the TestBot's VM (the rationale being that Windows 8.1
is old and we really only care about the latest version) which should make it
easier to debug. In the meantime this does seem like a regression.
commit 8aefdf48f9846e05aeef3c7ce2374401982b98b4
Author: Gabriel Ivăncescu <gabrielopcode(a)gmail.com>
Date: Tue May 3 18:17:06 2022 +0300
jscript: Implement Number.prototype.toLocaleString.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com>
Signed-off-by: Jacek Caban <jacek(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=52892
Bug ID: 52892
Summary: The 64-bit ntdll:thread fails on w7pro64 and w864
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 64-bit ntdll:thread fails on w7pro64 and w864:
thread.c:153: Test failed: Multiple threads have TEB 000007FFFFFDC000.
https://test.winehq.org/data/patterns.html#ntdll:thread
The failure is hard to reproduce but the test was introduced by this commit:
commit 6d4ec1255acceec7152ed98764ee29991ac04f10
Author: Brendan Shanks <bshanks(a)codeweavers.com>
AuthorDate: Mon Apr 18 11:25:10 2022 -0700
Commit: Alexandre Julliard <julliard(a)winehq.org>
CommitDate: Mon Apr 18 21:48:15 2022 +0200
ntdll/tests: Test that threads have unique TEBs.
Signed-off-by: Brendan Shanks <bshanks(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
Specifically the issue is with the line below:
+ ok( teb1 != teb2, "Multiple threads have TEB %p.\n", teb1 );
I think the issue is that there is no guarantee that the two test threads are
running at the same time. I suspect that sometimes what happens is this [1]:
* status = pNtCreateThreadEx( &threads[0], ... &teb1, ... );
A new TEB is allocated, the first thread starts, sets teb1 and terminates at
which time its TEB is freed.
* status = pNtCreateThreadEx( &threads[1], ... &teb2, ... );
A new TEB is allocated, hey there's a fresh TEB that has just bee freed! [2].
The second thread starts and sets teb2.
* WaitForMultipleObjects( 2, threads, TRUE, INFINITE );
Wait for both threads.
* ok( teb1 != teb2, "Multiple threads have TEB %p.\n", teb1 );
Hey, both threads used the same TEB!
But did they do so at the same time?
One hacky fix would be to at a small sleep in the test threads but that's
introducing race conditions. A better fix would be for the main thread to tell
the test threads when they can exit through some synchronization object.
[1] This may be tied to how the scheduler behaves which may limit the issue to
specific Windows versions.
[2] And that's probably tied to how the memory allocator behaves: more memory
locality or less chance of overwriting (incorrectly) still in use memory. Again
this could limit the issue to some Windows 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=52761
Bug ID: 52761
Summary: mscoree:mscoree test fails without a display or
console
Product: Wine
Version: 7.5
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: madewokherd(a)gmail.com
Distribution: ---
The mscoree:mscoree test fails if you run it like this:
$ DISPLAY= wine mscoree_test.exe mscoree </dev/null >log 2>&1
Without the DISPLAY=, it makes a bunch of console windows. That doesn't seem to
happen on Windows, but that could be caused by our csc.exe.
--
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=52937
Bug ID: 52937
Summary: msvcr110:msvcr110 fails on Windows with the UTF-8
codepage
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: msvcrt
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
msvcr110:msvcr110 fails on Windows with the UTF-8 codepage:
msvcr110.c:135: Test failed: expected syr-SY, got
LC_COLLATE=syr-SY;LC_CTYPE=EN-US;LC_MONETARY=syr-SY;LC_NUMERIC=syr-SY;LC_TIME=syr-SY
https://test.winehq.org/data/patterns.html#msvcr110:msvcr110
Note that the LC_CTYPE value in the above string corresponds to the last value
it was set to. So if one tests fr-FR right before syr-SY the string contains
LC_CTYPE=fr-FR. This is also why the en-US case is weird.
Furthermore with a non-UTF-8 codepage setlocale() does return "syr-SY".
So it looks like:
1. msvcr110 returns a long string specifying the details of the locale settings
whenever they have different values.
2. msvcr110 does not support setting LC_CTYPE to syr-SY, but only when the
codepage is UTF-8 for whatever reason.
--
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=51298
Bug ID: 51298
Summary: d3d8:visual: lighting_test() fails on Windows 10 >=
2004
Product: Wine
Version: 6.10
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
d3d8:visual has a failure in lighting_test() on Windows 10 >= 2004:
https://test.winehq.org/data/patterns.html#d3d8:visual
visual.c:544: Test failed: Lit quad with singular world matrix has color
0x00000000.
This happens on cw-rx460, cw-gtx560 and on those TestBot VMs that run the
32-bit tests. That means it's not a VM or graphics driver issue but a Windows
version one.
The test was introduced by this commit:
commit 589f1072df9535104c074e5382ef7d8ce28f0f33
Author: Matteo Bruni <mbruni(a)codeweavers.com>
AuthorDate: Tue Apr 21 15:11:19 2015 +0200
d3d8/tests: Add a lighting test with non-affine worldview matrix.
--
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=51104
Bug ID: 51104
Summary: mf:mf crashes on Windows + NVidia
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mfplat
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
mf:mf crashes on the cw-gtx560 and cw-rx460 machines but not on the TestBot VMs
(except w7u-2qxl, but that's a different crash).
https://test.winehq.org/data/patterns.html#mf:mf
The crash happens on the same test_evr() line from Windows 8.1 to Windows 10
2009:
hr = MFGetService((IUnknown *)stream_sink2, &MR_VIDEO_ACCELERATION_SERVICE,
&IID_IMFVideoSampleAllocator,
(void **)&allocator);
A bisect shows that the commit causing the crash is not the one that added this
line but the one below:
commit 430c179fe86dd7f9b3ddfb6ef30f6359633ef0b8
Author: Nikolay Sivov <nsivov(a)codeweavers.com>
Date: Fri Oct 9 13:54:38 2020 +0300
mf/evr: Set stream media type to the mixer.
Signed-off-by: Nikolay Sivov <nsivov(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.
http://bugs.winehq.org/show_bug.cgi?id=34782
Bug #: 34782
Summary: crypt32/chain tests crash with gcc-4.8.1 (win64)
Product: Wine
Version: 1.7.4
Platform: x86
OS/Version: Linux
Status: NEW
Keywords: download, source, win64
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
Classification: Unclassified
Running: crypt32:chain (3 of 15)
fixme:crypt:CertVerifyCertificateChainPolicy unimplemented for 0
fixme:crypt:CRYPT_CriticalExtensionsSupported unsupported critical extension
"1.2.3"
fixme:crypt:CRYPT_CriticalExtensionsSupported unsupported critical extension
"1.2.3"
fixme:crypt:CRYPT_CriticalExtensionsSupported unsupported critical extension
"1.2.3"
wine: Unhandled page fault at address 0x7f579f85aa74 (thread 0043), starting
debugger...
fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported constant (parameter)
pEncodePara in function
fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported constant (parameter)
dwFlags in function
fixme:dbghelp_dwarf:dwarf2_parse_subprogram_block Unhandled Tag type 0x15 at
ctx(0x23aa10,L"kernel32<elf>"), for debug_info(abbrev:0x7b3c80,symt:(nil))
fixme:dbghelp_dwarf:dwarf2_parse_subprogram_block Unhandled Tag type 0xf at
ctx(0x23aa10,L"kernel32<elf>"), for debug_info(abbrev:0x7b3c80,symt:(nil))
it works with gcc-4.7.3. I'll bisect gcc.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.
http://bugs.winehq.org/show_bug.cgi?id=28220
Summary: kernel32/process.ok: test fails when redirected
Product: Wine
Version: 1.3.27
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
It's not uncommon to want to do
make test > log 2>&1
but if you do this, kernel32/process.ok will fail with
../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p
kernel32_test.exe.so process.c && touch process.ok
wine: cannot find L"C:\\windows\\system32\\doesnotexist.exe"
wine: cannot find L"C:\\windows\\system32\\does.exe"
process.c:1344: Test failed: Opening ConOut
process.c:1347: Test failed: Getting sb info
process.c:1348: Test failed: Getting console modes
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.