Roderick Colenbrander wrote:
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.
OK.
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)
But is mono modular enough, that implementing a third party Windows.Forms for Win32 mono is possible, that uses gdiplus/gdi32/user32?
Or are there other, more intertwined dependencies?
(If so, then not all is lost. A separate project may do this if compatibility is needed. This would of course lead to mono being more compatible both on Win32 and Unix.)
regards, Jakob