I know this thread is a couple weeks old, I saw it on Wine Weekly News...
[A. Julliard]
If we want to use .idl files we'll have to come up with our own compiler, and then we can put the .idl source in the tree and compile it at build time.
[Ove Kaaven]
Hmm. Even when using flex and bison, it sounds like a fair amount of work... wonder who would volunteer?
The FreeDCE Project has a DCE IDL compiler which I understand is mostly compatible with MIDL.EXE. See http://sf.net/projects/freedce and http://www.dcerpc.net/ (the latter seems to be malfunctioning at the moment).
Peter
On Thu, 6 Dec 2001, Peter Samuelson wrote:
The FreeDCE Project has a DCE IDL compiler which I understand is mostly compatible with MIDL.EXE.
Yeah, sure... the same way Samba is compatible with Windows 2000... it is, they can both speak the SMB protocol, but you can't run Solitaire on Samba... similarly, MIDL can certainly read FreeDCE IDL files (simply because MS-RPC was designed to be compatible with the original DCE RPC, except for several "Microsoft extensions"), but what these two implementations *do* (generate) with the parsed IDL is very different. Hence, there's no way we could use FreeDCE's IDL compiler. I thought some of the earlier discussion already mentioned that?
[Ove Kaaven]
similarly, MIDL can certainly read FreeDCE IDL files (simply because MS-RPC was designed to be compatible with the original DCE RPC, except for several "Microsoft extensions"), but what these two implementations *do* (generate) with the parsed IDL is very different.
So different, really? I thought both IDL compilers had basically the same purpose, to generate interface code to which you link client and server code for IPC or RPC. As I understand it, the client and server stubs use basically the same API in both IDL compilers.
I haven't investigated, but FreeDCE may not support COM directly the way MIDL does. Even so, it seemed to me that retargeting the FreeDCE compiler so that its output links and runs with the winelib COM code would be easier than writing a whole new MIDL clone.
Presumably this would require integrating the FreeDCE and Wine runtime environments. Looks like FreeDCE has a BSD-style license, so *legally* it can be done, but of course I don't know if it's *practical*....
Peter
On Fri, 7 Dec 2001, Peter Samuelson wrote:
So different, really?
Yes.
I thought both IDL compilers had basically the same purpose, to generate interface code to which you link client and server code for IPC or RPC.
For the most part, yes (though MIDL also generates typelibs).
As I understand it, the client and server stubs use basically the same API in both IDL compilers.
The IDL (input) file has the same syntax, but if you're talking about the generated (output) code, then no, they don't use the same API.
I haven't investigated, but FreeDCE may not support COM directly the way MIDL does. Even so, it seemed to me that retargeting the FreeDCE compiler so that its output links and runs with the winelib COM code would be easier than writing a whole new MIDL clone.
Not really. It seems to be far easier to write one from scratch (you have heard about stuff like flex and bison, right?) than to try to maintain two completely different marshalling implementations in the same IDL compiler.
Presumably this would require integrating the FreeDCE and Wine runtime environments. Looks like FreeDCE has a BSD-style license, so *legally* it can be done, but of course I don't know if it's *practical*....
Wine is about making existing Windows applications run, so code generated with MIDL must work. Therefore, we can't use FreeDCE's core, and without the core, integration doesn't make sense. I'm just stealing bits and pieces from it where appropriate, but believe me, if I could, I *would* stuff the whole thing into Wine, but that's not how MS reimplementations of stuff works, unfortunately.
[me]
As I understand it, the client and server stubs use basically the same API in both IDL compilers.
[Ove Kaaven]
The IDL (input) file has the same syntax, but if you're talking about the generated (output) code, then no, they don't use the same API.
I was talking about the API between my code and the IDL stubs (the one that says "server defines foo(), client calls foo(), stub code takes care of the rest") ... not the API between the stubs and the actual backend libraries. Obviously the backend implementations will look rather different. However, this doesn't matter because...
Wine is about making existing Windows applications run, so code generated with MIDL must work. Therefore, we can't use FreeDCE's core, and without the core, integration doesn't make sense.
That's the crux of the issue, and the one point I somehow managed to overlook completely. If we were only talking about *winelib*, MIDL-generated code would not be relevant: you could just tell people to recompile with the "right" IDL compiler. It never occurred to me that you also need to replace the *backend libraries* which are called by the MIDL-generated stubs.
***** Ove 1, Peter 0. (: *****
Peter
-
Ove Kaaven -
Peter Samuelson