> On Sun, Apr 13, 2008 at 10:11 AM, Steven Edwards <[EMAIL PROTECTED]> > 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: > 1) support for mixed assemblies in Mono for Windows > 2) 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 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
