what to do with include/wine/obj_base.h?

[Ove Kaaven]

I've submitted a patch to move the API prototypes out of obj_base.h, and
I'd now be ready to submit unknwn.idl and unknwn.h, which would also
supersede the interfaces defined in there, but I'm unsure about what to do
with the remainder of it, namely the ICOM_* macros in there.

Note that there's a shortcoming of those macros, they don't handle array
arguments. Such arguments are binary-compatible with pointer arguments
though, so it's not a serious shortcoming for Wine and widl (which could
easily convert array args in IDL to pointer args in C), but it's a little
ugly and may have source-compatibility issues if widl is used by Winelib
code that implements interfaces with such method args.

There are standard COM interfaces with this problem too, e.g.
IPropertyStorage, but since such interfaces are implemented by Wine and
not by app code, there's unlikely to be source-compatibility issues there.

So the options include

1) keep using obj_base.h as it is, let widl use those macros as is (and
convert array args to pointer args), include it into unknwn.h

2) move ICOM macros to include/objbase.h, and dispose of obj_base.h

3) make widl use the MS-style macros in objbase.h (but I'm not sure what
to do about ICOM_MSVTABLE_COMPAT and ICOM_USE_COM_INTERFACE_ATTRIBUTE in
this case)

4) make widl not use macros at all, but emit full C and C++ definitions
directly (this is what midl.exe does, it seems)

5) make widl support any of the above with a command-line option, so that
Wine headers uses 1 or 2, while Winelib apps get to use 3 or 4.

6) redesign the ICOM macros (but I doubt anyone's going to volunteer for
that unless tied to a chair supervised by an ancient master of torture
with a cat-o'-nine-tails in his toolbox, there's too much code to change)