[Mono-dev] BSTR Marshalling in Mono

Jonathan Chambers joncham at gmail.com
Wed Dec 19 13:31:03 EST 2007

On Dec 19, 2007 11:05 AM, Paolo Molaro <lupus at ximian.com> wrote:

> On 12/19/07 Jonathan Chambers wrote:
> >       COM Interop support in mono works pretty well for most basic uses,
> but
> > has some limitations when it comes to strings. Mainly, BSTR marshalling
> on
> > non-Windows platforms is just a default implementation. The problem is
> that
> > most COM systems (both Mainsoft's COM and Mozilla's XPCOM) have specific
> > requirements on strings. They need to follow a certain format (usually a
> > length prefixed string), use special allocators/deallocators, and use
> the
> > correct byte size (2-byte vs. 4-byte encoding).
> [...]
> > 1. Expose some methods in the runtime so users could embed mono and
> adjust
> > the BSTR marshalling behavior with callbacks. Something like
> > mono_set_bstr_to_string_marshal, mono_set_bstr_from_string_marshal,
> > mono_set_bstr_free. This would require users to embed mono.
> >
> > 2. Use the dll map in the config file to let the user specify entry
> points
> > to perform BSTR marshalling. This seems a better choice than the first.
> > There is then a technical question as to how to implement this.
> The second solution would be better as it doesn't force embedding mono.
> For this new feature, though, we'd need to be able to handle both
> xpcom and COM at the same time, so a global setting wouldn't be enough.
> Is there a way we could use to distinguish the two cases at the time
> we're emitting the marshaling code?

Only by flagging the types (at the class/interface level) with some sort of
attribute. [ComSystem("XPCOM")] or something like that.

> As for the implementation, we could load a shared library that
> implements the needed bstr methods (this is indeed how I planned at the
> time the COM support would work), but these shared libs would need to be
> separate from mono, as we don't want the mono build to have to depend on
> xulrunner or com dev libs to be installed.
> Or we could see if it's possible to access the stuff we need with
> dlopen/dlsym directly on the xpcom/com libs and use that inside the
> runtime: this ahs the advantage that there is no build or runtime
> dependency (unless the feature is actually used at runtime) and the
> small drawback that the two systems are hardcoded (though we'd hope few
> other com-like systems will be developed).

This would work, as I think we would only need a few entry points. COM
strings are well defined, but I am not so sure about XPCOM. I think they
have a variety of strings, and least historically. Some are not simple
strings, but C++ classes AFAIK.

I'll work up a patch and send something in.


> lupus
> --
> -----------------------------------------------------------------
> lupus at debian.org                                     debian/rules
> lupus at ximian.com                             Monkeys do it better
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071219/31cdac79/attachment.html 

More information about the Mono-devel-list mailing list