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
