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.
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.
I encounter the following gaps:
o widl doesn't generate forward declarations for MIDL_user_allocate and MIDL_user_free, should be trivial to fix.
o widl doesn't parse the implicit_handle stuff in the .acf, which cause MIDL to put an extern declaration in for the handle.
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.
Otherwise, it works perfectly. Good work!
Any chance either of the first two points will be fixed soon? This would leave me with only one inelegant hack (two if calling MIDL counts), and an otherwise tolerable build process.
Thanks,
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.
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...
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?
On January 8, 2003 06:47 pm, Ove Kaaven wrote:
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.
I think having such support would be _extremely_ cool! Most people use gcc anyway, so 99.9% of people would benefit, and it's one of the outstanding things for Winelib we don't yet have a decent solution for.
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).
Yeah, they've been in there for as long as I can remember. But this is academic anyway, you need a new compiler (preferably >= 3.2) for anything non-trivial anyway, so...
On Wednesday 08 January 2003 02:53 pm, Ove Kaaven wrote:
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.
I have a prototype of this and I think it's going to work. Patches (or at least RFC's) should be forthcoming....
-
Dimitrie O. Paun -
Greg Turner -
Ove Kaaven