A similar project to below would be the use of windows ODBC drivers under unixODBC.
(where/how does one add a "Fun project" suggestion)
There are few example projects that do Just that. One is right here at home and for some reason these people do not want to come forward and spill the beans. So please people ...
A. How is the Netscape-plugin-to-OCX works in CrossOver-plugin. Is that an out of process plugin embedded inside the browser X-window? What is the out-of-process (RPC) communication between the Netscape-plugin and the wine-OCX-host? What is the X protocol that lets one process host another process drawing?
B. MPlayer, and others, are known to host Codec DLLs from windows like divx-avi and other. Do they use wine. or is it a code rip like the ndiswrapper (http://sourceforge.net/projects/ndiswrapper/) I think it looks like a wine derived loader.
I have an idea/question: Is the out-off-process COM work complete? (It must be for OLE2 and office to work). What would be the difficulty of implementing Just the out-of-process COM client side as a stand alone library. Then an out-of-process (.EXE) "Control" could be written for any export type of functionality as above. and the COM client library used on the Linux side to interface with that Control.
On the Linux side one has to have the:
1. CoCreateInstance( ...)
2. Virtual table stub functions that RPC to the Controls out-of-process object virtual table.
3. Map back of Event Objects (Opposite of 2)
I do not see any reason why the same exact COM/wine code (OK with some modifications) could not be encapsulated inside a stand alone Linux library.
Does above opens the possibility for a GNOME or KDE universal OCX hosting?
Does above opens the possibility for a universal Hosting of KDE-parts and (what is the name of the GNOME Controls) in an OCX host like IE or word?
Free life Boaz
Mike Hearn wrote:
On Wed, 2003-11-26 at 21:31, dim owner wrote:
So, a (the) big question is, how can we get this windows app to compunicate with UNIX processes?
It's tricky. The easiest way is simply to convert the Gimp into a Windows program by compiling it with WineLib. No, I don't know how to do that, Dimi is the expert here. That means that in order to use Photoshop plugins in the Gimp you'd need a special build of the Gimp and Wine installed and setup correctly. That might well be acceptable, I don't know.
Longer term it'd be nice to decouple them, maybe using RPC, or maybe by figuring out what stops us loading wine into an already initialized process.
