widl patch

[Greg Turner]

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