On Dec 19, 2007 11:05 AM, Paolo Molaro <[EMAIL PROTECTED]> 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 > > -- > ----------------------------------------------------------------- > [EMAIL PROTECTED] debian/rules > [EMAIL PROTECTED] Monkeys do it better > _______________________________________________ > 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