http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #42 from Amos Wenger amos@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.