some unimplemented COM stuff
Malte.Starostik at t-online.de
Tue May 29 21:32:19 CDT 2001
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.
Wars don't determine who's right, only who's left.
More information about the wine-devel