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.
regards, Jakob
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 fixable.
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)
Roderick