[Mono-winforms-list] General hello

Dan Maltes dan@astusa.com
Fri, 7 Mar 2003 13:58:01 -0500


>>What I think can solve the problem is to have a libwine build that
doesn't include any of the normal emulation stuff, but just what is
needed to provvide the drawing and windowing API.

Wouldn't this leave out pinvoke stuff needed for cross-platform?

-Dan

-----Original Message-----
From: mono-winforms-list-admin@lists.ximian.com
[mailto:mono-winforms-list-admin@lists.ximian.com] On Behalf Of Paolo
Molaro
Sent: Friday, March 07, 2003 12:56 PM
To: mono-winforms-list@lists.ximian.com
Subject: Re: [Mono-winforms-list] General hello


On 03/07/03 Mike Hearn wrote:
> I've been working on Wine for a few months now, and thought I'd
> subscribe to this list to watch your progress, and perhaps help make

Great, we really need some sort of support from the Wine developers to
get things working smoothly.

> * threading: lately Alexandre has been committing support for NPTL
> threads, which are being phased in as part of some kernel and glibc
> changes. Apparently that'll allow you to link in Linux pthreads with
> Wine, so making things easier for you guys - but not on the current
> generation of distros. Miguel mentioned it might simply be a matter of
a
> patch to wine to include the features you guys use from pthreads.

This is the biggest problem; currently we have a clash:

*) wine provides the win32 API and it's own implementation of pthread
*) mono provides a (very limited) subset of the win32 API and it _uses_
the pthread implementation

The clash between the the win32 APIs has been solved in mono with a
link trick, IIRC.
Then we have the issue with the pthread API: currently the issue, I
think, is that mono uses some pthread functions not implemented by wine
and they are currently stubbed to allow the dynamic linker to work.
Having all the needed pthread functions in wine will solve some
immediate problems, but in the long run I don't think that's the way to 
go, because it still assumes we have to run some mono applications
through mono and some through wine monostub (and it won't be possible to
dynamically load assemblies that depend on libwine).

What I think can solve the problem is to have a libwine build that
doesn't include any of the normal emulation stuff, but just what is
needed to provvide the drawing and windowing API. I guess there may be
several dependencies issues and it may not be easy to do: we'd like the
input from the wine developers on this.
Note that if only those chunks of code are included, we would be able to
dynamically load the modified libwine when the System.Windows.Forms
assembly is referenced and there should be no need for the separate
libpthread implementation or the %fs tricks wine needs to provide to
execute windows binaries.

Cheers.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list