[Bug 20296] League of Legends: crash after eula

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=20296

--- Comment #42 from Amos Wenger <amos at official.fm> 2011-04-06 04:46:05 CDT ---
(In reply to comment #41)
> (In reply to comment #40)
> > (In reply to comment #39)
> > > Sorry, that's even worse.   The objection is that the patch
> > > is a kludge, whether or not it includes duplicated code.
> > 
> > I agree, I understand this patch will never be accepted as-is, just trying to
> > gain a little momentum. Can anyone give directions for a cleaner approach?
> > Christoph seems to suggest that a "surrogate server" (not sure what it is) is
> > needed, but ends his comment with "So may not be needed on wine and the DLL can
> > just be loaded in-process." so I'm not sure what he really meant.
> > 
> > There's good will here, I just need better feedback :/
> 
> First thing is understanding how CLSCTX_INPROC_SERVER and CLSCTX_LOCAL_SERVER
> are different.  So that you have the patch heading down the right line to
> implement CLSCTX_LOCAL_SERVER.
> 
> http://msdn.microsoft.com/en-us/library/ms693716%28v=vs.85%29.aspx  Very
> important read on the subject.

Okay, so let me try to summarize to see if I've got it right:

CLSCTX_INPROC_SERVER creates and manages OLE objects in the same process as the
application that uses them. This is fine if the object is not shared between
multiple applications, for example, because each instance of an application can
only use its 'own version' of the OLE object, which is different in every
process.

CLSCTX_LOCAL_SERVER creates and manages OLE objects on the same machine, but on
a different process than the user application. Ie. the application containing
the object we want to use has to be launched, it will itself call
CoRegisterClassObject on startup, thus registering itself as an OLE object (in
our case, with the CLSID {629f8434-0530-41e6-b7c5-61a82faa3df2}) so that any
application on this machine can access the same, shared instance of this object
running in a dedicated process.

Right? And if I understood correctly, right now there is no separate process
being launched when CLSCTX_LOCAL_SERVER is used in Wine, so the object never
gets registered and it fails with:

err:ole:create_server class {629f8434-0530-41e6-b7c5-61a82faa3df2} not
registered
err:ole:CoGetClassObject no class object {629f8434-0530-41e6-b7c5-61a82faa3df2}
could be created for context 0x4

(see attachment #23993)

I'm not sure yet how to 'start a surrogate server' so that the OLE object gets
loaded in a different process, I'll continue to read Wine's ole codebase, it
seems create_server should do this but fails somehow (Christoph mentioned the
lack of a 'LocalService' entry under the 'AppId' entry - I'm still not too
clear what the relation is between the registry and our problem with OLE
objects here).

What I don't understand though, is why does it work at all to force INPROC
instead of LOCAL for our specific bug. For CoGetClassObject to work, the object
still has to be loaded somewhere somehow right? So that means it's
"accidentally" already loaded in the same process as the launcher and thus the
hack works? I must be missing something.

-- 
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.