[Mono-winforms-list] General hello

[Paolo Molaro]

On 03/07/03 Dan Maltes wrote:
> >>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?

You have to draw the line somewhere. If a .net application requires
so much from windows dlls, you're better off trying to get the MS CLR
running in wine (if it doesn't already) and ignore mono.

On 03/10/03 Mike Hearn wrote:
> > 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.

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

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

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

See next reply.

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

I was talking about the dependencies inside wine that you highlighted
above.
Let's see if I can explain myself better: how much work would be needed
to create a portable dynamically linked libwine library that can be
dlopened and that would allow us to call dlsym on it and have the JIT
call the methods in it through the function pointer returned by dlsym?
With libwine I mean any of the .so libraries that represent a dll, like
/usr/lib/wine/gdi32.dll.so.
As I understand it this is not currently possible because wine has to
setup the environment to run native x86 code, but we don't need that.
If someone needs to run native win32 code, wine is the right tool for
that. mono, instead, simply runs IL code that may P/Invoke to a dll
and we simply want to redirect that call to a library that implements
the call (libwine) in native code for the current platform.

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

Yes, if that works, I'm all for it, but it will be very hard to do,
given the constraints: using the standard libpthread, having
setjmp/longjmp work, simply dlopening the wine stuff at runtime,
getting the part of thw win32 API implemented by mono not to conflict
with the wine one etc.

Thanks for your feedback.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better