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.