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

[Ove Kaaven]

man, 23.02.2004 kl. 09.26 skrev Boaz Harrosh:
> Ove Kaaven wrote:
> 
> >I still think it would be better to use the Samba RPC client libraries
> >to interact with Wine's RPC implementation (rpcrt4). You wouldn't need
> >to implement a custom server to achieve that, it would just work, and be
> >more efficient.
> >  
> >
> 
> What are these (Samba RPC client libraries)?
> Do they belong to the Samba project or the Wine project (and where)?

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.

> Is there any kind Winelib or "Native" test that exercises these, that 
> one can examine and dissect?

I only know of the Samba source code itself.

> Do we need to use the Wine implementation of OLE than. or are we able to 
> use native OLE as well.
> If the former than I am afraid it is a little broken still.

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.

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.

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.

> If you point me to the right place I think I'll have a crack at it. I 
> like this approach.
> I'm thinking of a way to use widl with some extra  scripts to make that 
> process automatic.
> But we need the technology first.
> 
> By the way:
> Is widl able to process regular RPC calls as well, or Just COM object? 

Well, yes, to the same degree it can process DCOM interfaces - i.e. it
can still only really generate .h files, not interprocess proxies/stubs.
That would also have to be "fixed"... and I probably won't have time for
that kind of task myself anytime soon (unless I get paid or something).

> What I mean is: An IDL prototype to C function prototype. without a COM 
> scope. (That was the original use of it in MS, no? Just an RPC compiler)

Pretty much... a regular RPC interface definition looks just like a DCOM
interface, but without the [object] attribute in the interface
attributes. Without [object], the generated prototypes will look like
regular functions, without the This parameter. But the functions still
have to be defined inside an interface definition. This is obviously so
that the UUID of the interface the function belongs to can uniquely
identify the requested procedure call, even when many similar interfaces
with similar function names (but different semantics) exist.