> Hello Patrick:
>
> You recently wrote on wine-devle about your "condensing-ware"
> winapi_test project.
Yes. I have being otherwise occupied again, so I haven't worked
much on it lately. It works but it it currently such a gross hack
that I haven't released it yet. It works to some extent though.
> Is there room in this thing for arbitrary regression tests
> too?
Yes, it is generalized. What should be tested is totally separate
from the generation of the actual test application, which in turn
is separate from the analysis of the test.
I currently only have an all pointer (NULL, NOACCESS, READWRITE,
READWRITE) test, but writting more tests is easy.
> We are working my way through the semi-annual Corel
> mega merge and would like some way of verifying that the bugs
> we (Corel and
> WineHQ) have fixed stay fixed.
OK. Then you need to test between different versions of Wine for
which support is planned but not yet implemented. The only things
that is currently implemented is testing between builtin and native.
It shouldn't be that hard to do, except for the problem is having more
than one version of Wine installed at the same time since I run the
both tests in parallell.
Hmm. I guess I could do some tricks with LD_LIBRARY_PATH. Of course
Corel Wine's (libwine.so) is not binary compatible with the current
version of Wine so that won't work either.
Hmm again. What we could do is compile the generate WineLib application
once for Corel Wine and once for the current Wine. This means that the
libwine.so and friends must reside in different directory or something.
Perhaps static linking is the answer.
Wait a minute. What does the Corel Linux distribution do?
IIRC is possible to have both Corel Wine and Wine installed
at the same time. Or is that just a gross hack that is Corel
Office specific?
I will see if I find time to make a prerelease of winapi_test
later today. At least something useful currently works,
eventhough it still is a gross hack (slow and bloated).
