Fun projects?

Mike Hearn mike at theoretic.com
Thu Nov 27 12:45:58 CST 2003


On Thu, 2003-11-27 at 17:26, Boaz Harrosh wrote:
> 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?

I don't know, but I think it uses out of process embedding with some
simple IPC to control it.

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

MPlayer uses a heavily hacked up version of the wine loader. Not sure
about ndiswrapper.

> I have an idea/question: Is the out-off-process COM work complete? 

Partly, but with a few major caveats, like : we don't have the ability
to do the full solution without some MS tools. AFAIK widl is not
complete enough to replace midl, and it cannot produce TLB files. Maybe
widl can spit out the old-style marshaller code, I'm not 100% sure. It's
not feature complete. The wire protocol is not DCOM compatible.

> (It must be for OLE2 and office to work). 

Well, most use of OLE is in process to be honest.

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

Yes, you could use DCOM I guess, but the main problem is that it's
really hard to implement using C and WineLib. I've written a COM object
for Wine before, it was not much fun. More complex cases would be very
verbose. It'd probably be easier to use something like DBUS.

More to the point, in order to use DCOM you'd need to link Wine into the
client process as well, at which point you'd need to make the app a
WineLib app so you might as well just skip it and do it direct.

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

Our DCOM/OLE implementation uses the Windows API. It's not written to be
standalone.

> Does above opens the possibility for a GNOME or KDE universal OCX hosting?

If you wanted to do such a thing, something like ReAktivate or whatever
it was called would work. I'd use DBUS rather than a hacked up custom
RPC protocol though.

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

Doubtful. That'd be quite hard, and depends on how similar KParts and
Bonobo controls are. I'm not sure why you'd want to do that anyway - use
cases?

thanks -mike




More information about the wine-devel mailing list