Attached is a diff of some current progress. These changes are all in place right now, they would of course need moved to an external library.
Kornel, to answer your questions: This is intended to be the beginning of a framework to leverage multiple component technologies. COM Interop is well defined so I'm starting there. COM is not necessarily Windows specific. It can be ported via tools (such as those provided by Mainsoft) or on one's own if you follow the COM ABI standard. As for XPCOM, I know little about it. I've looked into it a little, and while it may not have as well defined an ABI, there may still be hope for it. - Jonathan -----Original Message----- From: Kornél Pál [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 16, 2005 1:07 PM To: Jonathan S. Chambers Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] COM Interop in Mono Hi, You are referencing something that you want to upload to SVN but did not show it yet. What is it exactly? Note that there were discussions about COM interop previously you should look at them as well. Some important things: COM is Windows specific. If you want to use it you can use MS.NET instead of Mono as relaying on COM interop is platform dependent. So there is no use to implement COM interop only for use with Windows. On the other hand COM interop could be implemented as a platform independent object oriented P/Invoke-like layer that could be cool. But the problem is that on Windows COM specifies a standard ABI (Application Binary Interface) for representing COM objects that can be accessed by code compiled using different compilers. On other platforms (Linux for example) there is no standard ABI for objects, only for classic C functions. This makes the things difficult. In addition things like XPCOM assume that you use the same compiler on both sides of interop so has no specific ABI, it depends on the C++ compiler you use. Some people would like to implement COM interop as Bonobo interop in Mono but these two layers are so much different that it cannot be done. Bonobo interop has to be implemented separatedly as it requires different interop attributes for example. Kornél ----- Original Message ----- From: "Jonathan S. Chambers" <[EMAIL PROTECTED]> To: "Jonathan S. Chambers" <[EMAIL PROTECTED]> Cc: <mono-devel-list@lists.ximian.com> Sent: Wednesday, November 16, 2005 5:50 PM Subject: RE: [Mono-dev] COM Interop in Mono Well, no one has responded yet, so here comes the next email ;-) This work is coming along, so I'd like to get it in svn soon. Would this go under the trunk, as in /trunk/cominterop or something like that? If anyone has a better name, please suggest. Also, I think this work will also be similar to work needed for XPCOM. Should both be in the same lib? Or where can I put shared functionality? Ok, more details. All calls to the RCW's are finding their way to the correct methods on the COM objects. Currently, I find the interface that the method belongs to. I then subtract interface->method.start from the method->slot. This gives me the offset of the method in the interface. I then compensate for whether the interface is IUnknown based or IDispatch based (3 or 7 methods at beginning of vtable). I then call that offset on the correct vtable. Now, more about integrating into mono. To correctly support COM interop in mono, the following functionality is needed. I'm trying to begin to define what the API needs to support. 1. Object Creation 2. Method Calls 3. Object Destruction (will all component wrappers need a finalizer?) 4. Casting (more difficult for me, can be supported later as this dynamically adds interfaces to an object) 5. Interface/COM object marshalling 6. BSTR marshalling (I think this should be in this library, so mono has no dependencies on the Sys*String routines for BSTRS) Some humble beginning like: /* creates unmanaged object */ gpointer component_create(MonoObject* this); /* destroys unmanaged object */ void component_destroy(MonoObject * this); /* gets managed->unmanaged wrapper for method calls, called by mono_marshal_get_native_wrapper? */ MonoMethod * component_get_method (MonoMethod *method) Not sure about the marshalling yet... Thanks, Jonathan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan S. Chambers Sent: Monday, November 14, 2005 10:06 PM Cc: mono-devel-list@lists.ximian.com Subject: [Mono-dev] COM Interop in Mono Hello all, Here is a brief overview of some work involving COM Interop support in mono. I'm sure I'm wrong on multiple things below, so feel free to suggest/correct. COM Standard Don't feel like saying alot. Lots of docs available. MS COM Interop Again, well documented. Especially via '.NET and COM: The Complete Interoperability Guide' by Adam Nathan. COM interop is twofold. 1. Managed Client, COM Server - This allows for unmanaged com components to be used in the managed runtime. This occurs via runtime callable wrappers (RCW). The RCW is a managed wrapper that manages a single unmanaged com object. The lifetime of the COM object is managed via the RCW; the RCW's lifetime is managed like any other managed object. Also, the interop can occur via early binding (using the Interop assembly and vtables) or late binding via reflection. 2. COM Client, Managed Server - In this case, an managed object is exposed to COM via a COM callable wrapper (CCW). The CCW behaves like a normal COM object to the client. The CCW exposes interfaces corresponding to the managed object's methods/properties, as well as IUnknown, IDispatch, and other interfaces. Another thing to note about COM interop is the runtime support for casting. Normal managed objects fail upon a cast when an interface is not implemented by that object. A RCW will try to cast the normal way, via the metadata provided about the class. If the cast fails, the runtime will then call QueryInterface on the underlying COM object for the interface in question. If the QueryInterface succeeds, then the runtime allows the cast to occur. I'm ignoring other semi-important (depending on your situation) aspects of COM interop such as COM threading, connection points, etc. Old Approach (all in C#, runtime agnostic; i.e. worked on MS. Net and Mono) I'm not going to spend much time on this. This work initially grew out of looking at some code by Peter Bartok in Win32Dnd.cs in MWF. A COM interface (really just a vtable) is essentially a structure of function pointers. Function pointers can be marshalled as delegates (in 2.0) and vice versa. So, for each COM interface a corresponding struct of delegates was defined; except, the all the method signatures were modified to take an IntPtr as the first argument, the 'this; pointer. Once the COM object was created, it was QI'd for that interface. Then, the returned pointer (which points to the vtable) was read via Marshal.ReadIntPtr. This value is then marshalled as the struct previously defined. The delegates can now be invoked. In addition, custom marshallers were written for the marshalling of interfaces and BSTRs. Tricks were played with pinning, GCHandles, etc for lifetime management. Also, to get around the fact that there was no runtime support for 'late' casting, Reflection.Rmit was used to build dynamic wrappers. This method proved useful, but ugly and inefficient to say the least. Current Approach This method involves the mono runtime directly. Currently, I'm focusing on RCW, i.e. using COM components in managed code. I'm also using the Interop assemblies generated via MS's tlbimp.exe (in the future, someone could easily write a tool to generate compatible assemblies via an XML definition or whatever instead of from a typelib). When a RCW class is loaded by the runtime, extra space is allocated in the class instance to contain the unmanaged object pointer. Upon creation of a RCW, the underlying COM object is created via CoCreateInstance and it's pointer is stored in the RCW. All methods on a RCW are marked internal call. Thus, for each method a managed->unmanaged wrapper is generated. Currently, here is the process for that. 1. The pointer to the COM Object is obtained from the RCW. 2. The function pointer to the method obtained. The method layout in the interop assembly is the same order as that of the vtable of the COM object. Thus, the offset of the method on the RCW is used to offset into the vtable of the COM object, and get the correct function pointer. 3. The interface pointer and method arguments are pushed on the stack. If the managed method has a return value, a reference to a local variable of that type is pushed on the stack as the last arg to the COM method. The function pointer is called, expecting a int32 as a return value (an HRESULT that will be translated to an exception in the case of a failure). If there is a return value, this return value is pushed onto the stack and the method returns. Currently, this mechanism allows for the use of a COM collection of doubles in managed code. TODO (lots, I'll stick to near term) 1. Get lifetime management of COM object working correctly. Perhaps RCW will need finalizer that calls Release on COM object? 2. RCW has one pointer to COM object, but COM object has multiple vtables. Need correct vtable for current interface that is being called. 3. BSTR marshalling 4. Interface marshalling 5. Use COM marshalling rules instead of PInvoke rules 6. 'late' casting 7. Wrap this into all into a separate library, and communicate with runtime via API so no component technology specific code is in mono. ... 58. CCW 59. connection points etc. I know very little about XPCOM, but I understand that it is quite similar. This should be able to be extended to that quite easily I believe. Thanks, Jonathan _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
cominterop.diff
Description: cominterop.diff
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list