Mike Hearn wrote:
On Fri, 17 Dec 2004 10:49:45 -0800, Bill Medland wrote:
Does anyone know anything about this? e.g. when starting a new thread where does the apartment get initialized?
It's supposed to get initialized in the call to CoInitialize[Ex] however the _LocalServerThread never calls this as it's an internal implementation detail of out of process DCOM.
This looks like we haven't got the design quite right here, the
LocalServerThread doesn't exist in native DCOM as far as I can tell
so it may need to be replaced by something else.
Rewriting this stuff is next on my todo list. The correct fix is to marshal it in the context of the calling thread, rather than in the new thread. This part is implemented in the native version as kind of a mix between the rpcrt4 thread pooling and undocumented local activator interfaces registered for each apartment.
The code in StdMarshalImpl is correct, the problem is that the local
server thread is violating the COM laws by using CoMarshalInterface before
entering an apartment.
For now, does this patch help?
Index: dlls/ole32/compobj.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/compobj.c,v retrieving revision 1.113 diff -u -p -r1.113 compobj.c --- dlls/ole32/compobj.c 14 Dec 2004 15:28:58 -0000 1.113 +++ dlls/ole32/compobj.c 17 Dec 2004 19:13:22 -0000 @@ -102,6 +102,7 @@ typedef struct tagRegisteredClass DWORD connectFlags; DWORD dwCookie; HANDLE hThread; /* only for localserver */ + APARTMENT *apt; /* owning apartment */ struct tagRegisteredClass* nextClass; } RegisteredClass;
@@ -1107,6 +1108,13 @@ _LocalServerThread(LPVOID param) {
TRACE("Starting threader for %s.\n",debugstr_guid(&newClass->classIdentifier));
+ /* we need to enter the apartment of the thread which registered + * the class object to perform the next stage + */ + + assert( newClass->apt ); + NtCurrentTeb()->ReservedForOle = newClass->apt; + strcpy(pipefn,PIPEPREF); WINE_StringFromCLSID(&newClass->classIdentifier,pipefn+strlen(PIPEPREF));
@@ -1219,6 +1227,12 @@ HRESULT WINAPI CoRegisterClassObject( if ( (lpdwRegister==0) || (pUnk==0) ) return E_INVALIDARG;
+ if (!COM_CurrentApt()) + { + ERR("COM was not initialized\n"); + return CO_E_NOTINITIALIZED; + } + *lpdwRegister = 0;
/* @@ -1240,6 +1254,7 @@ HRESULT WINAPI CoRegisterClassObject( newClass->classIdentifier = *rclsid; newClass->runContext = dwClsContext; newClass->connectFlags = flags; + newClass->apt = COM_CurrentApt(); /* * Use the address of the chain node as the cookie since we are sure it's * unique.
That patch is very hackish and needlessly complicated. This patch accomplishes the same task in fewer lines (note that this is not the best solution for the problem, I am working on that):
Index: compobj.c
===================================================================
RCS file: /home/wine/wine/dlls/ole32/compobj.c,v
retrieving revision 1.113
diff -u -p -r1.113 compobj.c
--- compobj.c 14 Dec 2004 15:28:58 -0000 1.113
+++ compobj.c 18 Dec 2004 13:58:03 -0000
@@ -1107,6 +1107,8 @@ _LocalServerThread(LPVOID param) {TRACE("Starting threader for %s.\n",debugstr_guid(&newClass->classIdentifier));
+ CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
+
strcpy(pipefn,PIPEPREF);
WINE_StringFromCLSID(&newClass->classIdentifier,pipefn+strlen(PIPEPREF));
Rob
