[Mono-winforms-list] General hello

[Mike Hearn]

> That's fine. Mono itself should work with NPTL. Getting wine to use the
> standard libpthread library will be a huge step forward.

Well from a recent email, Alexandre says:

"generic pthreads simply doesn't offer the functionality we need. It's
possible to use the glibc nptl pthreads, but that's only because of the
way they are implemented on top of kernel threads; this isn't a general
property of pthreads, so a 100% POSIX threaded Wine is not possible.
        
Once I get the nptl support working there will probably be a number of
things that can be done to take better advantage of the new threading
support, and any help with that is welcome. But in all cases such code
can only be added as an option, it can't replace the existing code since
we have to run on older kernels as well as on other systems."

So I guess it depends on what you mean by standard pthreads. On
glibc/NPTL based systems, I suppose the pthreads library might work, but
I'm not sure about other operating systems.

> > > 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. 
> > 
> > What is "normal emulation stuff"? The implementation of the
> 
> The x86-specific emulation, for example. Wine does a lot of tricks to
> get actual win32 code to work (ie %fs for TLS etc). We don't need that
> and I guess that stuff is part of the issue why getting wine to work
> together with mono is a problem. See, for example, the issue with using
> setjmp/longjmp and linking to wine. 

I'm now rather out of my depth, but I think WineLib apps basically skip
most of that stuff, and produce what is essentially a native app on
whatever architecture that can link to the Wine DLL/shlibs.

WineLib (ie not the PE loader) was at one point ported to PPC, so I
suppose it's relatively free of x86isms.

> Mono is supposed to be used with
> legacy code that uses those functions (and they are used internally by
> mono as well). I didn't check the wine code, but it's likely that the
> setjmp issue is related to wine having to do the setup for running
> actual win32 programs. Maybe you or another wine developer can confirm
> or deny my assumption? 

Well reading the archives it seems to be because Wine has its own
pthreads implementation. It was suggested that you don't link against
the standard pthreads library, and just use Wines, but I can see that
this might cause problems when you're not loading Wine at all (for gtk#
apps for instance).

Wine has its own pthreads because it needs to be able to emulate certain
constructs on top of it ... I don't know if these constructs are used
within the Wine source code itself, but I'd imagine they might be.

> I would love to be wrong on this issue:-)
> See, we should consider the integration between wine and mono to be
> disconnected by the x86-specific stuff, first, because we want to use
> wine to implement a chunk of API that we want to be portable also on
> different architectures and second, because dealing with that kind of
> details is not something that mono should be concerned about.
> So, think of our needs as having an architecture-independent libwine
> that doesn't have to execute native win32 code compiled on windows, but 
> just provide the API entry points.

This sounds a lot like WineLib. Also you might want to take a look at
the mplayer source code, they have taken parts of wine (copy'n'paste)
for their codec loader, which allows them to call Win32 code from native
code.

-- 
Mike Hearn <m.hearn@signal.qinetiq.com>
QinetiQ - Malvern Technology Center