http://bugs.winehq.org/show_bug.cgi?id=20296
Amos Wenger amos@official.fm changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33948|0 |1 is obsolete| |
--- Comment #49 from Amos Wenger amos@official.fm 2011-04-09 19:57:27 CDT --- Created an attachment (id=34018) --> (http://bugs.winehq.org/attachment.cgi?id=34018) First try implementing dll surrogates in Wine
So here it is, after a few days of reading more than my fair share of DCOM docs, wine sourcecode, hacking around to see how stuff works under the hood, here's my first try at implementing dll surrogates in wine. Disclaimer: the patch is big. 22K, 690 lines, It still depends on a Windows dllhost.exe (I used the version from my Windows XP SP3 32-bit). FOR TESTING THIS PATCH, DLLHOST.EXE NEEDS TO BE IN $WINEPREFIX/WINDOWS/SYSTEM32 (or anywhere in your %PATH%, really, but that's where it belongs anyway). The reason I haven't provided a dllhost.exe is because I'm not sure how to add a program to tools/ but it should be really easy to code, afaik it just does CoInitializeEx, then parses command-line arguments and goes CLSIDFromString, then calls CoRegisterSurrogateEx and that's it. If CoRegisterSurrogateEx returns, it just CoUnitializeEx and shuts down!
it probably needs a good cleanup and I can't guarantee it's 100% right - especially I'm not entirely sure I'm using the right CLSCTX and REGCLS values everywhere, but everything seems to go find on the local rpc server, generic marshalling/unmarshalling works like a charm and functions are called remotely correctly - there might be some apartment handling I haven't looked into yet, but I think this is pretty much what we had in mind. Also, I'm not sure where to draw the line between compobj.c and surrogate.c, sometimes I feel some of compobj.c belongs in surrogate.c, but oh well I'm not sure. Feedback greatly appreciated!
So here are my observations:
- When run naively (wine lol.launcher.exe), it shows the patcher, sleeps till I click "Play", then shows a dialog box telling me LolClient.exe has crashed, sleeps till I close this dialog box, and *then* the login screen comes up, but I can't login successfully (obviously it's LolClient.exe that's handling the login and since it crashed well... it's not even trying to log in with the data provided). - When run with a few debug options (WINEDEBUG=ole,+tid,+relay wine lol.launcher.exe), it's slow as fuck, but... it works! LolClient.exe doesn't crash, it displays the patcher then the login screen correctly, I can log in and even start a game and it begins to load :) (I haven't tested the actual gameplay because it was so slow and LoL complained about my graphic drivers.. nouveau actually).
So I've done some more investigation on the LolClient.exe crash, by running it manually (something like winedbg air/LolClient.exe -runtime air air/META-INF/AIR/application.xml air/) which obviously should fail since Maestro is not running, but that's not the problem here - it seems to crash in:
Backtrace: =>0 0x7c574eac ssleay_rand_add+0x30c() in libcrypto.so.1.0.0 (0x0f65c0bc) 1 0x00956d01 (0xafd17daf)
So now I'm really puzzled, it seems my patch solves the same issue as attachment #25672, except it does it correctly, because it starts a separate process to load the dll in, and does everything by rpc after that, so... problem solved. Now why does the rest crash? Apparently people had the whole client working only with ole-force-inproc-[...] but I don't. I'd appreciate if other people could test it, especially on 32-bit distros, I think it might be the culprit.