more desperate cries for help...

[Greg Turner]

Beware of this one, It's long, and I've spliced together at least two 
(three?) posts, and probably quoted things out-of-order...

In reply to my question about "why use LPC," Ove wrote:
> Probably because it's "the Microsoft way" (i.e. the right thing for
> Wine), but it wasn't me who recommended it. I'm fine with named pipes.

oops, sorry I attributed that to you.

> But why is it such an imperative to implement a superfast RPC
> transport right now? Wouldn't the old rule "get it working first, then
> optimize" mean more than usual when it comes to what we're dealing
> with here, undocumented stuff that we don't fully know how is supposed
> to work, and may not get right? Why make getting it right harder by
> adding a lot of complexity, instead of adding infrastructure?

good point, that seems like the logical way to proceed.

I wrote:
>> It seems to come down to: What are the absolutely most efficient ways 
>> for a wine developer to get:
>> 
>>  A. some shared memory,
>>  B. atomicity controls,
>>  C. IPC signalling (can be used to implement B., given A.)

and Ove replied:
> What do you want to signal? It sounds like all you can implement with
> just this is busy-wait-loops. Surely you're not thinking cpu-wasting
> busy waits are more efficient than the wineserver?

Signalling can be used to avoid crazy spinning in busy loops; that's
why I mentioned it... technically, I believe all you need is (A), if you 
are prepared to tolerate busy-wait-loops (which I'm not)... anyhow, I'm 
defending a bad idea here...  I'll get into that in a sec, but I think 
you've sold me on the idea that we should keep it simple rather than 
get all freaky about performance issues right off the bat...

Back to Ove:
> The endpoint mapper is a service that's accessed through RPC, it
> shouldn't be a client-side feature in shared memory. In Windows, the
> local endpoint mapper is hosted by rpcss.exe. (In Wine, it could be
> implemented by launching a Wine-rpcss whenever we need an
> endpoint-mapping service to hold an endpoint registration, and make it
> stay alive for (only) as long as the endpoint registrations it holds
> are still alive.)

Smart!  Now that you mention it, I remember reading in the DCE spec that 
this is, indeed, how it's supposed to be (not the rpcss part, but the 
idea that RPC itself is used to implement the endpoint mapping).  It 
seems a little screwy to me (especially in light of the chicken-and-egg 
issue it creates) that DCE should dictate the means by which you 
achieve the result, as opposed to the result itself; but that's exactly 
what they do, IIRC.

Also: we could, indeed, implement wine-rpcss as you mention.  Since it's 
not properly a "subsystem" in the MS sense of the term, maybe it's 
called "wine-epmap" but that's just semantics...  what you describe is 
totally doable, and we could convert from some low-level kludgy 
implementation to an RPC-based implementation once the necessary 
marshalling was in place... I'll give this serious thought.

Back to Ove:
> Anyway, I'll try to help with these RPC efforts soon, but I'm still a
> bit sick (and in the little time I'm still able to do stuff, matters
> of greater urgency tend to turn up), so I haven't been able to start
> yet...

heh, I know how that goes.  Your insights, alone, are helpful and 
appreciated; get well, and we will collaborate on this when you have 
the time to devote to it.

Back to Ove:
> The IDL definition of the endpoint mapper's RPC interface can probably
> be found in freedce or samba/samba-tng.

BTW, isn't freedce GPL'ed?  dce-rpc probably has 'em too... of course 
dce-rpc's licensing status in't all that clear to me either... 
!#$%#@ing licenses....  I miss the bad old days of public domain 
software sometimes.

Anyhow, see below for my "final answer"

later, On Monday 28 October 2002 05:48 pm, Ove Kaaven also wrote:
> On 28 Oct 2002, Alexandre Julliard wrote:
> > Greg Turner <gmturner007 at Ameritech.Net> writes:
> > > o I don't yet know how to properly raise and catch exceptions in
> > >   wine.  I see some examples, but I don't see any of try/finally,
> > >   of which I am a big fan and would probably like to use.
> > >   Is there a guide somewhere on how to do these things?
> >
> > You can use the macros in include/wine/exception.h. But setting up
> > exception frames in Wine is quite expensive because the compiler
> > doesn't do it for us, so you shouldn't use them except where really
> > necessary for compatibility.

bummer.  i can see how this could be necessary.

Ove:
> It also appears that implementing RpcTryExcept ...
> RpcExcept(expression) ... RpcEndExcept is next to impossible, from
> the looks of those macros. Even RpcTryFinally ... RpcFinally ...
> RpcEndFinally would be difficult... So we'd probably either have to
> strip/rewrite exception handling from MIDL output or beef up WIDL, if
> no really clever guy can implement those macros (I don't feel clever
> enough).

this is not reassuring.  I'll take a look and see if anything jumps out 
at me.  In fact, I think I already took a look at this once and came to 
the same conclusion.   Perhaps winemaker should do something about 
these?

Ove:
> Anyway, Alexandre, what was your stance on putting MIDL-generated
> code into Wine (pending WIDL getting good enough)?

Alexandre (not Ove, as above) replied in yet another email...
> IMO this is better avoided, but if it's really necessary to add a few
> routines to enable further progress I could live with it. It certainly
> shouldn't be anything that needs to be actively maintained because
> this would be a major pain.

Pain sounds about right....  To keep it safe, for now, I guess I will 
just study the output of MIDL and then code my stubs by hand.  It'll be 
good practice for NdrClientCall2 anyhow :(  One thing I can do, to keep 
things clear, is to keep wetware-generated stub code separated out in 
the same way MIDL/widl would.  This way when widl is ready to replace 
the hand-coded stuff, we can just type "rm" (and then screw with 
autoconf & makefiles of course).  I could even use the existing widl 
implementation to generate a chunk of the xxx.idl->xxx.h file.

As for the endpoint mapping issue:  I think you have a good point, Ove, 
that we'd might as well get the damn thing working before we start 
getting greedy about performance and elegance.  Now that I think about 
it, I don't know how I got sucked into the "lets do it the right way 
the first time" mode of thinking in the first place... my intention has 
always been to take an incremental approach.

Ove mentions that he is fine with a/n (un)named-pipes-based 
implementation... me too.  So do we have a consensus that pipes are an 
acceptable compromise for the moment?  If so, I'll make a pipes-based 
wine-epmap my next milestone.  Let me know if you have any thoughts 
about this or have a better alternative in mind.

-- 
gmt

"The purpose of government is to rein in the rights of the people"
 --President Bill Clinton, MTV interview, 1993