MIDL replacement?

[Ove Kaaven]

On Wed, 20 Feb 2002, Phillip Schmitz wrote:

> Has anyone taken up the challenge?

No. And I'm not convinced that it's worth it, since it would have to emit
the strings you mention below rather than freedce code, so the core of the
compiler would be completely different, and the parser part isn't a big
deal to do with flex and bison.

> Also, while on the topic of MIDL it seems that the emitted code contains
> marshaling hints/info in special strings - does wine currently understand
> these? (undocumented of course but not that messy - people writing their own
> custom DCOM-over-other-transports stuff managed to work them out quite quickly
> - I'm sure working with people from Microsoft Research helped though :)

Do you have any URLs or something where I can get the results of that
reverse engineering?

> Would it need to be a drop-in replacement for MIDL? I suppose not but I'm not
> sure how much easier that would be (I know com-idl is a moving target with
> COM+ and new attributes etc but plain COM should be sufficient for most).

Well, it must be compatible with both Winelib and binary emulation. I
think that's all the reasonable requirements it might have. (It might also
be useful if it emitted relay code that could be traced much like
--debugmsg +relay...)

> PS I don't know if it is worthwhile starting a separate effort to make a
> "free" MIDL replacement regardless - what do people writing windows code with
> mingw etc do if they want to use COM?

Probably lift midl.exe off the net? I don't think these developers try to
create their own COM objects, though, so they don't need an IDL compiler.
You don't need MIDL to use other people's COM objects.