https://bugs.winehq.org/show_bug.cgi?id=5162
--- Comment #52 from Jactry Zeng <jactry92(a)gmail.com> ---
Thanks to Huw's work, TxGetNaturalSize and TxDraw now are implemented in Wine
6.5.
It might be worth retesting these applications and file separate bugs for their
following issue.
--
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=50862
Bug ID: 50862
Summary: [Regression] Steam fails to start
Product: Wine
Version: 6.4
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
CC: julliard(a)winehq.org
Regression SHA1: 47fed8f5bc89344af054b70c2d3a7bea02b2113c
Distribution: ---
0188:err:module:import_dll Library SDL2.dll (which is needed by L"C:\\Program
Files (x86)\\Steam\\bin\\gldriverquery.exe") not found
0188:err:module:LdrInitializeThunk Importing dlls for L"C:\\Program Files
(x86)\\Steam\\bin\\gldriverquery.exe" failed, status c0000135
0190:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0190:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0190:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0190:fixme:ver:GetCurrentPackageId (000000000022FDA0 0000000000000000): stub
0198:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0198:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0198:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0198:fixme:ver:GetCurrentPackageId (0033FEA4 00000000): stub
0024:fixme:imm:ImmReleaseContext (000100B4, 05BD2238): stub
0024:fixme:dwmapi:DwmExtendFrameIntoClientArea (000400B2, 0033E2A8) stub
013c:fixme:file:NtLockFile I/O completion on lock not implemented yet
0024:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\C:\\Program Files
(x86)\\Steam\\bin\\cef\\cef.win7x64\\steamwebhelper.exe"
0024:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\C:\\Program Files
(x86)\\Steam\\bin\\cef\\cef.win7x64\\steamwebhelper.exe"
0024:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\C:\\Program Files
(x86)\\Steam\\logs\\cef_log.txt"
0024:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\C:\\Program Files
(x86)\\Steam\\logs\\cef_log.txt"
01a4:err:module:import_dll Library SDL2.dll (which is needed by L"C:\\Program
Files (x86)\\Steam\\bin\\cef\\cef.win7x64\\steamwebhelper.exe") not found
01a4:err:module:import_dll Library libcef.dll (which is needed by L"C:\\Program
Files (x86)\\Steam\\bin\\cef\\cef.win7x64\\steamwebhelper.exe") not found
01a4:err:module:LdrInitializeThunk Importing dlls for L"C:\\Program Files
(x86)\\Steam\\bin\\cef\\cef.win7x64\\steamwebhelper.exe" failed, status
c0000135
--
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=45567
Bug ID: 45567
Summary: League of Legends 8.12+ fails to start a game
(anticheat engine, validation of WoW64 syscall
dispatcher)
Product: Wine
Version: 3.13
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: z.figura12(a)gmail.com
Distribution: ---
Diagnosed by Andrew Wesie; partially split off from bug 45327.
The game inspects the %cs register to determine if it is running under WoW64.
Since Linux 32-bit code segment is the same as the
WoW64 32-bit code segment, 0x23, the anti-cheat will expect to be in a WoW64
environment regardless of whether the prefix is 32- or 64-bit.
Consequently the game will try to use the Wow64Transition export if it is
available, or otherwise request the module name of the address contained at the
WOW32Reserved TEB field (i.e. %fs:0xc0), and verifies that the latter matches
wow64cpu.dll.
This can be solved either by moving the syscall dispatcher to wow64cpu.dll, or
by implementing Wow64Transition.
--
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=37983
Bug ID: 37983
Summary: Jedi Knight: Dark Forces II (GOG.com version) - music
doesn't work
Product: Wine
Version: 1.7.35
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: rixa(a)cs.tut.fi
Distribution: ---
The game originally used to have background music on CD audio tracks. The
recent GOG.com release includes those tracks in .ogg format, along with what
seems to be some sort of a hack to play them through a custom winmm.dll in the
game directory.
The music does not play.
For the included winmm.dll to do anything, an override of "winmm
(native,builtin)" seems like a logical step. Indeed, it was reported on the
GOG.com forums that this gets the music working on Crossover, and I used the
trial version to verify that this is indeed the case.
But if I do the same on Wine, the game doesn't start anymore. It just dies
with:
err:seh:raise_exception Exception frame is not in stack limits => unable to
dispatch exception.
I tried to trace it down to other overrides that crossover sets by default, but
it would still work even if I removed them all. It would even keep working if I
replaced the entire drive_c there with the one from my wineprefix where it
doesn't work, so it probably does not have to do with any of the pre-installed
software, nor an installation broken for whatever reason. Using wine on the
prefix installed in crossover didn't work any better either.
In addition to a clean unpatched wine 1.7.35 that I compiled myself, I tried
multiple versions of wine from PlayOnLinux but none of them started the game
with the override in place; each died with the same message.
Without the override the game is still very playable, just has no background
music.
Xubuntu 14.10, nvidia 331.113.
--
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=33375
Bug #: 33375
Summary: Cannot test dlls with dashes in their name
Product: Wine
Version: 1.5.19
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: build-env
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: fgouget(a)codeweavers.com
Classification: Unclassified
Created attachment 44165
--> http://bugs.winehq.org/attachment.cgi?id=44165
Patch to reproduce this bug
No conformance test can be written for dlls that have a dash in their name.
These will first run into a build error:
echo "api-ms-win-security-base-l1-1-0_test.exe TESTRES
\"api-ms-win-security-base-l1-1-0_test-stripped.exe.so\"" |
LD_LIBRARY_PATH="../../../libs/wine:$LD_LIBRARY_PATH" ../../../tools/wrc/wrc
--nostdinc --po-dir=../../../po -m32 -I. -I. -I../../../include
-I../../../include -DWINE_STRICT_PROTOTYPES -DWINE_NO_NAMELESS_EXTENSION
-DWIDL_C_INLINE_WRAPPERS -o
../../../programs/winetest/api-ms-win-security-base-l1-1-0_test.res
:1:5: Error: syntax error
What surprises me is that the dot on the 'TESTRES' left-hand causes no problem
while the dashes do. I tried quoting that string but it did not help.
The next problem is that if the TESTRES left-hand is modified to work around
that issue, then winetest.exe will not be able to find the corresponding dll
anymore and will thus skip the test. Filtering the list of tests to run based
on the command line will likely be broken too.
I'm attaching a patch to reproduce this issue.
--
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=50826
Bug ID: 50826
Summary: regression: adk81setup fails with The file
C:\windows\mono\mono-2.0\lib/mscorlib.dll is an
invalid CIL image
Product: Wine
Version: 6.2
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
Distribution: ---
Regression caused by:
commit 86947587d206a0a95b4ac2c5458f8465ee4c371d
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Wed Mar 17 10:38:43 2021 +0100
server: Remove the redundant cpu field in the PE image information.
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=50721
Bug ID: 50721
Summary: IDA Pro 7.5: Lumina can't contact server, complains
about Schannel security attributes
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: secur32
Assignee: wine-bugs(a)winehq.org
Reporter: thotypous(a)gmail.com
Distribution: ---
Using Wine Staging, IDA Pro fails to contact the Lumina server when trying to
do any operation that depends on it (e.g. Lumina menu -> Pull All Metadata).
The IDA's output window shows "lumina: Schannel does not support the requested
security attributes"
By tracing secur32, it turns out that InitializeSecurityContextA is being
called with fContextReq flags ISC_REQ_EXTENDED_ERROR and
ISC_REQ_MANUAL_CRED_VALIDATION, which are not handled by Wine:
00f4:trace:secur32:InitializeSecurityContextA 0x3436e40 0x3436e50 (null)
0x0008c110 0 0 0x529b58 0 (nil) 0x529af8 0x3436e9c (nil)
Now regarding each flag:
1. ISC_REQ_EXTENDED_ERROR: according to MSDN, this flag means "When errors
occur, the remote party will be notified."
However, modern TLS does not have any mechanism to notify the remote party
about errors. Thus it seems unlikely that this flag causes any difference in
behavior, at least when the remote party is not running Microsoft's TLS
implementation.
When researching about the flag, I found
https://mskb.pkisolutions.com/kb/975858, which states Windows 7 used to ignore
this flag, but since it caused issues with some applications, they changed
schannel to return ISC_RET_EXTENDED_ERROR (via pfContextAttr) when the flag is
set. The KB does not describe any other change deployed by the upgrade. This
fact further supports the hypothesis that the flag does not change the behavior
of the protocol.
In short, up-to-date Windows 7 seems to just return ISC_RET_EXTENDED_ERROR when
ISC_REQ_EXTENDED_ERROR is set, but otherwise ignores it.
2. ISC_REQ_MANUAL_CRED_VALIDATION: according to MSDN, this flag means "By
default, Schannel validates the server certificate by calling the
WinVerifyTrust function; however, if you have disabled this feature using the
ISC_REQ_MANUAL_CRED_VALIDATION flag, you must validate the certificate provided
by the server that is attempting to establish its identity."
However, Wine currently does not carry automatic server certificate validation
at all. The OSX implementation always calls "SSLSetEnableCertVerify(s->context,
FALSE)" to disable it explicitly. The GnuTLS implementation never calls
"gnutls_session_set_verify_cert", which would be required to enable server
certificate validation.
Strictly speaking, the current implementation of Schannel in Wine is insecure,
but fixing it would require more extensive changes to the code and could cause
regression bugs with other applications. Thus, I argue it should be dealt with
by another bug entry and fixed by another patch.
Therefore, the attached patch restricts itself to return
ISC_RET_MANUAL_CRED_VALIDATION when ISC_REQ_MANUAL_CRED_VALIDATION is set, and
to better document the current situation in the code.
--
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=45032
Bug ID: 45032
Summary: WineTest does not run the vcomp tests
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: vcomp
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
So WineTest is not running the vcomp tests. What happens is this:
* It parses the vcomp_test.exe filename and concludes that this tests the vcomp
dll.
* It does a LoadLibraryExA("vcomp.dll", NULL, LOAD_LIBRARY_AS_DATAFILE) which
fails (as expected) and concludes that the dll is missing:
vcomp=dll is missing
* Since the dll is missing WineTest skips the vcomp tests.
According to Dan Kegel (see bug 31609) this is a manifest / activation context
issue and he sent a patch for it [1]. However the patch was for the TestBot
[2], not WineTest, and as far as I can tell it's not working.
Furthermore WineTest already has activation context code that seems equivalent
to Dan Kegel's patch.
Note that not all VMs have vcomp.dll. Based on the current results the 32 bit
dll is present on the TestBot's w2000pro, wxppro, w2003std, wvistau64*,
w2008s64, w8, w864 VMs and the 64 bit one is present on wvistau64, w2008s64 and
w864.
Note that some online resources seem to imply that vcomp.dll is present in the
Visual C++ 2005 redistributable (and VC++ 2005 was indeed installed on all the
VMs that have vcomp.dll except w2008s64 (though maybe it was installed and it
was not written down)). Some VMs seem to have other versions such as
vcomp90.dll but not vcomp.dll.
[1] https://bugs.winehq.org/show_bug.cgi?id=31609https://www.winehq.org/pipermail/wine-patches/2012-September/117631.html
[2] Paradoxically the TestBot has no problem running the vcomp tests now that
they dynamically load the vcomp dll. That's because the TestBot makes no
assumption based on the executable filename since one can upload test binaries
that don't follow any naming scheme. So now that the test dynamically loads
vcomp.dll the TestBot cannot check for 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=50836
Bug ID: 50836
Summary: dxva2api.h does not compile as C++
Product: Wine
Version: 6.4
Hardware: x86-64
OS: Windows
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: dxva2
Assignee: wine-bugs(a)winehq.org
Reporter: bjoern(a)hazardy.de
The functions do not compile with g++ 10:
error: invalid conversion from 'void*' to 'DXVA2FixedToFloat::<unnamed
struct>*' [-fpermissive]
The functions are broken since
https://source.winehq.org/git/wine.git/commitdiff/6aeb891d529d821fa62e26c17…
On MinGW it was fixed once, but now they reimport the library from wine and it
broke in
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/c0fa4d755413c4541bdad32f07…
again.
This hinders compiling Qt on Windows with GCC.
--
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.