Re: riched20: Remove the unneeded DEFINE_STDCALL_WRAPPER.
On Thu, Apr 7, 2011 at 5:30 AM, Michael Stefaniuc <mstefani(a)redhat.de>wrote:
The COM methods are already __stdcall. --- dlls/riched20/txthost.c | 128 ++++++++++++++-------------------------------- 1 files changed, 39 insertions(+), 89 deletions(-)
COM methods are supposed to use the stdcall calling convention, but the native riched20 and the native headers just defines ITextHost and ITextServices to be a c++ class (i.e. using the thiscall calling convention). Just look at the native TextServ.h header.
Dylan Smith wrote:
On Thu, Apr 7, 2011 at 5:30 AM, Michael Stefaniuc <mstefani(a)redhat.de>wrote:
The COM methods are already __stdcall. --- dlls/riched20/txthost.c | 128 ++++++++++++++-------------------------------- 1 files changed, 39 insertions(+), 89 deletions(-)
COM methods are supposed to use the stdcall calling convention, but the native riched20 and the native headers just defines ITextHost and ITextServices to be a c++ class (i.e. using the thiscall calling convention). Just look at the native TextServ.h header. Right, but for that you have the textHostVtbl with the THISCALL() wrapper.
The itextHostStdcallVtbl is just for the C COM macros used from Wine code as calling a thiscall function from Wine is a PITA. That is handled in editor.h: #ifdef __i386__ /* Use wrappers to perform thiscall on i386 */ #define TXTHOST_VTABLE(This) (&itextHostStdcallVtbl) #else /* __i386__ */ #define TXTHOST_VTABLE(This) (This)->lpVtbl #endif /* __i386__ */ /*** ITextHost methods ***/ #define ITextHost_TxGetDC(This) TXTHOST_VTABLE(This)->TxGetDC(This) #define ITextHost_TxReleaseDC(This,a) TXTHOST_VTABLE(This)->TxReleaseDC(This,a) ... On i386 Wine is calling functions from the static itextHostStdcallVtbl and those functions are not thiscall. Of course I might miss something as that code is mind warping... bye michael
On Thu, Apr 7, 2011 at 12:17 PM, Michael Stefaniuc <mstefani(a)redhat.com> wrote:
Dylan Smith wrote:
On Thu, Apr 7, 2011 at 5:30 AM, Michael Stefaniuc <mstefani(a)redhat.de>wrote:
The COM methods are already __stdcall. --- dlls/riched20/txthost.c | 128 ++++++++++++++-------------------------------- 1 files changed, 39 insertions(+), 89 deletions(-)
COM methods are supposed to use the stdcall calling convention, but the native riched20 and the native headers just defines ITextHost and ITextServices to be a c++ class (i.e. using the thiscall calling convention). Just look at the native TextServ.h header. Right, but for that you have the textHostVtbl with the THISCALL() wrapper.
The itextHostStdcallVtbl is just for the C COM macros used from Wine code as calling a thiscall function from Wine is a PITA. That is handled in editor.h: #ifdef __i386__ /* Use wrappers to perform thiscall on i386 */ #define TXTHOST_VTABLE(This) (&itextHostStdcallVtbl) #else /* __i386__ */ #define TXTHOST_VTABLE(This) (This)->lpVtbl #endif /* __i386__ */ /*** ITextHost methods ***/ #define ITextHost_TxGetDC(This) TXTHOST_VTABLE(This)->TxGetDC(This) #define ITextHost_TxReleaseDC(This,a) TXTHOST_VTABLE(This)->TxReleaseDC(This,a) ...
On i386 Wine is calling functions from the static itextHostStdcallVtbl and those functions are not thiscall. Of course I might miss something as that code is mind warping...
I'll try to explain. The ITextHost interface may be user provided for windowless richedit controls, but for windowed richedit controls the internal ITextHostImpl implementation is used. They both must be defined using the thiscall calling convention, so in wine ITextHostImpl has a set of thunks to fill the textHostVtbl that perform thiscall->stdcall conversion before jumping to the stdcall defined methods. The rest of the richedit code needs to call the ITextHost interface using the thiscall calling convention, so on i386 it calls a thunk in itextHostStdcallVtbl which are defined using the stdcall calling convention, and perform stdcall->thiscall conversion before jumping to the thiscall defined method (i.e. the actual method for user provided ITextHost, and a thunk to reverse the calling convention in Wine).
On Thu, Apr 7, 2011 at 1:00 PM, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote:
The rest of the richedit code needs to call the ITextHost interface using the thiscall calling convention, so on i386 it calls a thunk in itextHostStdcallVtbl which are defined using the stdcall calling convention, and perform stdcall->thiscall conversion before jumping to the thiscall defined method (i.e. the actual method for user provided ITextHost, and a thunk to reverse the calling convention in Wine).
Sorry, that last part should read (i.e. the actual method for user provided ITextHost, OR a thunk to reverse the calling convention for calling the internal ITextHostImpl).
On 04/07/2011 07:04 PM, Dylan Smith wrote:
On Thu, Apr 7, 2011 at 1:00 PM, Dylan Smith<dylan.ah.smith(a)gmail.com> wrote:
The rest of the richedit code needs to call the ITextHost interface using the thiscall calling convention, so on i386 it calls a thunk in itextHostStdcallVtbl which are defined using the stdcall calling convention, and perform stdcall->thiscall conversion before jumping to the thiscall defined method (i.e. the actual method for user provided ITextHost, and a thunk to reverse the calling convention in Wine).
Sorry, that last part should read (i.e. the actual method for user provided ITextHost, OR a thunk to reverse the calling convention for calling the internal ITextHostImpl). Thanks for the explanation. It kinda makes sense but it still feels ugly.
bye michael
On 4/7/11 3:28 PM, Michael Stefaniuc wrote:
On 04/07/2011 07:04 PM, Dylan Smith wrote:
On Thu, Apr 7, 2011 at 1:00 PM, Dylan Smith<dylan.ah.smith(a)gmail.com> wrote:
The rest of the richedit code needs to call the ITextHost interface using the thiscall calling convention, so on i386 it calls a thunk in itextHostStdcallVtbl which are defined using the stdcall calling convention, and perform stdcall->thiscall conversion before jumping to the thiscall defined method (i.e. the actual method for user provided ITextHost, and a thunk to reverse the calling convention in Wine).
Sorry, that last part should read (i.e. the actual method for user provided ITextHost, OR a thunk to reverse the calling convention for calling the internal ITextHostImpl). Thanks for the explanation. It kinda makes sense but it still feels ugly. I don't know if this will help but...
Both Clang and (recent) GCC have direct support for __attribute__((thiscall)) (and I would know about Clang, I added it to the LLVM side). We could potentially take advantage of this and not have to declare thunks like this. Chip
On 8 April 2011 08:09, Charles Davis <cdavis(a)mymail.mines.edu> wrote:
I don't know if this will help but...
Both Clang and (recent) GCC have direct support for __attribute__((thiscall)) (and I would know about Clang, I added it to the LLVM side). We could potentially take advantage of this and not have to declare thunks like this.
That's definitely not portable. It could be used with ifdefs, but then one would have to ask if it is worth the effort. Is there any speed or security or other reason for preferring this method on compilers that support it?
participants (4)
-
Austin Lund -
Charles Davis -
Dylan Smith -
Michael Stefaniuc