Including Mono within a Wine package - should Wine expect this?

[Kornél Pál]

Hi,

I am almost complete with implementing mixed-mode support for Mono only some 
code cleanup is remaining. Note that however this still will not support 
MSVCRT becuase that assumes that is running on .NET Framework. Also note 
that applications using unmanaged API (COM interfaces and DLL exports) of 
.NET Framework will not be compatible with Mono because those APIs are not 
implemented by Mono.

If my patch will be accepted you will see the changes in SVN trunk of Mono.

> From: "Dan Kegel" <dank at kegel.com>
>> On Sun, Apr 13, 2008 at 11:14 PM, Roderick Colenbrander
>> <thunderbird2k at gmx.net> wrote:
>>>  What we really need is mono's windows.forms to be layered on top of 
>>> gdi32 and user32 for windows controls like buttons, textboxes and so on 
>>> .. As lots of programs do overrides using native dlls on them, so that's 
>>> why it should be real windows controls with a wndproc.
>>>
>>>  Ironically the current situation is for a part our own issue. Years ago 
>>> Mono's windows.forms used winelib. They moved to a managed 
>>> implementation because they had wine integration issues and we weren't 
>>> that cooperative. Further they didn't like the 2d performance much 
>>> (likely due to the lack of a dib engine ..). They might be reluctant to 
>>> Wine.
>>
>> Yup.  We have to really get our act together, then undoing the fork
>> might make sense.

Undoing the fork is not that easy because the current System.Windows.Forms 
uses it's own rendering engine and low level parts have been completely 
rewritten to support platform independent rendering and message processing. 
It supports low level WndProc functionality but I don't know how much is it 
compatible with Microsoft's implementation.

Kornél