On 31 Oct 2002, Alexandre Julliard wrote: > Ove Kaaven <[EMAIL PROTECTED]> 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?
