Andriy Palamarchuk apa3a@yahoo.com writes:
:-( I need more than one thread to catch message on system parameter value change.
Not really, if you create a window your winproc will be called even if it's in the same thread. But we need to make threading work in any case.
I really like memory protection which is provided by "fork()". We are going to need it (e.g. for TODO tests) :-/ The framework can be used in forkless mode, however we still need to remove that piping stuff.
Can we have the same advantages by using two-stage launching process? The first part coordinates everything and starts each test with "exec". Such implementation is less efficient but much more portable.
IMO that's what we want, and the next step is to recognize that a simple shell script and a couple of makefile rules can do the "exec" job just as well, without having to worry about pipes or fork or whatever. I frankly don't see the need of a complex test harness to launch tests and print reports. Maybe when we have 1000 tests we will want some of that complexity, but for now it's only a waste of time.
a) this is license not for Wine, but for Wine testing application. From my point of view GPL is very appropriate in this case. Any other OS projects, using the test application will have to contribute the changes back. On other hand the license won't hurt any commercial application because nobody will make business on it.
Let's not debate licenses again. Anything that is included in the Wine distribution has to be under the Wine license. If you want a GPLed test suite you'll have to distribute it separately from Wine; but I think that would be a mistake.