[4/5] msi: Don't initialize COM for custom action threads.

[Hans Leidekker]

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