Wine as shared library patch

[Miguel de Icaza]

Hello,

> I strongly disagree!
> 
> I'm not sure what this patch can do. But if it lets you Inject into wine 
> mid run from any Linux application or Library than it is tremendous. 
> MPlayer can use it, a unixODBC to windowsODBC can use it, web-browser 
> plug-ins can use it.

The intention is to have a module wine-sharedlib.so that you can dlopen
and call a method in there to have Wine initialize itself.  After this
you can call the API as a library.

Now, this might not be as helpful to others as you might thinkg, unless
they dlopen/dlsym every symbol they want to import (this is what we do
with Mono: every symbol we need has to be explicitly invoked).

MPlayer sounds like the perfect consumer for this though, and drivers as
well.

> Perhaps if Migel or Peter can elaborate on what this patch can do?v
>  (Also if you could post somewhere public an example application that 
> demonstrate the use of it.)

Mono on CVS (mono and mcs modules) now have the capability of running
Windows.Forms applications.  

Windows.Forms is basically an API to create GUI applications with .NET
and its essentially a wrapper around Win32, hence our strong desire to
use Wine as a runtime library.

> 1) Can it enable a shared library to load Wine and hence even windows 
> DLLS in-process? So a Linux Application becomes a Wine-Lib app mid run.

Yes, it does that. 

We need that to support third party components that might want to
P/Invoke (.NET parlance for dlopen/dlsym/call) Win32 methods.

> I would like to see this patch in. I agree that a global variable is 
> bad. The Set-jump put NULLS every where, is even worse. It should be 
> with a proper interface. Maybe even a "wine_init_ex". A regression test 
> should be submitted that checks that this functionality is not broken 
> with new code patches.

The global variable is gone;  All you need is the sample program that
Alexandre posted (and its Makefile)

Miguel