[Mono-dev] Mono on wine redux

[Kornél Pál]

Hi,

> 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 
process.

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 
process.

After solving the loader problem undocumented internals of mixed-mode 
assembly handling are yet to be implemented.

Kornél