http://bugs.winehq.org/show_bug.cgi?id=17973
Summary: explorer: Spaces in desktop title on CLI cause both
wrong window title and command
Product: Wine
Version: 1.1.13
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: programs
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: shacklein(a)gmail.com
When using the form:
$ wine explorer /desktop=Title,WxH program.exe
Title currently cannot contain spaces. Example:
$ wine explorer /desktop=My\ Program,800x600 myprogram.exe
This correctly detects the size 800x600 for the virtual desktop, but it sets
the title of the window to "My" and tries to run "Program" as the command line.
I've submitted a patch to wine-patches that fixes this problem (and afaik,
doesn't introduce any new ones), though I'm not sure if it's really "neat"
enough.
http://www.winehq.org/pipermail/wine-patches/2009-March/070776.html
So far, I've had no feedback about it. At the least, I'd like to be told why
it's not suitable for inclusion, or if there's any cleaning up I need to do to
it :)
--
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.
https://bugs.winehq.org/show_bug.cgi?id=53025
Bug ID: 53025
Summary: Port Royale 4 crashes with
IDXGISwapChain4_CheckColorSpaceSupport
Product: Wine
Version: 7.9
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: berillions(a)gmail.com
Distribution: ---
Created attachment 72397
--> https://bugs.winehq.org/attachment.cgi?id=72397
IDXGISwapChain4_CheckColorSpaceSupport backtrace -
Hello,
I bought Port Royale 4 on GoG and when i try to launch it with OpenGL/Vulkan
renderer, the game crashes.
I have a backtrace about dxgi error as you can see in the attached file.
No issue with DXVK.
--
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=46008
Bug ID: 46008
Summary: Support CUDA 10.0 compiled apps like new mfaktc v0.21
binary..
Product: Wine-staging
Version: 3.18
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: rtfss1(a)gmail.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 62580
--> https://bugs.winehq.org/attachment.cgi?id=62580
output
Hi,
just downloaded new mfaktc binary compiled with CUDA10 which adds support for
new Nvidia Turing GPUs like RTX 2080..
from here:
https://www.mersenneforum.org/mfaktc/mfaktc-0.21/mfaktc-0.21.win.cuda100.zip
the app is a "simple" command line app so it should work OK with wine if it
wasn't compiled with new CUDA10..
on Windows works ok but using latest Wine-Staging 3.18 (as staging is still
required for CUDA support right?) no..
the app isn't detecting runtime version OK:
CUDA runtime version 13697.32
CUDA driver version 10.0
ERROR: CUDA runtime version must match the CUDA toolkit version used during
compile!
full log 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=3548
mirh <mirh(a)protonmail.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mirh(a)protonmail.ch
--
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=53024
Bug ID: 53024
Summary: wine-7.9 build fails in x86_64 Ubuntu 22.04
Product: Wine
Version: 7.9
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: winmm&mci
Assignee: wine-bugs(a)winehq.org
Reporter: dimesio(a)earthlink.net
Distribution: ---
Created attachment 72396
--> https://bugs.winehq.org/attachment.cgi?id=72396
OBS log for x86_64 Ubuntu 22.04 build failure
The build succeeded in i586 but failed in x86_64 Ubuntu 22.04. Builds for all
other Ubuntu versions succeeded.
[ 564s] /usr/bin/x86_64-w64-mingw32-dlltool: failed to open temporary tail
file: winmm_dll_t.o: No such file or directory
[ 564s] tools/winebuild/winebuild -b x86_64-w64-mingw32 -w --implib -o
dlls/usp10/libusp10.cross.a --export dlls/usp10/usp10.spec
[ 564s] winebuild: /usr/bin/x86_64-w64-mingw32-dlltool failed with status 1
[ 564s] make[1]: *** [Makefile:139207: dlls/winmm/libwinmm.delay.a] Error 1
[ 564s] make[1]: *** Waiting for unfinished jobs....
[ 565s] make[1]: Leaving directory '/usr/src/packages/BUILD'
[ 565s] dh_auto_build: error: make -j8 returned exit code 2
--
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=53023
Bug ID: 53023
Summary: MinecraftInstaller
Product: Wine
Version: 7.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jon9097(a)gmail.com
Distribution: ---
Created attachment 72394
--> https://bugs.winehq.org/attachment.cgi?id=72394
Log
The Minecraft Installer doesn't work. It won't start. I'm attaching the logs.
--
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=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.