RE: vxdcall calling convention

[Patrik Stridvall]

> On Mon, Nov 18, 2002 at 04:21:37PM +0100, Patrik Stridvall wrote:
> > > Le lun 18/11/2002 à 02:51, Patrik Stridvall a écrit :
> > > > > Corrects this line in winapi_check:
> > > > > win32/device.c:544: kernel32: void
> > >
> > > VxDCall(DWORD,CONTEXT86 *): calling
> > > > > convention mismatch: cdecl != stdcall
> > > >
> > > > I'm not 100% sure this really is a bug.
> > > > Don't trust winapi_check too much it is very ad hoc. :-)
> > > >
> > > > It might however be a bug but I never got around to test it
> > >
> > > properly.
> > > > So, have you verified that this really is correct?
> > >
> > > Well, kernel32.spec references them by "stdcall -register -i386".
> > > Another API referenced the same way is CommonUnimpStub, and 
> > > in thunk.c,
> > > it is declared as "void WINAPI".
> > >
> > > Is it sufficient checking?
> >
> > I'm not sure, it might be the other API(s) that are wrong
> > or that VxDCall is a special case. That why I haven't dared
> > changed anything.
>
> I think it needs to be WINAPI, the __wine_call_from_32_regs 
> assembler thunk
> does not remove arguments from stack.

Yes, I'm leaning in that direction as well the more I think about it.

However, I don't think it is enough. It will work for the implemented
VxDCall
that pops the stack itself, however it will not work for unimplemented
VxDCalls
since they will not clean up the stack correctly AFAICS.

Anyway, if so it has been wrong a long time (so long that I don't notice the
warning from winapi_check any longer :-), so I wonder why it wasn't noticed
by anybody else running an application using VxD calls.

vxdcall calling convention

[Alexandre Julliard]

Patrik Stridvall  writes:
> However, I don't think it is enough. It will work for the
> implemented VxDCall that pops the stack itself, however it will not
> work for unimplemented VxDCalls since they will not clean up the
> stack correctly AFAICS.

The problem is you don't know how many args to pop. In theory the name
of the function tells you that, but in practice apps don't call the
right version, and VxDCall pops the number of args the specific call
requires no matter which version of the function is called. So this is
how we do it too.