mirror of
https://github.com/rn10950/RetroZilla.git
synced 2024-11-10 18:00:15 +01:00
60 lines
2.6 KiB
Plaintext
60 lines
2.6 KiB
Plaintext
|
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
|