On Wed, 8 Jan 2003, Greg Turner wrote:
On Wednesday 08 January 2003 02:53 pm, Ove Kaaven wrote:
Maybe. Unfortunately I'm still not entirely sure what implementations of UserMarshal is supposed to look like when the wire_marshal type contains embedded pointers. Is this supposed to be left to the NDR engine or does the UserMarshal routines have to marshal embedded pointers manually? Hmm... perhaps I should see if MS has some sample code somewhere.
I'll look at my books when I get home and tell you if I find anything about that.
OK, great. I'll probably look around a bit myself, too.
o widl doesn't generate forward declarations for MIDL_user_allocate and MIDL_user_free, should be trivial to fix.
I could probably do so if you could show me what it's supposed to look like and when it's supposed to be generated (otherwise it might take a while before I get around to looking into it)
sure, I'll provide this. You can also see examples in my patch. But rather than expect you to fish around for the info, I'll come up with some concise specification of what I need and forward it to you (will take some time, but the point is, I'll get to it sooner or later, so you don't need to go fishing for it).
OK.
o widl doesn't parse the implicit_handle stuff in the .acf, which cause MIDL to put an extern declaration in for the handle.
Right, widl doesn't handle .acf files yet. Can it be done without it?
I am not sure (quite possibly there are command-line options to do the same). This seems to change a number of things. For example, excluding the .acf changes which API's are called by the stub to ones unimplemented by wine! The whole AutoBindHandle mess is a bit of a mystery to me ATM; but, from the perspective of the .h file, it is just one line of code, an extern variable declaration. Perhaps, this is asking too much of widl in the short run, and I should just provide it myself for now.
Once I get a better patch together I'll document such deficiencies more carefully so you can refer to the source when you get around to .acf parsing.
OK. I haven't even looked into acf files yet, perhaps I need to soon then.
Currently I'm doing this:
/* ignore exception handling for now */ #define RpcTryExcept if (1) { #define RpcExcept(expr) } else { #define RpcEndExcept } #define RpcTryFinally #define RpcFinally #define RpcEndFinally #define RpcExceptionCode() 0
which, along with a few more definitions in the RPC headers (which I planned to submit sometime soonish), make my MIDL-generated _p.c files compile almost without modification (I just need to add an #undef __WINE__ at the top).
yep, that's more-or-less what I had. Should we publish these awful exception handling hacks somewhere "special" in include/ ? They are simply too evil to go into their "proper" home in the SDK headers IMHO -- the consumer of such junk-food should be forced to specifically ask for such a thing before we serve it to him as though it were a healthy, well-balanced meal.
I don't see why it can't be there if we do something like
#ifdef HAVE_SNAZZY_COMPILER #define RpcTryExcept __try ... #else #define RpcTryExcept if (1) ... #endif
People compiling Windows apps under Winelib would usually need to use a compiler with a lot of extensions anyway, and people needing to compile RPC/DCOM marshalling code should either use such a compiler, know what they're doing, or (when it becomes possible) use widl to generate such code.
Though I've been wondering if perhaps MSVC-type __try/__except support can be done on gcc by taking advantage of gcc's support for nested functions.
hehe, that is a deliciously evil idea, one that has occured to me as well... but, it sure does create some compiler dependencies...
Wine depends on gcc in a lot of ways already. But my idea is that each compiler should have a way, and we can define __try to the way of the currently used compiler, and to a no-op (like that if(1) thing) if the compiler can't do it.
OTOH, since VC supports these natively as a "language extension", and gcc has the nested functions, dependency-wise, I guess it's not all that bad. Anybody know how long gcc has had support for nested fn's in pure C?
I'm pretty sure at least gcc 2.7.2 had them (I remember seeing it in its docs).
There are other issues, of course, like how to generate unique (but preferably not /too/ unique) function names on-the-fly...
If we need that, I suppose using __LINE__ might be good enough.
Quip: Thank god they never got around to implementing interface inheritance and garbage collection for COM! Just imagine the mess...
Who? What?