Testing Result for Beta EVE Launcher

I think it was you who fixed prev launcher disease under linux?

Blessed will be your ways man. I owe you whatever amounts you want of solo 1vs1 at the sun

2 Likes

Thanks :slight_smile: I did gather enough info to figure out the root cause, but it was the wine devs who actually fixed it

OK, I’ve confirmed that the launchdarkly_client.pyd module successfully loads with a relative path on windows, and does not in wine. I’m thinking it’s related to this last argument they’re passing to LoadLibraryExW:

LoadLibraryExW((LPCWSTR)plVar4[3],(HANDLE)0x0,8);

8 for this argument messes with the search order for DLLs, and is undefined when passing a relative path as the first argument (which they’re doing with launchdarkly but no other modules).

1 Like

I’ve opened a wine bug ticket here: WineHQ Bugzilla – Bug 51821 – EVE Online Sisi Client Crashes Due to differences in how Wine and Windows handle LoadLibraryExW Undefined Behavior

Please go ahead and post a comment to show that it affects multiple users

6 Likes

Thank you Renard for doing the heavy lifting. Would help out more if I knew how to get the relevant information.

1 Like

BTW everyone, while I work on a proper fix, I’ve discovered that if you copy launchdarkly_client.pyd from C:\EVE\SharedCache\sisi\bin64 to C:\EVE\SharedCache\sisi\, Sisi will launch just fine, confirming it’s an issue with the DLL search path behavior in Wine. You should be able to use this as a workaround for now.

5 Likes

My man… thank you! Will update and verify/confirm once I have a chance.

I guess we should keep a copy of the pyd file in case this change gets pushed to the TQ launcher before it’s resolved via Wine?

Update - Just tried this out. It works.
Wanted to point out that you need to run the launcher first, then copy while it’s running. If you copy before the launcher is run, the launchdarkly_client.pyd will be deleted when the launcher starts. Also, similarly you will have to cp the file into the directory again every time you run the launcher, as when the launcher starts, it will delete the launchdarkly_client.pyd file

1 Like

Thanks for the notes! I forgot to mention that the Launcher cleans out extra files etc. when it starts so you’re exactly right that you need to start the launcher before copying it. I’m talking to the wine devs on IRC now so hopefully we can figure out a fix.

I guess we should keep a copy of the pyd file in case this change gets pushed to the TQ launcher before it’s resolved via Wine?

I doubt you would need to, although it wouldn’t hurt. There isn’t really a problem with the file, it’s just that Wine doesn’t resolve the correct directory when loading it, while Windows does.

@D43dun are you comfortable building wine from source? I’ve got a patch I need to test that fixes it on my system. I’m working on creating more conformance tests that are required before it could be eligible to be accepted in wine, but it would be good to know if it fixes the problem with Sisi on other systems and doesn’t introduce any other serious bugs.

Also I want to try it too. Im kinda ok with building form source, I think. Can I participate?

Grab this patch and apply it with git am. Should apply cleanly to both vanilla wine and wine-staging.

yep. I can give it a try… Never done it before, but can look into this in the next day or so.

So, I compiled wine and wine64 from source with your patch applied. Compiling wine reminded me why I stopped using gentoo a long time ago.

I use lutris to run the game, so I pointed the game runner to be the recently compiled wine, and I couldn’t get the launcher to begin. I sense that this might be some sort of issue between how I’m calling wine through lutris. Also, I couldn’t find the debug output from Lutris.

Will try to run again today in the evening, and tail -f the logs straight from the system to see what’s wrong when running this, try to get the launcher/game to run.

What distro are you on? If you’re using Arch or Manjaro I can provide a working PKGBUILD.

Also no worries if you can’t easily get the compiled Wine running. Turns out this has been a known bug for a long time (an issue was opened in 2011; they attempted a fix in 2019 but it didn’t work).

1 Like

I’m on ubuntu 20.04.

I solved my conformance test problems because I was being an idiot :slight_smile: Will try to submit this upstream in time for wine 6.20, although the maintainers mentioned that this is a particularly difficult part of the codebase to work with correctly and get things accepted

5 Likes

I applied your patch to wine-staging-6.19, sisi works for me now under linux! Hell yeah!

Probably I will use this wine in the future

UPD im using gentoo

Glad to hear it! Note that the original patch could -possibly- break other things, although it’s already a super weird edge case which is why it went mostly unnoticed for so long. A more granular and “correct” patch has been submitted upstream and is waiting for review, I’ll update the thread if it ends up getting merged

Of course i am understand that wine-staging with custom homemade patches is something that can break things. That is the reason why I am keeping a dozen versions of wine, thanks to easy way to do this in gentoo.

What if it will not be merged? any chances to see whats wrong then?

FCK … same for TQ after todays patch … lol …