[Mono-dev] Mono on wine redux
kornelpal at gmail.com
Fri Apr 11 20:11:30 EDT 2008
> From: "Dan Kegel" <dank at kegel.com>
> That would require adding support for mixed-mode assemblies
> to the Windows version of Mono. I don't know how big a job
> that is, but I bet it'd be a fun project for the right intern to take a
> whack at. (Anyone interested?)
Altought there are relatively few mixed-mode assemblies I agree that this is
something Wine requires.
.NET Framework loads assemblies (except in-memory ones) using LoadLibrary.
This is a big difference compared to Mono. mscoree.dll!_CorDllMain is called
on older Windows versions (by the entry point in the assembly) and Windows
XP and later versions implement special processing for managed DLLs in
LdrLoadDll: _CorValidateImage is called that does fixups and replaces
entry-point as well. _CorImageUnloading is called when managed images are
unloaded. Also note that __CorExeMain is called for managed executables
instead of entry point by XP and later.
This loader support is required to support .NET Framework security engine
that could be entirely "disabled" if the real PE entry point were executed.
This is possible on Windows 2000 for example.
I believe that this loader hack should be implemented in Wine as well for
security reasons. Also note that Wines mscoree.dll creates a new mono.exe
process but a better solution would be to use mono.dll in the actual
Back to mixed-mode assemblies: LoadLibrary is required for mixed-mode
assemblies because they contain native code that may assume and code
compiled with Visual C++ actually requires the DLL to be loaded using
LoadLibrary. This requires some modifications in Mono but there is a bigger
problem. Currently Mono can be used with .NET Framework in the same process
so calling LoadLibrary would load the image into .NET Framework rather than
Mono. For proper LoadLibrary support Mono should behave if it were a .NET
Framework version and provide mscorwks.dll that were called by mscoree.dll
just like for any real .NET Framework version.
Doing this would make Mono and .NET Framework mutually exclusive within a
After solving the loader problem undocumented internals of mixed-mode
assembly handling are yet to be implemented.
More information about the Mono-devel-list