[Mono-dev] BSTR Marshalling in Mono
Jonathan Chambers
joncham at gmail.com
Tue Jan 8 14:51:57 EST 2008
Hello,
Here is the first attempt at a patch. Nothing is changed with the
default configuration. Things are controlled via an environment variable
(MONO_COM), and extensible using the dllmap in the config file. The only
other current configuration is MONO_MS, which supports Mainsoft COM
components. If this looks acceptable, I will cleanup any issues and document
the environment variable.
Thanks,
Jonathan
On Dec 19, 2007 1:31 PM, Jonathan Chambers <joncham at gmail.com> wrote:
>
>
> 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.
>
> Thanks,
> Jonathan
>
>
> >
> > 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/20080108/72b8e505/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bstr2.diff
Type: text/x-diff
Size: 7385 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080108/72b8e505/attachment.bin
More information about the Mono-devel-list
mailing list