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
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.
-
Hin-Tak Leung -
Vincent Povirk