Fun projects?

[Boaz Harrosh]

This question comes up a lot.
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.
>
>
>
>
>  
>