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)
Ove Kaaven ovehk@ping.uio.no writes:
- make widl not use macros at all, but emit full C and C++ definitions
directly (this is what midl.exe does, it seems)
I'd say this is the way to go if it's not too painful, it seems to be the most flexible. In any case obj_base.h has to go, so if we keep the macros they have to be put inside one of the standard headers, which wouldn't be very clean.
On 6 Dec 2002, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
- make widl not use macros at all, but emit full C and C++ definitions
directly (this is what midl.exe does, it seems)
I'd say this is the way to go if it's not too painful, it seems to be the most flexible. In any case obj_base.h has to go, so if we keep the macros they have to be put inside one of the standard headers, which wouldn't be very clean.
We may have to keep the macros anyway, there are headers that use them that can't be generated from IDL, like the DirectX headers. I suppose they could be converted to using the MS-style objbase.h macros by perl scripts or by rewriting them from api headers or something, but someone else would have to take on that task, I think.
But I'll try to add a widl header generation mode that don't use macros, then.
On Fri, 6 Dec 2002, Ove Kaaven wrote: [...]
We may have to keep the macros anyway, there are headers that use them that can't be generated from IDL, like the DirectX headers. I suppose they could be converted to using the MS-style objbase.h macros by perl scripts or by rewriting them from api headers or something, but someone else would have to take on that task, I think.
IIRC, one of the problems with the MS macros is that they force you to repeat all the inherited functions everytime. I.e. whenever you declare a new COM class you have to add the same QueryInterface, AddRef and Release lines over and over again. For DirectX this is even worse when Xxx8 inherits from Xxx7 which inehrits from Xxx6, etc <g>.
The ICOM macros should be source and binary compatible with what's generated by the MSVC macros so I would just keep on using them since they should make the headers more readable and maintainable.
Also I would not be surprised if the MS macros were less flexible than the ICOM macros and required that you have a compiler that can generate C++ classes with just the right binary layout.
Concerning the array issue, isn't 'int[] a' equivalent to 'int a[]'? Then one could have things like:
ICOM_METHOD2(HRESULT,Foo,REFIID[],, LPVOID[],)
Or is it just that MSVC does not like the ',,' in macro invocations?
On Mon, 9 Dec 2002, Francois Gouget wrote:
Also I would not be surprised if the MS macros were less flexible than the ICOM macros and required that you have a compiler that can generate C++ classes with just the right binary layout.
Yeah, as mentioned in my original mail, I didn't know where to hook in ICOM_USE_COM_INTERFACE_ATTRIBUTE and ICOM_MSVTABLE_COMPAT if we used them. The latter could probably be plugged into BEGIN_INTERFACE, but the former (which seems more useful) has no place. We'd have to add a Wine-specific macro for that at least...
Concerning the array issue, isn't 'int[] a' equivalent to 'int a[]'?
I've never seen that syntax with named parameters (I do know int[] to be valid with unnamed parameters in C++, but unnamed parameters aren't allowed in C). Does it work everywhere? Certainly doesn't on my gcc 2.95...
$ cat foo.c int func(int[] b) { return 0; }
int main() { int[5] a; return 0; }
$ cc -c foo.c foo.c:1: parse error before `b' foo.c: In function `main': foo.c:8: parse error before `[' $ c++ -c foo.c dill.c: In function `int main()': dill.c:8: parse error before `['
(hmm, seems to be valid as a function argument in C++, but not C?)
Or is it just that MSVC does not like the ',,' in macro invocations?
That's a separate issue that I don't know anything about.
Le lun 09/12/2002 à 19:15, Francois Gouget a écrit :
Or is it just that MSVC does not like the ',,' in macro invocations?
I'll do some more tests later today, but from my experience last week with using the WINE headers to compile the tests on MSVC, it doesn't. It caused an error, not only a warning, IIRC.
Vincent
-
Alexandre Julliard -
Francois Gouget -
Ove Kaaven -
Vincent Béron