different behaviors of mixed-mode assembly under .net/wine-mono/native mono.

[Hin-Tak Leung]

Hi,

I am trying to look into a somewhat curious issue about
mixed mode assembly under wine-mono.

The application works correctly under wine + MS .net 2.

With native mono on the explicit command line, either win32
mono + wine, or x86_64 linux mono on x86_64 linux,
the win32 native constructor of a class
returns a null. That's fair enough.

But with wine-mono, the application does not behave
either like .net 2 or win32 mono on the command line.
It throws illegal IL code exception.

So I have a specific question - how do I go about finding
out how the IL code exception comes about?
(I have had a couple of patches in either camp so
I am not against patching wine or mono, or wine-mono for that matter) 

And a general question: are mixed mode assemblies supposed
to work under win32 mono at all, or wine-mono definitely needed?
I saw some wine + mono discussions a while ago and
I got the impression that mixed mode assemblies are supposed to
work with win32 mono somewhat?

The application itself is available as a public download in binary form.
But since it mostly works - correctly under .net, and even the
illegal IL exception was caught, just not the null constructor.
Editing the IL code to put a try+catch around the constructor
makes it largely operational too under linux mono, so there is
not much of a bug to file; mostly a curiosity why
wine-mono doesn't behave like it support mixed-mode fully, or
not at all, but something between.

Hin-Tak

[Vincent Povirk]

> So I have a specific question - how do I go about finding
> out how the IL code exception comes about?
> (I have had a couple of patches in either camp so
> I am not against patching wine or mono, or wine-mono for that matter)

You can set the WINE_MONO_VERBOSE environment variable to a single
digit greater than 0 to get debugging information related to JIT
compilation. This should at least tell you exactly which method's IL
is being rejected.

Setting MONO_VERBOSE_METHOD will show debugging information for the
JIT compilation of a specific method, unfortunately Mono crashes
trying to parse many of the mangled names that appear in Managed C++
assemblies, so often this approach does not work for me. I've often
had to hack the code that checks MONO_VERBOSE_METHOD to special-case a
specific method name.
> And a general question: are mixed mode assemblies supposed
> to work under win32 mono at all, or wine-mono definitely needed?
> I saw some wine + mono discussions a while ago and
> I got the impression that mixed mode assemblies are supposed to
> work with win32 mono somewhat?

There is some support for mixed-mode in win32 mono, but it is disabled
by default. They are different enough that I would not use win32 mono
on Windows to learn anything about how well wine-mono "should" work.
> The application itself is available as a public download in binary form.
> But since it mostly works - correctly under .net, and even the
> illegal IL exception was caught, just not the null constructor.
> Editing the IL code to put a try+catch around the constructor
> makes it largely operational too under linux mono, so there is
> not much of a bug to file; mostly a curiosity why
> wine-mono doesn't behave like it support mixed-mode fully, or
> not at all, but something between.

Microsoft's managed C++ compiler has been known to generate IL that
technically violates ecma 335, or otherwise gives Mono trouble. We
have hacks in wine-mono for a few of these cases, but it's likely we
have not addressed all of them.

There are also features used by managed C++, such as "thiscall"
reverse-pinvokes, which are technically independent of mixed-mode, but
which are not implemented in wine-mono.