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