Using the proxy/stub dlls that midl generates is one way for the implementors of custom interfaces to provide for marshalling.
However, if the custom interface is OLE Automation compatible then the marshalling will be carried out by the OLE system itself, using the type library describing the interface (if the developer elects not to implement their own marshalling). I'm not sure how the existance of this "Type library marshalling" relates to the original question of out-of-process COM objects for an installer; it may be that it relies on this mechanism.
Because type library marshalling doesn't require extra dlls or effort on the part of the developer, I think it is quite popular.
----- Original Message ----- From: "Daniel Walker" diwalker@earthlink.net To: wine-devel@winehq.com Sent: Saturday, July 21, 2001 3:01 AM Subject: Marshaling
From what I've read when someone creates a custom interface for COM, an IDL file is generated, then the MIDL compiler uses the IDL file to create proxy and stub code that works with the standard COM RPC functionality.. So under some (most) circumstances wine's COM implementation would only have to facilitate the sending and recieving of the marshaled data ..
Not to minimize the work involved .. The standard marshaling would have to do all the generic COM interfaces like IUnknown, IStorage, IStream (I think). Even though full implementations of those would be available . But most components would have custom interfaces so they would also have their own marshaling code ..
If I'm 100% correct then , I guess, there wouldn't be a need for the type information. Yet it exists .. Unless the type info is used for something other than marshaling.
Daniel Walker