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. > > 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). > > 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. > > o RpcTry/Except/etc. Ugh, what a $&^@$*% train wreck. > > More-or-less unfixable, and not widl's fault anyhow. ATM I may > > hack around this using some evil, incorrect, and, frankly, > > downright offensive macros. Long term, of course, I'm interested in > > seeing exception handling souce-compatibility in wine... perhaps, > > winegcc, or some cousin, could parse VC++ __try & family and > > generate wine-compatible __TRY & family to match? Given the > > freedom to parse/generate, regardless of the implementation > > specifics, it becomes a surmountable problem IMO. > > 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. > 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... 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? Or anything bad about using them? Perhaps, wine already does use them and therefore it's "A-OK"? There are other issues, of course, like how to generate unique (but preferably not /too/ unique) function names on-the-fly... but since the lexical scope is only that of the enclosing function, this also is probably not a show-stopper. Even in the best-case scenario, it will not look too pretty in the debugger. But exceptions never do anyhow... I dunno, I can't think of a compelling reason this couldn't work. It's probably worth at least the infamous "college try" (apparently universities try harder than people or something? WTF is a "college try" anyhow?) Quip: Thank god they never got around to implementing interface inheritance and garbage collection for COM! Just imagine the mess... -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot