RFC: Calling thiscall methods to start windowless richedit control tests

[Dylan Smith]

I have created a couple of patches to start the windowless richedit
control tests.  Since this has been tried by two other people already,
I thought I should get some comments before submitting them to
wine-patches.

Maarten Lankhorst initially tried to start these tests back in 2005:
http://www.winehq.org/pipermail/wine-devel/2005-July/038185.html

Austin Lund made some more progress on starting these tests.
http://www.winehq.org/pipermail/wine-devel/2008-July/067001.html

I kept the tests minimal because I want to other issues to be taken
care of before adding tests.  The main thing is that the tests compile
and run properly on Windows and Linux without crashing.

The main difficulty was wrapping c++ methods which use the thiscall
calling convention.  Austin Lund already got this to work, so I just
modified what he had to avoid using the ebx register.  The first patch
has the code to wrap the ITextHost methods so they can be called with
the thiscall calling convention, and the second patch has the wrapping
code to call ITextServices functions that use the thiscall calling
convention.

Even though the assembly is fairly short, the conditional macro
definitions for all the ITextServices methods does become verbose.
Let me know if someone knows a more elegant way of doing this.

The macros I created however conflict with the ones in
include/textserv.h, however these aren't in the native public headers.
 Should these be removed from Wine's public headers, or should they be
modified to handle the thiscall calling convention like I did in the
second patch?

In order to investigate what is happening in the tests, it is helpful
to trace the calls to ITextHost methods by the richedit controls.  I
realized it would be too verbose to trace all these calls by default,
so I wrapped them all with a check for winedebug > 1, since normally
winedebug is 0 or 1.   Does this seem like the best way to handle
this?  Because I can't use the normal TRACE channels from
wine/debug.h, since it can't be included in the tests.

I would also like someone to look at the conditional macro definitions
of __ASM_FUNC and __ASM_NAME.  I took these definitions from the
generated include/config.h file from my normal linux build, and from
my Windows cross compile build that uses mingw.  I looked at configure
and found there is another possible definition for __ASM_FUNC, so I
know I am missing one of the cases, but I can't test for it like the
configure script does.  Does anyone know how to do this properly?

Thanks again for everyone who has helped on this issue.  I have tried
to look at all the previous comments made, and use evolve some of the
code that was already written.