A CURSORY AND LIKELY MISLEADING GUIDE TO MONOCONNECT
General Architecture
--------------------
The goal of this code is to provide a two-way bridge between the
CLR/.NET/Mono/C#/etc. world and XPCOM.
We want:
- Natural C#/etc. syntax for consumers.
- Acceptable performance (wrapper space and call speed)
- "Correctness" (maintenance of object identity, reference management).
- Dynamic, lazy generation of stubs and interfaces from interface-info.
We do not want:
- People distributing generated stubs.
To that end, we register for TypeResolve and AssemblyResolve events on
our AppDomain (components.cs, RegisterAppDomainHooks). When user code
references an interface or stub-proxy that we have not yet generated
(and is not special-cased, like nsISupports), our TypeResolve hook
triggers the generation of an appropriate class.
The generation of proxy classes happens in generate-proxy.cs, where we
employ the many wonders of System.Reflection.Emit to create a proxy
for the indicated interface. The proxy class for a given interface
will have specialized marshalling code emitted for the specific
interface parameters and index. There is currently virtually no code
shared between proxy methods, which is something that we should remedy
in the future: a rough census of Mozilla interfaces (circa 1.6)
indicates that generating a static helper method or delegate per
unique method signature would give us significant savings.
typeinfo.cs has a bunch of infrastructure for inspecting interface
info from the IIM. I am not particularly proud of any of that
infrastructure, but it does get the job done at present. Lots of it
is likely not even used today, since it largely predates actual proxy
generation. xptinvoke.cs is along the same lines.
(typeinfo.cpp exists mainly because we need C-linkage entry points for
P/Invoke, and secondarily because I wanted to reduce mono<->C thunking
as much as was easy.)
wrapped-clr.cs is where the CLR-implementing-XPCOM-interfaces code
should go. Today, it basically...who am I kidding? You can see the
source, it clearly does almost nothing. I have fantasies about
patching the C++ vtable with JITted delegate pointers.
There's one piece missing to this puzzle (other than all the other
pieces): we need to generate metadata-only interface assemblies for
people to compile C# against, because our TypeResolve/AssemblyResolve
tricks are not enough to get us wired into the compiler.
tools/generate-interfaces.cs is that tool, mostly.
Other things that are missing:
- AString support
- Exceptions
- figuring out a good way to map casting to QI
- a component loader
2f2ae146c0