better support for mixed-mode assemblies, and sort of regression

[HinTak]

The binary is at

https://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft%20Font%20Validator/old/win32.hybrid/win32.hybrid-bin-2016_02_08.zip/download

after unzip'ing, set WINEPREFIX differently, and do

wine  RELEASE_2016_02_08.hybrid/bin/FontValidator.exe -only-tables +raster-tests -file /usr/share/wine/fonts/arial.ttf -report-dir Z:/tmp

It should produce a arial.ttf.report.xml in /tmp/.
You will find that it works correctly with genuine MS dotnet runtime (2.0), but fails with wine-mono; with wine-mono, it generates a half-written output file, and the following message:

err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
* Assertion: should not be reached at ../../../mono/mono/metadata/domain.c:495


abnormal program termination
err:mscoree:expect_no_runtimes Process exited with a Mono runtime loaded.

I wrote about this just over a year ago on wine-devel; I think there is a sort of regression from then - about a year ago, when I tried this, I got some strange messages about illegal byte code with either wine-mono or wine32 mono under wine.

The application is semi- open-source - the truetype.dll which is a mixed mode assembly, was not opened; the rest is sort of what's on the hybrid.2016-05-06 branch of https://github.com/HinTak/Font-Validator . HTH. Please feel free to ask any question on it and I'll try to answer as best I can.

Both https://sourceforge.net/projects/hp-pxl-jetready/ and https://github.com/HinTak/Font-Validator are mine.

[HinTak]

About a year ago, the program finishes running but the output file itself contains a message about illegal byte code (the program itself catches some exceptions and put them into the output). Now it does not finish running.

[HinTak]

Note you can also run to completion, by skipping the +raster-tests part of the command line. This opts out the part involving the mixed-mode assembly. It should then basically work the same way between wine+dontnet, wine+wine-mono, or native mono on linux, if you adjust for things like file path, etc. I mention this in case you need to know that wine-mono is mostly working correctly.

[HinTak]

This is 4.6.3 shipped by fedora... I'm okay to build it yourself, etc if you have things to try...

[HinTak]

Ping

[HinTak]

Still not working with 4.7.3:

you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
you are registering twice the same counter address
* Assertion: should not be reached at /builddir/build/BUILD/wine-mono-4.7.3/mono/mono/metadata/domain.c:470


abnormal program termination
005a:err:mscoree:expect_no_runtimes Process exited with a Mono runtime loaded.

[HinTak]

Thought I'd write it here also (besides at the mono upstream issue page) - The mixed mode assembly I am trying to run not only does P/Invoke but also reverse P/Invoke : it calls native code from C# code, and also passes a C# delegate to the C native code as function pointers for the C native code to call back. So it is not surprising that MONO_TYPE_FNPTR happens though it is probably rare.

[HinTak]

The assertion for wine-mono seems different - it appears the domain is empty, or something.

[HinTak]

I tried passing --verbose to win32, and the assertions are different ( mono/mono#10268 ) . current mono's mixed-mode support seems to be better than wine-mono's, as far as how far --verbose goes.

[HinTak]

It no longer asserts within wine-mono with wine mono 6.0.0, but it still does not work correctly. The mixes mode assembly itself thrown an error that's caught (and catchable) by the app itself.

[HinTak]

The current behavior of win32 mono --mixed-mode seems to be more broken than it used to be, and is filed at:
mono/mono#20976

[HinTak]

@madewokherd with wine migrating to PE I thought it us time to give it a try. Under wine + dotnet 2 it is works (as expected). With wine staging 7.12 and wine mono 7.3.0, now it seems to be getting properly into the C-half of the mixed mode assembly, and hitting on e of the self tests within the C half of it. It is throwing a Microsoft Visual C++ Runtime Library error, about "not enough space for thread data"!

[HinTak]

This is getting somewhat promising.

[HinTak]

The "not enough space for thread data" from within the application, is accompanied by heap:unsafe_heap_from_handle invalid handle 00000000 from wine.