thunderbird2k at gmx.net
Thu Aug 30 11:51:04 CDT 2007
On Thursday 30 August 2007 18:41, Jakob Eriksson wrote:
> Roderick Colenbrander wrote:
> > O
> > I think the incompatibilities you mean are for instance that in case of
> > Mono you can mix Windows.Forms with win32 calls. If you don't like the
> > behavior of something you can call a standard gdi32/user32 function and
> > change some stuff.
> Yes! Thank you, I didn't know 100% what I was talking about.
> > Things like that work because I think the .NET version of Windows.Forms
> > maps to win32 controls. Mono renders everything itself through
> > System.Drawing. I don't think a different gdiplus.dll will make any
> > difference for this. To allow mixing of Windows.Forms with gdi32 stuff
> > everything needs to be rendered using native controls. That's what mono
> > attempted years ago using Wine but they had various Wine integration
> > troubles and we didn't come to a good solution for it.
> And wasn't one of those troubles that there was not gdiplus DLL?
> I was hoping an integration was coming closer.
The main issues were related to using Wine as a sort of 'plugin'. They didn't
want to use standard winelib. The Mono hack they proposed for it wasn't
accepted and they didn't want to distribute their own Wine. Gdiplus was also
an issue because they had to mix it with winex11.drv but that would have been
Win32 mono will be able to work on Wine. After some more integration it might
be able to embed lets say Win32 ActiveX controls and use win32 dlls. It will
never be able to use gdi32/user32 to change the behavior of some of the
drawing stuff. For that they would need to rewrite Windows.Forms to not
render the controls themselves. They will never do that. (It also means
restarting from about scratch)
More information about the wine-devel