IDL/header issues

Ove Kaaven ovehk at
Fri Nov 1 06:33:56 CST 2002

On 31 Oct 2002, Alexandre Julliard wrote:

> Ove Kaaven <ovehk at> writes:
> > IDL-generated files would also eventually obsolete all the current
> > wine/obj_*.h files, but those obj_* files seem to be somewhat more
> > logically structured than MS's own IDL files, should we craft Wine's IDL
> > files accordingly, and maybe have some top-level .idl files in include/
> > and some sub-.idl files under include/wine/, like it's done now in e.g.
> > objidl.h?
> No, I think we should follow the Microsoft way. Sure it's a mess, but
> so is the rest of the API anyway... And every time we tried to do
> things better than Microsoft we ended up having to revert it.

Well, the current structure hasn't been reverted yet (probably because the
componentization only breaks the MS files into sub-files that's all
included from the MS-compatible file, it doesn't seem to try to
restructure them in any other way). I was thinking of writing an
objidl.idl that contained something like

import "unknwn.idl" /* included in the real objidl.h (encompasses wine/obj_base.h) */
import "wine/obj_misc.idl"
import "wine/obj_channel.idl"

which would make the generated objidl.h file have

#include "unknwn.h"
#include "wine/obj_misc.h"
#include "wine/obj_channel.h"

much like Wine's current objidl.h file does. Then we wouldn't have to
change all those COM-using .c file to stop including wine/obj_*.h (and I
could more easily convert the files). Or would you really prefer getting
rid of wine/obj_*.h?

More information about the wine-devel mailing list