[Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.

Dan Maltes dan@astusa.com
Fri, 2 Jul 2004 10:26:12 -0400

I completely agree Peter, the SWF dependancy on Wine was just too unstable.

Dan Maltes

-----Original Message-----
From: mono-winforms-list-admin@lists.ximian.com
[mailto:mono-winforms-list-admin@lists.ximian.com] On Behalf Of Peter Dennis
Sent: Thursday, July 01, 2004 10:35 PM
To: Steven Edwards; mono-winforms-list@ximian.com
Subject: Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms

>Rather than spending a whole lot of time rewritting things wouldnt it 
>be better to help the Wine project get stable and move to the 1.0 goal?
>There is a roadmap and TODO on Winehq of things that are needed for 
No, it wouldn't. Even if Wine already was 1.0 we still would not have the
portability we're trying to get (ie. run on Solaris Sparc, Mac OS, etc) and
debugging would still be almost impossible (Wine does funky stuff with
register for thread storage, special stuff would be required to setup
Mono-created threads before they'd be able to call Wine functions, etc).
Also, there doesn't seem to be much interest from the Wine community to do
anything that helps using Wine with SWF/Mono. We've had to resort to some
quite complicated mechanisms to even be able to use Wine as a shared,
runtime attached library, after Alexandre rejected a patch that only touched
six lines of existing Wine code and added a new library to Wine, to allow
straightforward use of Wine as a library. Having to take instead the
complicated route it now means that many people are having problems getting
SWF to run at all, with due to strict path dependencies.
Another problem was that we had to spend way too much time tracking what
changed from one Wine version to the next. For example from April to May,
the wine_get_unix_file_name() function arguments were changed (I'm not even
asking why it was changed instead of introducing a new function with
different arguments and leaving the old one for those people who might use
it). Since I can't require always the latest Wine version, I have to come up
with code figuring out what Wine version might be running, and write code to
make version dependent Wine calls. I'd rather spend that time improving SWF.

Notice how people complain on this mailing that they're having problems
getting even basic stuff going? The SWF code works, it's the interaction
with Wine that's mostly causing the problems. Again, as I said, it will
become much easier for the regular user once the Wine dependency is removed
and the controls are all in managed code.

>Also I do development for the ReactOS platform. How is this going to 
>effect Mono and System.Windows.Forms running on Windows and ReactOS?
Not at all. If ReactOS is in fact Windows compatible you just run SWF as if
you were on Windows, with it's Windows driver.


Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com