[Bug 10467] New: Making Microsoft .NET 2.0 to work in wine, based on example app FastMD5 1.4 for NET 2.0

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10467

           Summary: Making Microsoft .NET 2.0 to work in wine, based on
                    example app FastMD5 1.4 for NET 2.0
           Product: Wine
           Version: CVS/GIT
          Platform: PC
               URL: http://www.paehl.de/english.php
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: wine-dotnet
        AssignedTo: wine-bugs at winehq.org
        ReportedBy: focht at gmx.net


Hello,

this bug id exists for the sole purpose of showing my little journey of getting
.NET 2.0 to work in wine.

This topic does *NOT* cover the MONO project in any way.
The windows version of MONO is covered by other bug reports.

DISCLAIMER: This is just a first step which aims at major show stoppers.
There are *many* issues left when it comes to managed (JIT) vs. unmanaged
(native) API code bridging.
To iron out all the bugs, many different applications are needed which cover
the whole range of .NET Framework.

I randomly chose a simple .NET 2.0 app which uses plain system.windows.forms
stuff (no fancy controls/interop).

--- snip ---
http://www.paehl.de/fastmd5_net20.zip

FASTMD5 create very fast with low CPU use a MD5 hash. Required .NET 1.1 or 2.0 
--- snip ---

Just as foreword: yes, it plain sucks to debug mixed code in wine (managed +
unmanaged) because the tools required don't work reliable (or at all) due to
several wine bugs/design problems.

Prerequisite: successful installation of .NET 2.0 Framework and wine-0.9.49 (or
GIT)

----------
If you start .NET apps they will fail with stack overflows and some exceptions
thrown.
The exception type tells us what we are dealing with: 0xe0434f4d
For the uninitiated: this an exception type exclusively thrown by .NET common
language runtime (CLR).

Using my specially hacked wine to run tools like windbg one can get a raw
estimate by looking at native method callstack:

--- snip ---
0:000> sxe clr
..
0:000> .load clr20\sos.dll
..
0:000> g
..
0:000> kb
ChildEBP RetAddr  Args to Child              
WARNING: Stack unwind information not available. Following frames may be wrong.
0034efb8 79f97065 e0434f4d 00000001 00000001 KERNEL32!RaiseException+0x78
0034f018 7a0945a4 00a11cb4 00000000 00000000
mscorwks!RaiseTheExceptionInternalOnly+0x226
0034f0dc 02fa364b 00000000 0000007f 0034f138 mscorwks!JIT_Throw+0xd0
0034f1d8 79e88f63 00000000 0012e0f8 0034f22c 0x2fa364b
0034f1f8 79e88f63 00000000 00000000 0016b200 mscorwks!CallDescrWorker+0x33
0034f210 79e88ee4 0034f2e8 00000002 0034f2b0 mscorwks!CallDescrWorker+0x33
..
--- snip ---

JIT code is at 0x2fa364b which transfers managed exceptions using
mscorwks!JIT_Throw() to native code/OS.

Lets look at CLR exception info...

--- snip ---
0:000> !PrintException
Exception object: 00a11cb4
Exception type: System.TypeInitializationException
Message: The type initializer for 'System.Globalization.TextInfo' threw an
exception.
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131534
--- snip ---

And the managed code callstack...

--- snip ---
0:000> !ClrStack
OS Thread Id: 0xf (0)
ESP       EIP     
0034f040 7b8414d8 [HelperMethodFrame: 0034f040] 
0034f0e4 02fa364b System.Globalization.TextInfo.GetNativeTextInfo(Int32)
0034f114 02fa3511 System.Globalization.TextInfo.get_InvariantNativeTextInfo()
0034f140 02fa193d System.String.Compare(System.String, Int32, System.String,
Int32, Int32, System.StringComparison)
0034f16c 02fa15a1
System.Security.Util.URLString.PreProcessForExtendedPathRemoval(System.String,
Boolean)
0034f184 02fa10b0 System.AppDomainSetup.NormalizePath(System.String, Boolean)
0034f1a4 02fa06d6
System.AppDomainSetup.SetupDefaultApplicationBase(System.String)
0034f1bc 02fa02cc System.AppDomain.SetupFusionStore(System.AppDomainSetup)
0034f1d4 02fa01fa System.AppDomain.SetupDomain(Boolean, System.String,
System.String)
0034f42c 79e88f63 [GCFrame: 0034f42c] 
0034f9e0 79e88f63 [DebuggerClassInitMarkFrame: 0034f9e0] 
--- snip ---

Some native method call in GetNativeTextInfo() seems to be the culprit.
For many (string) resource based stuff to work, a unicode OS casing table is
required.
The table for the invariant version is built from external .NLS file.
To make story short: wine does not ship the default case mapping table for
unicode characters: "l_intl.nls".
This is a "must" requirement and failure results in early
TypeInitializationException while setting up default application domain. 

Short fix: copy the file from your windows system32 directory to wine system32.
Long run fix: let wine generate/install this file. Not a big deal.

Now simple .NET _console_ based apps (like "Hello World") will work.
---------------------------------------

Stay tuned, more goodies to come ...

Regards


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.