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

[Steven Edwards]

Hello Peter,

I am not trying to be rude but...

--- Peter Dennis Bartok <peter@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