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

[Peter Dennis Bartok]

May I remind you that this thread was started by you, asking why we are
abandoning Wine, not by me complaining about Wine. All I did was give you
the reasons why we are no longer using Wine. You may not like them, you may
disagree with them, but the decision has been made. And there is really
nothing to be gained in nitpicking or pointing fingers.

I don't understand the comment about managed Quake, but we don't have to
create managed Wine. We simply have to create the SWF controls in managed
code and the underlying SWF framework. Wine doesn't have anything to do with
the framework, anyway, so it's down to the controls. And even by using the
Wine controls we still would have to either modify Wine to support the
additional functionality required by SWF, or subclass them, basically
recreating the drawing code for those controls and just using the WndProc
messages from Wine. So, you can see it's really just a small step to then
drop Wine and handle the management of Windows ourselves instead of using
Wine for it.

Not trying to be rude either. You asked, I answered.

Peter


-----Original Message-----
From: "Steven Edwards" <steven_ed4153 at yahoo.com>
To: "Peter Dennis Bartok" <peter at novonyx.com>;
<mono-winforms-list at ximian.com>
Cc: <wine-devel at winehq.com>
Date: Thursday, 01 July, 2004 21:03
Subject: Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms
plans.


>Hello Peter,
>
>I am not trying to be rude but...
>
>--- Peter Dennis Bartok <peter at novonyx.com> wrote:
>> >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
>> >1.0.
>> 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
>
>Well Winelib does run on PPC and the port to Sparc is mostly done. 99%
>of Wine even compiles on Alpha here for me. See
>
>http://www.winehq.com/site/status_porting
>
>> 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.
>
>I was there when Miguel came online to ask why the patch was not merged
>and I also seem to recall Alexandre proposed a fix the would work and
>seemed to make Miguel happy.
>
>See:
>http://www.winehq.org/hypermail/wine-devel/2004/03/0150.html
>
>> 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.
>
>Once again how can you fuss about unstable interfaces on a project that
>does not have a stable release? You could work with Winehq to create
>those stable interfaces.
>
>Besides how can you blame the Wine project for tracking changes when
>the first patch Mono submitted was this?
>
>http://primates.ximian.com/~duncan/mono-wine/sources/mono-wine.patch
>
>A whole bunch of #ifdefs and other kludges that violates Winehq coding
>standards.
>
>> 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.
>
>Alright well I am not claiming to know very much about the project.
>Like I said I only lurk here because I care about how its going to run
>on ReactOS. I guess my final though on the matter is that if Vertigo
>Software could make a mananged Quake2, how hard can it be for you to
>make a managed Wine?
>
>Thanks
>Steven
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Mail - 50x more storage than other providers!
>http://promotions.yahoo.com/new_mail
>_______________________________________________
>Mono-winforms-list maillist  -  Mono-winforms-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-winforms-list
>
>