widl patch

[Ove Kaaven]

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?