[Mono-dev] mixed-mode assemblies in wine

[Vincent Povirk]

2011/3/1 Kornél Pál <kornelpal at gmail.com>:
>> Another possible approach, if we don't share mscoree.dll code, would
>> be for Wine and Mono to both implement ICLRMetaHost
>> (http://msdn.microsoft.com/en-us/library/dd233134.aspx) and
>> ICLRRuntimeInfo, both of which can be accessed before a runtime is
>> chosen and loaded, and for only Mono to implement ICLRRuntimeHost,
>> which requires a loaded runtime. Wine's mscoree.dll's other functions
>> (except for the _Cor functions which will have to be special) could
>> then work based on those interfaces.
>
> This could work but if we keep the embedding API implementation MIT
> licensed, then any other project can reuse it and customize to its needs if
> needed.

Yes, I assume adding code to the Mono runtime implies an MIT license.

Let's see if we can flesh out this approach more fully.

This would mean that both Wine and Mono would implement the
CLRCreateInstance function:
http://msdn.microsoft.com/en-us/library/dd537633.aspx

Mono's CLRCreateInstance function would be part of the embedding API
(possibly with a different name), not Mono's mscoree, so that Wine can
access it directly.

Mono's mscoree would forward its CLRCreateInstance export to the
embedding API function.

All other exports in mscoree would be written based on
CLRCreateInstance and the IMetaHost interface (although Wine would use
its internal IMetaHost interface and Mono's mscoree would presumably
use one from the embedding api), except for the _Cor functions. Wine
would search for Mono installs and their runtimes the same way it does
now.

The methods GetInterface and GetProcAddress on Wine's ICLRRuntimeInfo
(http://msdn.microsoft.com/en-us/library/dd233121.aspx) would load the
appropriate libmono dll and then forward to its ICLRRuntimeInfo
implementation. LoadLibrary would forward only if Wine is unable to
handle the call itself. IsLoaded and IsStarted would forward only if
the appropriate libmono.dll is already loaded.

You should probably think about how you want LoadLibrary
(LoadLibraryShim) to work. AFAIK it's only generally used to load
fusion.dll. Wine already has an implementation of fusion.dll. You may
be able to use the native fusion.dll without any changes, or you may
want to have your own for some reason.

I think _CorValidateImage should always be implemented in mscoree.dll,
as it shouldn't require a runtime, and it is too early to select one.

As for _CorExeMain, _CorExeMain2, and _CorDllMain, those require a
runtime selection. I'm not sure how this selection should work. We
probably want the runtime version to be calculated by mscoree, and
when we forward those calls to Mono, we'll want to specify a runtime.
However, we probably want to make sure we use the same runtime version
for each call to one of these functions. Maybe we should select a
runtime on the first call to one of these functions, then use that
same selection on subsequent calls?

I'm inclined to forward _CorImageUnloading to the mono runtime if one
is loaded, even though you don't seem to use it at the moment.

It's not obvious to me how ClrCreateManagedInstance is supposed to map
to the .NET 4 interfaces (even though MSDN implies it can), and so I
currently use internal methods of Wine's ICLRRuntimeHost objects for
this. It really boils down to a call to the class's constructor with
no arguments, followed by a call to
System.Runtime.InteropServices.GetIUnknownForObject, but I can't
figure out how to do either of those things in the new API.

Both mscoree.dll's will need a way to notify the runtime that they
want libraries to be loaded with LoadLibrary instead of mapped
read-only in memory. Since this implies a promise to forward _Cor*Main
calls to the runtime, it may not be as difficult as I originally
thought.

Wine's mscoree currently uses an assembly preload hook to search the
Windows GAC for assemblies. You'll probably want to do that, but I
guess a preload hook is inappropriate on Windows because you'd end up
loading standard libraries from .NET. I'd really prefer to have Mono
doing this search (so it can ensure the proper order, and because its
GAC-searching code is probably better than ours), but my bug for this
was closed either INVALID or WONTFIX.