[4/5] msi: Don't initialize COM for custom action threads.
Hans Leidekker
hans at codeweavers.com
Tue Mar 24 04:26:24 CDT 2009
I have now seen custom actions initializing COM with different threading
models that also check the return value of CoInitialize(). This suggests
that we shouldn't initialize COM at all.
A bit of googling turned up this comment from a Microsoft employee's
blog, which confirms it:
Hey Steve, sorry for the delay on this. This question rang a bell so I dug
into some of the emails that have gone across our internal Windows Installer
question-n-answer alias and here is the official answer from the Windows
Installer team:
"One of the first things that a custom action server does when it is
created is to call CoInitializeEx(0, COINIT_MULTITHREADED).
However, the thread on which a DLL custom action is run is different
from the main thread (on which COM is initialized) and COM will not be
initialized on it. It is up to the custom action to initialize COM to
its liking."
http://blogs.msdn.com/astebner/archive/2005/02/07/368917.aspx
-Hans
diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c
index ffac63f..fa8f951 100644
--- a/dlls/msi/custom.c
+++ b/dlls/msi/custom.c
@@ -695,8 +695,6 @@ static DWORD ACTION_CallDllFunction( const GUID *guid )
TRACE("calling %s\n", debugstr_w( function ) );
handle_msi_break( function );
- CoInitializeEx(NULL, COINIT_MULTITHREADED);
-
__TRY
{
r = fn( hPackage );
@@ -709,8 +707,6 @@ static DWORD ACTION_CallDllFunction( const GUID *guid )
}
__ENDTRY;
- CoUninitialize();
-
MsiCloseHandle( hPackage );
}
else
More information about the wine-patches
mailing list