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
Greg Turner gmturner007@Ameritech.Net (by way of Greg Turner gmturner007@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.
On 28 Oct 2002, Alexandre Julliard wrote:
Greg Turner gmturner007@Ameritech.Net (by way of Greg Turner gmturner007@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.
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)?
Ove Kaaven ovehk@ping.uio.no 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.
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@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.
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.
-
Alexandre Julliard -
Greg Turner -
Ove Kaaven