On Sun, Apr 13, 2008 at 10:11 AM, Steven Edwards winehacker@gmail.com wrote:
Rather than ignoring mono these issues make it sound like Wine and mono should try to work together again. The EULA for the .NET runtime prohibits distributing it and using it on non-windows licensed systems so we are in much the same legal situation with IE where we have to have a replacement.
Yes, exactly. I've been discussing this a bit on the mono list.
There are two big pieces of work needed:
- support for mixed assemblies in Mono for Windows
- porting Mono's WinForms on top of Wine gdiplus
instead of Mono gdiplus (and making it more win32-ish as a result)
This would be a fine summer project for somebody properly motivated.
There will be more incentive to do this as we get Microsoft .NET working better, and it becomes clearer just how many applications need one or the other of the two items above to run.
In short: I think the path to Mono+Wine nivana at the moment leads directly through enemy territory: we have to get MS .net working better first before it's clear it'll be worth it.
- Dan
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.
Roderick