[Mono-winforms-list] Re: win32 api dlls

[Roderick Colenbrander]

I would really subscribe to the wine-devel list were most wine discussions
take place. Some more projects want to use wine stuff without turning their
apps into winelib apps.

The wine project hardly knows what is going on here. Only a few know (Mike
Hearn, Steven Edwards and perhaps some more).

Maintaining this "small" fork will be a pain. Under the hood wine already
contains some new important changes and because of those your work can be
redone. The latest distributions (rh9, mdk9.1 and others) use glibc 2.3x combined
with nptl. All this new stuff breaks wine and the latest wine version is
needed for it. (needs to be compiled using --with-nptl). So the patches already
need an update and there needs to come a way to compile with or without nptl.

So subscribe to the wine-devel list and tell what is going on and start the
discussion.

Roderick Colenbrander


> On Wed, 2003-04-23 at 20:53, Miguel de Icaza wrote:
> > Hello,
> > 
> > > > The problem is that other people can not do the diff, only you know
> the
> > > > exact version that you used as a base.   So it is much more
> convenient.
> > > 
> > > Why to do not just compile the code  from my tarball and copy the
> required
> > > files into required places (or symlink them). I see this is not
> convenient,
> > > but
> > > this is only for now. later all will be taken on their places.
> > 
> > The issue is not with the compilation Vlad, the issue is that people on
> > the list need to understand the changes, and they need to discuss those
> > changes, to come up with a plan.
> > 
> 
> The changelog is being prepared. 
> 
> > How to integrate it?  Where to send patches?  Will Wine take all the
> > patches?  Which patches they wont?  What is controversial?  Can we use
> > the same build?  Can Wine users have two builds?
> > 
> 
> We will produce a tarball with patches and a build script to make the
> shared objects. While the code is not included in Wine tree, we'll have
> to maintain the patches and they will be based on a Wine snapshot.
> 
> Current development is based on 20030318 snapshot. When there are
> significant changes/improvements in Wine we'll migrate the patches up to
> be based on some newer slice of time in Wine history ;)
> 
> We live in the hope that in time this code would be included in wine
> tree but until that may happen I don't see an alternative to this.
> 
> I think for now Vlad could maintain the patches. Should we have a place
> in mono winforms CVS for them?
> 
> The shared objects should live in peace and harmony separate from an
> existing Wine build so people who want to live on the bleeding edge with
> Wine proper should be able to do so. What will be needed is a patched
> wineserver running in different port, under a different name. 
> 
> > As you can see there are plenty of open questions, and we need to
> > discuss those issues.  Hence our need to have patches.
> > 
> > Miguel
> 
> Yrjänä
> 
> -- 
> Yrjana Rankka                      //  ghard@openlinksw.com
> Developer                          //  http://www.openlinksw.com
> OpenLink Software Ltd              //
> ODBC, XML & E-Business Infrastructure Technology Providers
> 
> _______________________________________________
> Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-winforms-list
> 

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!