some unimplemented COM stuff
marcus at jet.franken.de
Wed May 30 00:46:11 CDT 2001
On Wed, May 30, 2001 at 04:32:19AM +0200, Malte Starostik wrote:
> On Mittwoch, 30. Mai 2001 03:33, Ove Kaaven wrote:
> > On Wed, 30 May 2001, Malte Starostik wrote:
> > > On Mittwoch, 30. Mai 2001 00:39, Ove Kaaven wrote:
> > > > On Mon, 28 May 2001, Malte Starostik wrote:
> > > > > unfortunately g++ doesn't support specifying a calling convention for
> > > > > method pointers like HRESULT (IDispatch::*setProp)(BSTR).
> > > >
> > > > Since when? The construct HRESULT CALLBACK (*stuff)(...) is used all
> > > > over the Wine headers, so I'd think someone would have noticed if g++
> > > > didn't support it...
> > >
> > > HRESULT CALLBACK (*stuff)(...)
> > > works indeed. I only tried
> > > HRESULT CALLBACK (IFooBar::*stuff)(...)
> > > which yields:
> > > warning: `stdcall' attribute directive ignored
> > > and results in stack corruption then I ignore this warning.
> > Can you explain why you do this, then? I can't imagine why you would want
> > to declare a method pointer like this.
> Well, that was just the first thing that came to mind. Assembler was the
> second. I somehow didn't even think of a plain function pointer - well yes, I
> am more used to C++ than C :)
> Of course it's kinda hard to initialize a C++ method pointer from a vtable
> offset. Anyway, it should be implemented in winelib and not in my app, so
> it's not feasible after all.
> But that doesn't matter now that I realized a full implementation will
> probably need assembler as the number of arguments is virtually unlimited. So
> an array of parameters that is copied to the stack via inline assembler is
> IMHO the way to go. Will give it a try.
Why can't you use the WINE supplied macros INTERFACE_FUNCTION?
They should be defined to the correct C++ method calls.
More information about the wine-devel