An RPC progress report
gmturner007 at ameritech.net
Tue Oct 22 13:50:48 CDT 2002
On Tuesday 22 October 2002 12:47 pm, you wrote:
> Greg -
> I've been following the RPC merges lately,
> looks like a lot of stuff added. I browsed
> the code, but I couldn't really get a grasp
> on some of it.
That's OK, I'm not sure /I've/ got a grasp on
some of it !! ;)
> I was just wondering if
> you'd like to write an update (short, long,
> whatever) about what you've done, what's left
> to do, major stumbling blocks, etc. I'll
> include it in the next issue of Wine Weekly
Above what Ove already implemented, I really haven't done all that
much. Frankly, in its current state, it is quite possible that the RPC
work I am doing will /detract/ from the stability of wine, until the
implementation is more complete. RPC is painfully complicated,
and a victim of serious creeping featurism. Microsoft makes it worse
by providing poorly documented extentions to the protocol, and a largely
undocumented marshalling API (much of which developers typically don't
have to learn because the API calls are generated by the MIDL compiler).
My target right now is to get a "hello world" API invocation to
work across processes using wine RPC. Once that is achieved,
I plan to create a unit test for this. Then, we'll have a framework
that we can begin to extend and implement "properly." I am not there
yet, but I think I'm getting close. I just have to implement marshalling
for strings, which, in theory, looks pretty easy. There are probably many
bugs that need squashing before it works, and maybe some additional gaps
in functionality that I don't even realize exist yet... but I do think I'm
Now, what remains to be done? Well, as Ove mentions in the TODO
for his units, "a whole lot." Here are several things in no particular order:
- widl is like MIDL for wine. For wine to be a useful RPC platform, quite
a bit of work needs to be done here. widl currently doesn't generate stubs
for RPC invocation -- it will need to; this is tricky because the MIDL compiler
does some really wierd stuff. Then again, we don't neccesarily have to
make widl work like MIDL, so it could be worse.
- RPC has a quite featureful error handling mechanism; none of it is implemented
- The server portions of the patch don't seem to be getting accepted by
Alexandre. My guess is that once I have a working test he'll conceed to
let this in. To implement this properly is tricky and possibly beyond my
abilities; Ove seems to think the right way to do this is to use LPC
(Local Procedure Call, another undocumented monster). LPC has no implementation
in wine and is not going to be trivial to create.
- there are several different memory allocation schemes for MSRPC.
I don't even understand what they all are yet, much less have them
- MSRPC provides impersonation capabilities which currently are not possible
to implement in wine.
- Some transports are not yet implemented. The existing transport implementations
are incomplete. (By transports I mean, tcp/ip, named-pipes, local procedure call,
etc --- the various types of low-level plumbing that can be used to connect the
client and the server).
- Data marshalling is the means by which RPC represents data across process
and machine boundaries. MSRPC extends NDR format for this. The wire
protocol is mostly documented, but the MS API's to convert data-types in
memory into NDR are not. This, alone, is a sizable chunk of work.
- ORPC is RPC for OLE; once we have a working RPC framework, we can
use it to implement out-of-process OLE client/server communications.
This will be a huge win for wine. But again, it's a lot of work, and I'm no OLE
expert (hell, I'm no RPC expert :)
- Surely there is much more stuff I am forgetting. Like Ove said, it's "a whole lot"
of stuff, approximately as big a project as, say, DirectX.
Basically, RPC for wine is a huge beast of a project. IMO it is probably the
biggest and most difficult-to-fill hole in wine's feature-completeness ATM.
In the short term, don't expect any miracles --- I really doubt that I'm
going to "solve" this (in my spare time!) anytime soon. But, once
I start getting some results, I imagine others will be enticed to help out,
as contributors like Ove already have. (To be clear: Ove enticed me, not
the other way around: He did all the "real" work, and deserves way
more credit than me for any success I may achieve in the near future).
wish me luck,
"Oh, and of course, the fastest way to dig
a tunnel is to dig at both sides."
-- The Linux Advanced Routing HOWTO
More information about the wine-devel