more desperate cries for help...

[Greg Turner]

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?

o If we want MIDL generated code to compile in winelib, we are
  going to have to implement the RpcTryExcept and RpcTryFinally
  macros.  I think I heard somewhere that, these are somewhat
  mysterious macros, i.e., their implementation is based on compiler
  magic instead of normal header files... how on earth shall we deal
  with that?  I tried grepping the psdk header files and they map to
  __try, __except, __finally, and so on.... does wine have those?

Thanks again for any assistance,

--
gmt

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

[Alexandre Julliard]

Greg Turner  (by way of Greg Turner ) 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.

[Ove Kaaven]

On 28 Oct 2002, Alexandre Julliard wrote:
> Greg Turner  (by way of Greg Turner ) 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.

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).

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

[Alexandre Julliard]

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

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.

[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  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.

[Greg Turner]

On Monday 28 October 2002 09:51 pm, Greg Turner wrote:
> 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.

I just remembered why DCE specifies the endpoint mapping mechanism with 
such particularity... it needs to work across hosts (duh).

I'm going to try to look into some of the issues we've been discussing 
some more after work today; perhaps, now that we have a marshalling 
prototype that works (at least so long as there's no mismatch in data 
representation), it wouldn't be too hard to just flesh out the 
remaining marshalling features needed by the endpoint mapper.  This 
might be wishful thinking, but If DCE says we have to use RPC for this, 
they probably also provide the neccesary IDL or pseudo-IDL in the spec.

I guess I'm back to a "do it right the first time" mentality with this 
line of thought, but if I'm going to all the trouble to move the 
endpoint mapping features from the wineserver to a separate (winelib) 
executable, I'd might as well just code it to spec from the beginning.  
This would also allow us to begin interoperability testing sooner, 
which is a very good thing IMO.