[Mono-winforms-list] General hello

[Mike Hearn]

> 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.

I can investigate if you like, but as I said I think the main threading
problem is that Wine doesn't use pthreads, it uses its own version,
because pure pthreads doesn't provide good enough support for certain
windows features. Now that NPTL is being phased in, Wine is busted in
all distros using the new glibc - Phoebe for instance.

As you can imagine, that's a cause for concern for us. Alexandre is now
busy porting Wine to the new NPTL/glibc threading system, so it'll
continue to work on newer distros.

As part of that, I believe it should become possible to link wine
against pthreads with few or no problems. I'll double-check, but that's
the impression I got from the mailing list.

> 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
GDI/USER/COMCTRL libraries depends on NTDLL etc etc, just as it would in
Windows. That's why it's a nearly exact emulation. Pulling in the
controls library involves pulling in many other parts of Wine.

> 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.

Most wine dependancies are dynamically loaded these days (ie freetype),
the actual "hard" dependancy list is remarkably small, basically X11
support and glibc:

http://www.winehq.com/news/?view=160#Wine's%20Library%20Dependencies

> 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.

I think it makes more sense to try and have the whole of wine available
if you need it, that way assemblies using P/Invoke for other Win32 API
calls will still work (in theory).

I'll check up on what the implications for Alexandres current threading
work really are with respect to you guys, and get back to you.

thanks -mike