On Sunday 22 February 2004 03:49 pm, Robert van Herk wrote:
maman yonatan wrote:
so if I understand you properly, you say that there is no way doing from _outside_ of wine (no matter what kind of com object I have), is that correct?
Of course there is a way: you could make your own remote procedure call mechanism. Might be a very cool project, actually, to make an interface to call objects living a wine, that makes COM accessible from unix!
However, it will be quite some work. You probably need a server kind of application that lives in Wine, and a client application that lives in Linux. Then, you got to make sure that the linux app can connect with the server, and issue procedure calls to the wine server. Finally, the wine server should forward actual calls into COM, and return the result value back to the linux client.
Thus something like this:
- [COM object(Wine)] <-> 2. [Custom build COM-server(Wine)] <-> 3.
[Client application using the COM object(Linux)]
Where layer 2 is something needs probably to be implemeted from scratch.
I don't know how much is known about COM by the wine-people, but I guess it that when they succeeded in replicating the COM API, it should also be doable to make a Linux frontend to that... (??)
This is a pretty good idea. It would definitely take some doing, but one could imagine cutting and pasting lots of code from rpcrt4 and the wineserver to achieve it via unix domain sockets... this would definitely be a big boon to projects like mplayer and mono which want some way to kick wine around from a normal linux ABI environment (seems like a pretty common problem actually, I see it mentioned on this list quite frequently).
Although I've contemplated inventing something like this in the past, ATM I am /not/ volunteering. If you give me a few months (or pay me ;)) I will probably take a crack at it, but right now I am hopelessly busy :(.