[Bug 51465] New: EVE Online Launcher Crashes Due to Missing syscalls in Windows Credential Manager
https://bugs.winehq.org/show_bug.cgi?id=51465
Bug ID: 51465 Summary: EVE Online Launcher Crashes Due to Missing syscalls in Windows Credential Manager Product: Wine Version: 6.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: algebro@tuta.io Distribution: ---
Created attachment 70306 --> https://bugs.winehq.org/attachment.cgi?id=70306 Crash on authentication
As of version 1917874 of the EVE Online launcher, the application crashes when trying to log in. According to the developers, they moved to a new credential management solution (involving https://github.com/frankosterfeld/qtkeychain and the Windows Credential Store), and they said that Wine currently doesn't implement the needed syscalls for this to function.
I've attached a stacktrace which looks like it crashes somewhere in cryptopp, but I haven't been able to figure out much by debugging (winedbg doesn't see any of those function addresses as valid, and I haven't been able to map them to functions in a disassembler). Let me know if I can provide any more information that would be helpful.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #1 from algebro@tuta.io --- Relevant comment from the developers: https://forums.eveonline.com/t/new-launcher-new-linux-error/319782/104
https://bugs.winehq.org/show_bug.cgi?id=51465
info@ppfeufer.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |info@ppfeufer.de
https://bugs.winehq.org/show_bug.cgi?id=51465
Kim Malmo berencamlost@msn.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |berencamlost@msn.com
https://bugs.winehq.org/show_bug.cgi?id=51465
Anton Vorobyov phoenix@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |phoenix@mail.ru
--- Comment #2 from Anton Vorobyov phoenix@mail.ru --- Can confirm that I am also affected by this issue. There are possible workarounds for now, but in the long run Wine needs to support those APIs in order to be able to launch EVE online.
https://bugs.winehq.org/show_bug.cgi?id=51465
Kuran stannum.k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stannum.k@gmail.com
--- Comment #3 from Kuran stannum.k@gmail.com --- Confirm this bug. Also informing that AppDB application is not specified but as mentioned in bug description this is: EVE Online - https://appdb.winehq.org/objectManager.php?sClass=application&iId=2249
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #4 from algebro@tuta.io --- I've been doing more debugging, and there seem to be a couple of issues going on (all are happening in cryptopp so far). If we figure out it's some sort of cryptopp bug then I'll close this ticket and report it there, but at least one of the problems seems to be something with allocation, which could be wine related.
Issue #1:
the game crashes at https://github.com/weidai11/cryptopp/blob/2d8e4680855691657cb8029ae5cb05c67c... after checking the result value of a FIPS self-test. From what I can tell, DoPowerUpSelfTest() in fipstest.cpp is never called to run the tests, so this fails and it throws an exception. Just as a test case, I patched the cryptopp.dll that shipped with the launcher to remove that check and it gets past it just fine.
Issue #2:
We're crashing in SetNewAndDeleteFunctionPointers() in dll.cpp (https://github.com/weidai11/cryptopp/blob/2d8e4680855691657cb8029ae5cb05c67c...). For some reason GetModuleHandle("msvcrtd") or GetModuleHandle("msvcrt") are failing. Anyone know what could cause that?
https://bugs.winehq.org/show_bug.cgi?id=51465
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|EVE Online Launcher Crashes |EVE Online launcher crashes |Due to Missing syscalls in | |Windows Credential Manager | CC| |z.figura12@gmail.com
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- "syscalls" does not mean what that employee thinks it means.
Anyway:
(In reply to algebro from comment #4)
Issue #2:
We're crashing in SetNewAndDeleteFunctionPointers() in dll.cpp (https://github.com/weidai11/cryptopp/blob/ 2d8e4680855691657cb8029ae5cb05c67c6dc654/dll.cpp#L121). For some reason GetModuleHandle("msvcrtd") or GetModuleHandle("msvcrt") are failing. Anyone know what could cause that?
Sounds kind of like bug 27827; the application is expecting msvcrt to already be loaded as a dependency of some system DLL.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #6 from algebro@tuta.io ---
Sounds kind of like bug 27827; the application is expecting msvcrt to already be loaded as a dependency of some system DLL.
Thanks! Is there a way to load it with winedbg just to verify?
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #7 from algebro@tuta.io --- Actually, it looks like msvcrt should already be loaded (I got this when launching the program with WINEDEBUG=+loaddl:
0048:trace:loaddll:build_module Loaded L"C:\windows\system32\msvcrt.dll" at 00000001C8DB0000: builtin
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #8 from algebro@tuta.io --- Nevermind, `info shared` says msvcrt and msvcrtd aren't loaded when GetModuleHandleA() is called. Is there anything that can be done about this on the Wine side of things? Or is this a cryptopp issue?
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #9 from Zebediah Figura z.figura12@gmail.com --- (In reply to algebro from comment #8)
Nevermind, `info shared` says msvcrt and msvcrtd aren't loaded when GetModuleHandleA() is called. Is there anything that can be done about this on the Wine side of things? Or is this a cryptopp issue?
Well, there is; we should probably be linking to msvcrt in our system DLLs (i.e. 14d97456a was wrong). But it's also kind of an application bug; they're relying on undocumented behaviour.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #10 from algebro@tuta.io --- Are there major implications if we were to link to msvcrt? Does that conflict with ucrt or would it be likely to break things?
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #11 from algebro@tuta.io --- I just found this in the cryptopp readme:
``` *** DLL Memory Management ***
Because it's possible for the Crypto++ DLL to delete objects allocated by the calling application, they must use the same C++ memory heap. Three methods are provided to achieve this. 1. The calling application can tell Crypto++ what heap to use. This method is required when the calling application uses a non-standard heap. 2. Crypto++ can tell the calling application what heap to use. This method is required when the calling application uses a statically linked C++ Run Time Library. (Method 1 does not work in this case because the Crypto++ DLL is initialized before the calling application's heap is initialized.) 3. Crypto++ can automatically use the heap provided by the calling application's dynamically linked C++ Run Time Library. The calling application must make sure that the dynamically linked C++ Run Time Library is initialized before Crypto++ is loaded. (At this time it is not clear if it is possible to control the order in which DLLs are initialized on Windows 9x machines, so it might be best to avoid using this method.)
When Crypto++ attaches to a new process, it searches all modules loaded into the process space for exported functions "GetNewAndDeleteForCryptoPP" and "SetNewAndDeleteFromCryptoPP". If one of these functions is found, Crypto++ uses methods 1 or 2, respectively, by calling the function. Otherwise, method 3 is used. ```
I'm guessing we're hitting case 3, and cryptopp doesn't bother to look for ucrt?
https://bugs.winehq.org/show_bug.cgi?id=51465
Kevin Andrews kjandrews0@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kjandrews0@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=51465
Stefan Reimer it@stefanreimer.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |it@stefanreimer.de
--- Comment #12 from Stefan Reimer it@stefanreimer.de --- Confirm this bug. Wine 6.9 on Gentoo.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #13 from info@ppfeufer.de --- Confirmed on wine 6.12 on Gentoo
https://bugs.winehq.org/show_bug.cgi?id=51465
Andreas Zuber a.zuber@gmx.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |a.zuber@gmx.ch
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #14 from algebro@tuta.io --- I just added a small hacky patch to cryptopp to manually load msvcrt.dll as follows:
hModule = GetModuleHandle("msvcrtd"); if (!hModule) hModule = GetModuleHandle("msvcrt"); if (!hModule) hModule = LoadLibrary("msvcrt.dll");
After recompiling cryptopp.dll and replacing the one that ships with the EVE Windows launcher, it works fine on Wine 6.12. So it looks like Zebediah was spot on.
@Zebediah, should we do anything about this on the Wine side (like look at linking against msvcrt), or just patch this upstream in cryptopp to have it load the library if it's not present?
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #15 from Zebediah Figura z.figura12@gmail.com --- (In reply to algebro from comment #14)
I just added a small hacky patch to cryptopp to manually load msvcrt.dll as follows:
hModule = GetModuleHandle("msvcrtd"); if (!hModule) hModule = GetModuleHandle("msvcrt"); if (!hModule) hModule = LoadLibrary("msvcrt.dll");
After recompiling cryptopp.dll and replacing the one that ships with the EVE Windows launcher, it works fine on Wine 6.12. So it looks like Zebediah was spot on.
@Zebediah, should we do anything about this on the Wine side (like look at linking against msvcrt), or just patch this upstream in cryptopp to have it load the library if it's not present?
Conceptually it'd be nice for cryptopp to fix the bug themselves, yes. (Note that you probably want to always use LoadLibrary instead of trying GetModuleHandle first.) That said, we may need to fix it in Wine anyway, for other applications.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #16 from algebro@tuta.io --- Would you have any guidance on how to fix it in wine? I'd be happy to try and contribute a patch, although when I was looking through the source code I was having trouble figuring out what exactly I would need to do without breaking everything. No worries if you'd rather handle it internally though!
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #17 from Zebediah Figura z.figura12@gmail.com --- (In reply to algebro from comment #16)
Would you have any guidance on how to fix it in wine? I'd be happy to try and contribute a patch, although when I was looking through the source code I was having trouble figuring out what exactly I would need to do without breaking everything. No worries if you'd rather handle it internally though!
Something like the following (untested!) diff should do it:
diff --git a/tools/makedep.c b/tools/makedep.c index db076d0c057..9c21ca40d73 100644 --- a/tools/makedep.c +++ b/tools/makedep.c @@ -2292,7 +2292,7 @@ static void add_crt_import( const struct makefile *make, struct strarray *import } else { - crt_dll = !make->testdll && !make->staticlib ? "ucrtbase" : "msvcrt"; + crt_dll = "msvcrt"; strarray_add( imports, crt_dll ); } }
Then it'd be a matter of trying to compile it, fixing any instances where we rely on newer CRT features, and then doing the same thing with the tests.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #18 from algebro@tuta.io ---
Then it'd be a matter of trying to compile it, fixing any instances where we rely on newer CRT features, and then doing the same thing with the tests.
Thanks a lot for your help! We're going to give this a try (I've also submitted a patch to cryptopp for now). Does linking to msvcrt like this conflict with the previous work with ucrt? Or does it just supplement it by loading msvcrt when needed? I want to make sure I understand all of the implications/impact before proposing a major change (although I guess technically you proposed it)
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #19 from Zebediah Figura z.figura12@gmail.com --- (In reply to algebro from comment #18)
Then it'd be a matter of trying to compile it, fixing any instances where we rely on newer CRT features, and then doing the same thing with the tests.
Thanks a lot for your help! We're going to give this a try (I've also submitted a patch to cryptopp for now). Does linking to msvcrt like this conflict with the previous work with ucrt? Or does it just supplement it by loading msvcrt when needed? I want to make sure I understand all of the implications/impact before proposing a major change (although I guess technically you proposed it)
I don't quite recall what the motivations for switching to ucrtbase were, but I suspect they were along the lines of "ucrtbase is newer and therefore objectively better". Which is true, but unfortunately it seems like we still need to use msvcrt...
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #20 from algebro@tuta.io ---
I don't quite recall what the motivations for switching to ucrtbase were, but I suspect they were along the lines of "ucrtbase is newer and therefore objectively better". Which is true, but unfortunately it seems like we still need to use msvcrt...
Do you have any idea as to how open the other maintainers would be to a rollback like this? I'm working out some linker errors with that patch now but I didn't want to waste people's time if they're uncomfortable going back to a deprecated runtime
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #21 from algebro@tuta.io --- Getting a linker error related to `__imp_lrintf` in `dsound_convert` when the patch is applied, not sure if it's an issue with my environment or something else:
/usr/lib/gcc/x86_64-w64-mingw32/11.1.0/../../../../x86_64-w64-mingw32/bin/ld: dlls/dsound/dsound_convert.cross.o: in function `f_to_8': /home/algebro/Documents/wine/trunk/src/wine-64-build/../wine/dlls/dsound/dsound_convert.c:121: undefined reference to `__imp_lrintf' /usr/lib/gcc/x86_64-w64-mingw32/11.1.0/../../../../x86_64-w64-mingw32/bin/ld: dlls/dsound/dsound_convert.cross.o: in function `f_to_16': /home/algebro/Documents/wine/trunk/src/wine-64-build/../wine/dlls/dsound/dsound_convert.c:130: undefined reference to `__imp_lrintf' /usr/lib/gcc/x86_64-w64-mingw32/11.1.0/../../../../x86_64-w64-mingw32/bin/ld: dlls/dsound/dsound_convert.cross.o: in function `f_to_24': /home/algebro/Documents/wine/trunk/src/wine-64-build/../wine/dlls/dsound/dsound_convert.c:139: undefined reference to `__imp_lrintf' /usr/lib/gcc/x86_64-w64-mingw32/11.1.0/../../../../x86_64-w64-mingw32/bin/ld: dlls/dsound/dsound_convert.cross.o: in function `f_to_32': /home/algebro/Documents/wine/trunk/src/wine-64-build/../wine/dlls/dsound/dsound_convert.c:148: undefined reference to `__imp_lrintf'
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #22 from algebro@tuta.io --- I'm a little confused because if I'm reading makedep.c correctly, the -mno-cygwin flag should automatically have this being built with msvcrt anyway:
make->use_msvcrt = strarray_exists( &make->extradllflags, "-mno-cygwin" );
When switching to ucrt with d0bf94, the `mno-cygwin` flag remained and they just added ucrtbase to the imports, and later removed ucrtbase in af12270. Was there some other change related to ucrt that would mess up the linking here?
https://bugs.winehq.org/show_bug.cgi?id=51465
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #23 from Zebediah Figura z.figura12@gmail.com --- (In reply to algebro from comment #20)
I don't quite recall what the motivations for switching to ucrtbase were, but I suspect they were along the lines of "ucrtbase is newer and therefore objectively better". Which is true, but unfortunately it seems like we still need to use msvcrt...
Do you have any idea as to how open the other maintainers would be to a rollback like this? I'm working out some linker errors with that patch now but I didn't want to waste people's time if they're uncomfortable going back to a deprecated runtime
I don't really, no. I should probably have already added Jacek to CC already. Jacek, do you have thoughts on this? Are there reasons for the switch to ucrtbase that I missed or forgot?
(In reply to algebro from comment #22)
I'm a little confused because if I'm reading makedep.c correctly, the -mno-cygwin flag should automatically have this being built with msvcrt anyway:
make->use_msvcrt = strarray_exists( &make->extradllflags, "-mno-cygwin" );
When switching to ucrt with d0bf94, the `mno-cygwin` flag remained and they just added ucrtbase to the imports, and later removed ucrtbase in af12270. Was there some other change related to ucrt that would mess up the linking here?
"use_msvcrt" is meant here as in contrast to glibc. As far as that naming is concerned, ucrtbase is another version of msvcrt (specifically version 140).
lrintf() is a function exported by ucrtbase but not msvcrt. As such we'd need to import ucrtbase in dsound (or find some substitute for lrintf).
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #24 from algebro@tuta.io ---
"use_msvcrt" is meant here as in contrast to glibc. As far as that naming is concerned, ucrtbase is another version of msvcrt (specifically version 140).
Ah thanks, that makes sense! I think this patch might also be required, but still testing:
--- tools/winegcc/winegcc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/winegcc/winegcc.c b/tools/winegcc/winegcc.c index 8c1e0d088ac..a8235834ed1 100644 --- a/tools/winegcc/winegcc.c +++ b/tools/winegcc/winegcc.c @@ -1267,7 +1267,7 @@ static void build(struct options* opts) if (strncmp( output_name, "msvcr", 5 ) && strncmp( output_name, "ucrt", 4 ) && strcmp( output_name, "crtdll.dll" )) - add_library(opts, lib_dirs, files, "ucrtbase"); + add_library(opts, lib_dirs, files, "msvcrt"); } else strarray_add(files, strmake("-a%s", crt_lib)); }
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #25 from Zebediah Figura z.figura12@gmail.com --- (In reply to algebro from comment #24)
"use_msvcrt" is meant here as in contrast to glibc. As far as that naming is concerned, ucrtbase is another version of msvcrt (specifically version 140).
Ah thanks, that makes sense! I think this patch might also be required, but still testing:
tools/winegcc/winegcc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/winegcc/winegcc.c b/tools/winegcc/winegcc.c index 8c1e0d088ac..a8235834ed1 100644 --- a/tools/winegcc/winegcc.c +++ b/tools/winegcc/winegcc.c @@ -1267,7 +1267,7 @@ static void build(struct options* opts) if (strncmp( output_name, "msvcr", 5 ) && strncmp( output_name, "ucrt", 4 ) && strcmp( output_name, "crtdll.dll" ))
add_library(opts, lib_dirs, files, "ucrtbase");
add_library(opts, lib_dirs, files, "msvcrt"); } else strarray_add(files, strmake("-a%s", crt_lib)); }-- 2.32.0
It's not required; it actually specifies the default for any libraries compiled with winegcc, but we are already specifying the CRT library explicitly via makedep (even for modules currently compiled with ucrtbase). I think it makes sense for winelib software to use ucrtbase by default, in which case we don't want the above hunk.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #26 from algebro@tuta.io --- (In reply to Zebediah Figura from comment #25)
It's not required; it actually specifies the default for any libraries compiled with winegcc, but we are already specifying the CRT library explicitly via makedep (even for modules currently compiled with ucrtbase). I think it makes sense for winelib software to use ucrtbase by default, in which case we don't want the above hunk.
Great, thanks. Importing ucrtbase in dsound got past that, now it's a matter of adding it to the other DLLs that need it (d3dx9_29.dll looks like it needs it next).
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #27 from algebro@tuta.io --- Got it compiling, had to add ucrtbase back to a bunch of the DLLs (basically reverting af12270). I'll test it with EVE tomorrow and start looking into how to do the conformance tests, and what work needs done to update them.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #28 from Jacek Caban jacek@codeweavers.com --- Created attachment 70331 --> https://bugs.winehq.org/attachment.cgi?id=70331 fix
It's not clear to me that linking to msvcrt.dll would make things much better. We would then be possibly missing ucrtbase.dll being loaded. On Windows, ucrtbase.dll ends up being used in quite some cases and I think that usually both msvcrt.dll and ucrtbase.dll end up being loaded. For a relatively high level testing, I used a simple test like this:
#include <windows.h> #include <stdio.h>
int main(int argc, char **argv) { LoadLibraryA(argc > 1 ? argv[1] : "user32.dll"); printf("%p %p\n", GetModuleHandleW(L"msvcrt.dll"), GetModuleHandleW(L"ucrtbase.dll")); return 0; }
For the test to make sense, it needs to be compiled with some other msvcrt version than tested ones. It's not possible with GCC mingw, so I used llvm-mingw with a command (I will attach the executable for convenience):
x86_64-w64-mingw32-gcc deptest.c -lmsvcr100 -o deptest64.exe
If you try it with DLLs like gdi32.dll or user32.dll, only ucrtbsae.dll is loaded on Windows 10. If you try it with advapi32.dll, only msvcrt.dll is loaded. Thus, higher level DLLs pull both of them.
That said, is the attached patch enough to get the game running?
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #29 from Jacek Caban jacek@codeweavers.com --- Created attachment 70332 --> https://bugs.winehq.org/attachment.cgi?id=70332 deptest64.exe
A build of the test from previous comment.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #30 from Kevin Andrews kjandrews0@gmail.com --- Created attachment 70335 --> https://bugs.winehq.org/attachment.cgi?id=70335 make output
Compiling with just the following change:
IMPORTS = kernelbase sechost msvcrt
Gives the attached output when compiling the 64bit build ready for including into the 32bit build which passes afterwards but fails to run anything.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #31 from Jacek Caban jacek@codeweavers.com --- You probably need to clean dlls/advapi32 directory so that it's rebuilt with proper defines.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #32 from Kevin Andrews kjandrews0@gmail.com --- That was from a fresh clone (local history):
git clone git://source.winehq.org/git/wine.git wine64 git clone git://source.winehq.org/git/wine.git wine32
cd wine64 git checkout wine-6.13 patch dlls/advapi32/Makefile.in CC="ccache gcc" ./configure --enable-win64 make -j 12
cd ../wine32 git checkout wine-6.13 patch dlls/advapi32/Makefile.in CC="ccache gcc -m32" PKG_CONFIG_PATH=/usr/lib32/pkgconfig/ ./configure --with-wine64=../wine64 make -j 12
Errors with the previous attachment, is there something i need to clean / do before make? leaving this out on the 64bit build enables both to compile but the EVE Online launcher freezes just after opening.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #33 from algebro@tuta.io --- The game is launching fine for me with that patch on Arch Linux. Not sure how to fix your build as I've just adapted the Arch package to apply the patch
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #34 from Jacek Caban jacek@codeweavers.com --- If you previously used those sources to build Wine, then you need to do something like:
make dlls/advapi32/clean
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #35 from Kevin Andrews kjandrews0@gmail.com --- I completely removed the previous builds and followed those commands exactly in my last comment, i'll try the clean command next and see if the 64bit will build, might have something to do with ccache on my configure command.
Building with the patch only applied to wine32 seems to have worked, restarted the launcher again and it's working (launcher version 1920522). Three clients all launching and logging into the actual game to stations.
Not 100% sure why vanilla wine isn't building with that change on 64bit on my machine, i'll take more of a look at it later.
Was just about to pull the wine PKGBUILD for arch and add to the patch files, looks like you got there first!
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #36 from Kevin Andrews kjandrews0@gmail.com --- Sorry for the spam, yes issue was between seat and keyboard one of:
make dlls/advapi32/clean ccache -C
Fixed the 64bit build and included inside a rebuilt 32bit runs fine.
https://bugs.winehq.org/show_bug.cgi?id=51465
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #37 from Jacek Caban jacek@codeweavers.com --- Thanks for testing and the report. I sent a patch:
https://source.winehq.org/patches/data/209969
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #38 from algebro@tuta.io --- (In reply to Jacek Caban from comment #37)
Thanks for testing and the report. I sent a patch:
Thanks so much for your help Jacek and Zebediah! We really appreciate it!
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #39 from ppfeufer info@ppfeufer.de --- Can confirm, patch is working on Gentoo with wine 6.12
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #40 from ppfeufer info@ppfeufer.de --- (In reply to ppfeufer from comment #39)
Can confirm, patch is working on Gentoo with wine 6.12
Although, as long as the game client is open, the launcher is unresponsive. The client needs to be minimized for the launcher to become responsive again.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #41 from algebro@tuta.io --- (In reply to ppfeufer from comment #40)
(In reply to ppfeufer from comment #39)
Can confirm, patch is working on Gentoo with wine 6.12
Although, as long as the game client is open, the launcher is unresponsive. The client needs to be minimized for the launcher to become responsive again.
It seems to be working fine with Wine-Staging 6.12 on Arch for me in Windowed mode. Fullscreen mode has always been a little wonky for me (whenever I switch window focus it minimizes the game), but I just assumed that's how it was
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #42 from ppfeufer info@ppfeufer.de --- (In reply to algebro from comment #41)
(In reply to ppfeufer from comment #40)
(In reply to ppfeufer from comment #39)
Can confirm, patch is working on Gentoo with wine 6.12
Although, as long as the game client is open, the launcher is unresponsive. The client needs to be minimized for the launcher to become responsive again.
It seems to be working fine with Wine-Staging 6.12 on Arch for me in Windowed mode. Fullscreen mode has always been a little wonky for me (whenever I switch window focus it minimizes the game), but I just assumed that's how it was
I am in windowed mode.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #43 from Kevin Andrews kjandrews0@gmail.com --- Finished building straight from winehq git and arch linux wine-staging PKGBUILD, both version 6.13, with the patch applied (https://github.com/Caffe1neAdd1ct/arch-wine-staging-pkgbuild) both working fine :)
Thanks very much to all involved!
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #44 from Kevin Andrews kjandrews0@gmail.com --- (In reply to ppfeufer from comment #42)
(In reply to algebro from comment #41)
(In reply to ppfeufer from comment #40)
(In reply to ppfeufer from comment #39)
Can confirm, patch is working on Gentoo with wine 6.12
Although, as long as the game client is open, the launcher is unresponsive. The client needs to be minimized for the launcher to become responsive again.
It seems to be working fine with Wine-Staging 6.12 on Arch for me in Windowed mode. Fullscreen mode has always been a little wonky for me (whenever I switch window focus it minimizes the game), but I just assumed that's how it was
I am in windowed mode.
I just tested 3 clients launched from the same launcher, tested in both fixed window and windowed modes, launcher remains responsive for me...
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #45 from ppfeufer info@ppfeufer.de --- (In reply to Kevin Andrews from comment #44)
(In reply to ppfeufer from comment #42)
(In reply to algebro from comment #41)
(In reply to ppfeufer from comment #40)
(In reply to ppfeufer from comment #39)
Can confirm, patch is working on Gentoo with wine 6.12
Although, as long as the game client is open, the launcher is unresponsive. The client needs to be minimized for the launcher to become responsive again.
It seems to be working fine with Wine-Staging 6.12 on Arch for me in Windowed mode. Fullscreen mode has always been a little wonky for me (whenever I switch window focus it minimizes the game), but I just assumed that's how it was
I am in windowed mode.
I just tested 3 clients launched from the same launcher, tested in both fixed window and windowed modes, launcher remains responsive for me...
Been playing around a bit more. When I have the client on a different monitor, it's all fine and everything keeps responsive. So it might be an entirely different issue I am facing here. Maybe something with KDE not refreshing windows in background or something like that.
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #46 from Kevin Andrews kjandrews0@gmail.com --- (In reply to ppfeufer from comment #45)
(In reply to Kevin Andrews from comment #44)
(In reply to ppfeufer from comment #42)
(In reply to algebro from comment #41)
(In reply to ppfeufer from comment #40)
(In reply to ppfeufer from comment #39)
Can confirm, patch is working on Gentoo with wine 6.12
Although, as long as the game client is open, the launcher is unresponsive. The client needs to be minimized for the launcher to become responsive again.
It seems to be working fine with Wine-Staging 6.12 on Arch for me in Windowed mode. Fullscreen mode has always been a little wonky for me (whenever I switch window focus it minimizes the game), but I just assumed that's how it was
I am in windowed mode.
I just tested 3 clients launched from the same launcher, tested in both fixed window and windowed modes, launcher remains responsive for me...
Been playing around a bit more. When I have the client on a different monitor, it's all fine and everything keeps responsive. So it might be an entirely different issue I am facing here. Maybe something with KDE not refreshing windows in background or something like that.
Highly probable to be a different issue, i have to use libstrangle to limit down the FPS on nvidia prime sync with Gnome otherwise i get massive freezing when switching windows with vsync enabled in the clients... Apparently nvidia driver has fixed the issue, freezing is "better" but not playable with 3 clients...
I'd recommend trying out a workspace switching solution with fixed windows and shortcuts if you're on one monitor, multiple monitors i'm not sure what to suggest..
https://bugs.winehq.org/show_bug.cgi?id=51465
--- Comment #47 from ppfeufer info@ppfeufer.de --- (In reply to Kevin Andrews from comment #46)
(In reply to ppfeufer from comment #45)
(In reply to Kevin Andrews from comment #44)
(In reply to ppfeufer from comment #42)
(In reply to algebro from comment #41)
(In reply to ppfeufer from comment #40)
(In reply to ppfeufer from comment #39) > Can confirm, patch is working on Gentoo with wine 6.12
Although, as long as the game client is open, the launcher is unresponsive. The client needs to be minimized for the launcher to become responsive again.
It seems to be working fine with Wine-Staging 6.12 on Arch for me in Windowed mode. Fullscreen mode has always been a little wonky for me (whenever I switch window focus it minimizes the game), but I just assumed that's how it was
I am in windowed mode.
I just tested 3 clients launched from the same launcher, tested in both fixed window and windowed modes, launcher remains responsive for me...
Been playing around a bit more. When I have the client on a different monitor, it's all fine and everything keeps responsive. So it might be an entirely different issue I am facing here. Maybe something with KDE not refreshing windows in background or something like that.
Highly probable to be a different issue, i have to use libstrangle to limit down the FPS on nvidia prime sync with Gnome otherwise i get massive freezing when switching windows with vsync enabled in the clients... Apparently nvidia driver has fixed the issue, freezing is "better" but not playable with 3 clients...
I'd recommend trying out a workspace switching solution with fixed windows and shortcuts if you're on one monitor, multiple monitors i'm not sure what to suggest..
Found it I think. KDE has something like "Focus stealing prevention" that needs to be turned off (System Settings > Window Management > Window Behavior > Focus)
PS.: Sorry for the off-topic, but I reckon that someone might run into this as well, so this might help :-)
https://bugs.winehq.org/show_bug.cgi?id=51465
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |2b3a300cbfee15dd6771a0a984c | |13591a2b36358 Status|NEW |RESOLVED
--- Comment #48 from Jacek Caban jacek@codeweavers.com --- Fixed in Git: https://source.winehq.org/git/wine.git/commitdiff/2b3a300cbfee15dd6771a0a984...
https://bugs.winehq.org/show_bug.cgi?id=51465
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #49 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.14.
https://bugs.winehq.org/show_bug.cgi?id=51465
Mehmet gelisin mehmetgelisin@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mehmetgelisin@aol.com
--- Comment #50 from Mehmet gelisin mehmetgelisin@aol.com --- DWORD QueueUserAPC() will return zero with GetLastError() set to return ERROR_ACCESS_DENIED if called on a terminating thread, but ERROR_GEN_FAILURE is the expected return of GetLastError() in this scenario. http://www.compilatori.com/
Unfortunately, it's hard to catch a thread in this state since once a thread has been terminated completely calling on it results in GetLastError() returning ERROR_INVALID_HANDLE as it should. http://www.wearelondonmade.com/
This effects applications using older versions of WebRTC, such as StarCitizen. The chromium development team noticed this and built a workaround into WebRTC to make WebRTC compatible with WINE and Windows in this commit: http://www.jopspeech.com/
DWORD QueueUserAPC() will return zero with GetLastError() set to return ERROR_ACCESS_DENIED if called on a terminating thread, but ERROR_GEN_FAILURE is the expected return of GetLastError() in this scenario. http://joerg.li/
Unfortunately, it's hard to catch a thread in this state since once a thread has been terminated completely calling on it results in GetLastError() returning ERROR_INVALID_HANDLE as it should. http://connstr.net/
This effects applications using older versions of WebRTC, such as StarCitizen. The chromium development team noticed this and built a workaround into WebRTC to make WebRTC compatible with WINE and Windows in this commit: http://embermanchester.uk/
DWORD QueueUserAPC() will return zero with GetLastError() set to return ERROR_ACCESS_DENIED if called on a terminating thread, but ERROR_GEN_FAILURE is the expected return of GetLastError() in this scenario. http://www.slipstone.co.uk/
Unfortunately, it's hard to catch a thread in this state since once a thread has been terminated completely calling on it results in GetLastError() returning ERROR_INVALID_HANDLE as it should. http://www.logoarts.co.uk/
This effects applications using older versions of WebRTC, such as StarCitizen. The chromium development team noticed this and built a workaround into WebRTC to make WebRTC compatible with WINE and Windows in this commit: http://www.acpirateradio.co.uk/
DWORD QueueUserAPC() will return zero with GetLastError() set to return ERROR_ACCESS_DENIED if called on a terminating thread, but ERROR_GEN_FAILURE is the expected return of GetLastError() in this scenario. https://waytowhatsnext.com/
Unfortunately, it's hard to catch a thread in this state since once a thread has been terminated completely calling on it results in GetLastError() returning ERROR_INVALID_HANDLE as it should. https://www.webb-dev.co.uk/
This effects applications using older versions of WebRTC, such as StarCitizen. The chromium development team noticed this and built a workaround into WebRTC to make WebRTC compatible with WINE and Windows in this commit:
Unfortunately, it's hard to catch a thread in this state since once a thread has been terminated completely calling on it results in GetLastError() returning ERROR_INVALID_HANDLE as it should. http://www.iu-bloomington.com/ This effects applications using older versions of WebRTC, such as StarCitizen. The chromium development team noticed this and built a workaround into WebRTC to make WebRTC compatible with WINE and Windows in this commit: http://www-look-4.com/
https://bugs.winehq.org/show_bug.cgi?id=51465
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |6.0.x
https://bugs.winehq.org/show_bug.cgi?id=51465
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|6.0.x |---
--- Comment #51 from Michael Stefaniuc mstefani@winehq.org --- Removing the 6.0.x milestone from bug fixes included in 6.0.3.
-
WineHQ Bugzilla