On 24-08-2010 01:23, Dan Kegel wrote:
Morten Rønne wrote:
I have been working on creating tests for the 16 bit implementation of wine
Great!
Have you seen http://code.google.com/p/win16test/ ? That's for Win16 binaries, not DOS, but it might have some similarities. For instance, it also uses openwatcom.
I had trouble back then getting the Linux version of openwatcom to produce win16 binaries, so I used 'winetricks openwatcom' to install the windows version.
- Dan
Yes, I have seen those tests. But they run as independent programs for each test. Wine (as it is now) creates one big program that is able to run all tests.
So I am not sure if it is acceptable to use that approach.
Also looking further into the wine_test program and thinking about how the test program should react when running (and esp. failing) I am considering creating a program for each test series that I envision at the moment: DOS 16 bit, DOS 32 bit and Win 16 bit (3.x) (the tests above for a start). This will of course mean that kernel32/tests would create more than one program for testing.
The problem with the current wrapper solution is that a failure in the underlying program and the count of test executed doesn't get reported to the wrapper, which means that it will report success regardless of the actual outcome. This can of course be fixed, but it would be a lot easier simply to drop the wrapper and let the program report failure and count directly.
But would that be an acceptable solution? Will TestBot be able to handle this case?
Creating a specific program directly with openwatcom will mean that no skip message will be produced if openwatcom isn't available and the programs therefore isn't created. But is that a problem, that should be handled?
One problem I can see down the line is the problem that DOS programs doesn't have a resource file system like windows does. If I have understood the wine test program correctly "all" it does is extract all executable, and then run the extracted executables one by one. Any file the test program needs are embedded as resources in each test executable themselves. That will give a problem for DOS programs, which will also need extra files, but not having a method of extracting them from the executable.
Would changing the wine test program to do the extract and cleanup be an acceptable solution, or should I find another way?
Best Regards Morten Rønne