man, 23.02.2004 kl. 15.26 skrev Boaz Harrosh:
If I may summarize what I understood. There are 2 options:
- 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.
- 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...