how to connect to com object "outside" from wine?

[Ove Kaaven]

man, 23.02.2004 kl. 15.26 skrev Boaz Harrosh:
> If I may summarize what I understood. There are 2 options:
> 1) It would be best to take Samba-project implementation of RPC and 
> implement wine's RPCRT4 over that. This way we are both wire-compatible 
> with DCE RPC and also we can use a ready made "libsmbclient" to send 
> COM-RPC calls the wine way. (Remote or local) from Linux-Land. In this 
> case in theory both native and builtin OLE implementations can be used.
> 
> 2) Make a Linux-Land lib that is wire-compatible with wine-RPCRT4 and 
> send COM-calls over that. Currently this approach can only use builtin 
> OLE implementation, but that could be fixed.
> 
> Did I understand correctly? If so which way would you take?

Neither of those options look much like what I meant. Let's see...

1) No, you can't take Samba-project implementation and put it into Wine.
Not possible. Wine's RPCRT4 must conform to Microsoft's low-level RPC
API *and* the DCE RPC wire protocol, but Samba's implementation *only*
care about the wire protocol; its design, implementation, and API is
completely different from what RPCRT4 needs. Wine's RPCRT4 has no other
choice than being an independent implementation of MS-RPC, without
possibility to nab any significant amount of code from elsewhere (like
FreeDCE or Samba).

The point of using Samba for its RPC client capabilities is that it's a
Linux native library, so you don't need to be a Winelib app to use it,
but you'd still be able to communicate with Wine and its RPCRT4
implementation using it (provided we make RPCRT4's wire protocol
compatible with DCE RPC and hence Samba, and implement remote named
pipes or other transport).

2) I don't get what you're referring to with "Linux-Land lib". The idea
was that Samba could be that Linux-Land RPC lib, wasn't it?

> What is Samba-RPC using, do you know?

I'm pretty sure they use named pipes. A named pipe is a multiplexed TCP
stream on a particular port. The alternative would probably be to
implement RPC in all its UDP glory, and you can probably imagine how fun
*that* would be...

Just consider that you can use attributes such as [maybe] or
[idempotent] on functions and methods in RPC, and you may get some idea.
If I remember right, if a function is marked [maybe], it means that it's
okay if RPC packets for calls of that function are lost. (Could be
useful for progress bars, since if a packet is lost, a new call will
come in later with updated info anyway.) If a function is marked
[idempotent], it means that it's okay if the function gets called more
than once due to duplicate packets (due to retransmission or routing
issues). Now tell me you'd still want to do the full UDP implementation
instead of a named-pipe TCP connection...

Well, it's possible to run RPC over plain TCP, without named pipes, but
I don't think that's a widely used feature under Windows, so it probably
wasn't a good alternative for Samba.

Of course, Microsoft also had to invent RPC over HTTP, to get some DCOM
stuff (ActiveX?) through corporate firewalls...