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.