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

[Boaz Harrosh]

Ove Kaaven wrote:

The Samba project is about communicating with Windows clients and
servers, using the Windows protocols. For many services (authentication,
printing, directory services, etc), modern Windows versions use RPC, not
SMB. So the Samba folks have been forced to write a RPC protocol stack.
This RPC stack should be available as a library (libsmbclient probably)
to native Linux apps. I think they have a utility to generate
marshalling code for any RPC interface, which could enable native Linux
apps to access Windows RPC services through libsmbclient. This could
prove useful because DCOM is built on top of RPC, though I don't know if
they have any native DCOM support yet.
 

 


Communication happens on the RPC level, not the COM/OLE level. Builtin
or native OLE shouldn't matter for this (though native OLE probably
doesn't work with Wine's RPCRT4 for unrelated reasons).
But currently Wine's RPCRT4 is not wire-compatible with anything but
itself. There are many alignment issues that we currently don't take
into account, for example. To use Wine's RPCRT4 for this, it'd have to
be made wire-compatible with DCE RPC, or at least enough so to
communicate with Samba. On the other hand, the native RPCRT4 would also
take a fair bit of work to get to work under Wine.
 

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?

I imagine this Samba<->Wine RPC communication to happen over named pipes
(once Wine supports remote named pipes), but other transport protocols
could probably be used if easier to implement.
 

What is Samba-RPC using, do you know?

Now all of this may sound like a fair amount of work, and it probably
is, but it's work that would really have to be done anyway sooner or
later, so if you're looking for a general solution, it'd be more useful
time spent for Wine to work on these things, rather than writing a
dedicated server app.
 

I'm with you 100% on that. This single fixture can be what makes Wine 
main-stream Linux just like samba is?

Juan, can you see the light at the end of the...?

Pretty much... a regular RPC interface definition looks just like a DCOM
interface, but without the [object] attribute in the interface
Good I'll give it a go.