widl patch

[Ove Kaaven]

On Wed, 8 Jan 2003, Greg Turner wrote:

> On Wednesday 08 January 2003 12:31 pm, Ove Kaaven wrote:
> > Feel free to recompile the .idl files after applying this patch...
> > it's not necessary, but sooner or later someone is going to try what
> > I'm currently trying... to compile MIDL-generated proxy/stub code
> > with Wine headers.
> 
> Indeed, I am doing this now with my RPC test.  I'm not sure we are 
> targeting the same stuff, however.  You can see my work-in-progress in 
> the K patchseries, which only has one (rejected) "official" patch: K01.
> 
> Actually, what I'm really trying to do is mix and match.  I want the .h 
> header to be generated by widl, and the _s.c and _c.c stubs to be 
> generated by MIDL.

Well, that's pretty much what I'm doing, except I'm working on DCOM, not
plain RPC, so I'm trying to compile _p.c. But that means that I haven't
investigated everything widl needs to do to support plain RPC.

> wire_marshall should be a barrel of laughs ;)  Maybe after I get this 
> batch working I'll whip up some tests for 'ya that use it.

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.

> 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)

> 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?

> 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).

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.

> Any chance either of the first two points will be fixed soon?

Well, I can always try fix stuff like that if you let me know what needs
to be done. Since we're working on slightly different interfaces, I
haven't always looked too hard at the problems you'll face, so it helps if
you explain exactly what should happen.