[Mono-dev] mixed-mode assemblies in wine

[Vincent Povirk]

> My preferred way would be to call exports that Windows calls:
> - _CorValidateImage on image load
> - _CorImageUnloading on image unload
> - _CorExeMain instead of exe entry point
> - _CorDllMain instaad of dll entry

Is there a reason for us to add this to the Wine loader soon? I've
been putting it off because I have to ask for someone else to do it.

> - the C runtime (not the OS) should also call CorExitProcess on normal
> termination (exit)

Yes, I added this to Wine's msvcrt last week so we can tear things
down properly. Although right now that doesn't work because of the
hooks. :)

> I also planned to get rid of MonoFixupExe  and drop support for mixed-mode
> assemblies by using mono.exe and introduce a loader that would call
> CreateProcess on the managed (may be mixed-mode) .exe, inject a loader .dll
> (or a custom mscoree.dll) by modifying IAT, remove IL-only flag so that the
> OS loader will not load MS.NET mscorlib.dll, and do inicialization in that
> loader .dll called by OS loader. This would not affect functionality of
> mono.dll just would not fixup mscoree.dll by default that also would play
> more nicely with standalone verifier, dumper, etc. tools and CoreCLR.

That's interesting.

It would seem (to me) that in this case your mscoree.dll and ours can
and should be the same one. The only difference is how libmono is
found and loaded.

> I also have the impression that implementing .NET Framework functionality in
> Wine may not be the right architecture. Ideally those belong to Mono. Since
> I know that Mono does not accept GPL to runtime (requires MIT X11 license or
> special permissions to Novell; althoug is licensed under GPL) and Wine
> prefers GPL this may not be suitable.
>
> Wine loader should call mscoree.dll just like Windows loader does
> (system32\mscoree.dll is hardcoded, cannot use your own).
>
> If you prefer to keep mscoree.dll code in Wine, then I belive that Wine
> mscoree.dll should load mono.dll (as it already does) and forward the above
> five basic exports to mono.dll and implement other exports on its own by
> calling native Mono API.

My only strong reason for wanting mscoree.dll to be in Wine is so that
it can load without any Mono present (which is enough to install many
apps, and pass tests), and so that it can select between multiple
available Mono setups at runtime (in order to cover .NET versions 1.1,
2.0, and 4.0 simultaneously). For that to work, we need a dll that
loads Mono dynamically rather than linking to it, and it needs to
support both embedding ABI's.

Licensing is not an issue. Wine is LGPL, and we can use MIT code. The
reverse isn't true, but I think it would be possible to relicense most
of Wine's current mscoree code as MIT, since most of that architecture
was written by me for CodeWeavers.

Still, if you want to work on the .NET embedding API, I think we
should find a way to collaborate, in whichever project.

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.