On 31 Oct 2002, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no 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?