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
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
On Thu, Sep 2, 2010 at 6:26 PM, Morten Rønne morten.roenne@tdcadsl.dk wrote:
Have you seen http://code.google.com/p/win16test/ ?
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.
IIRC win16test mirrors Wine's approach exactly. Is the "one big program" you're talking about programs/winetest? I think it bundles the little executables into an archive. There's no reason it can't bundle up the 16 bit apps and run them. - Dan
On Thu, Sep 2, 2010 at 6:47 PM, Dan Kegel dank@kegel.com wrote:
IIRC win16test mirrors Wine's approach exactly. Is the "one big program" you're talking about programs/winetest? I think it bundles the little executables into an archive. There's no reason it can't bundle up the 16 bit apps and run them.
Though you might have to turn off upx in programs/winetest/Makefile.in for 16 bit executables...
On 02-09-2010 20:47, Dan Kegel wrote:
On Thu, Sep 2, 2010 at 6:26 PM, Morten Rønnemorten.roenne@tdcadsl.dk wrote:
Have you seen http://code.google.com/p/win16test/ ?
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.
IIRC win16test mirrors Wine's approach exactly. Is the "one big program" you're talking about programs/winetest? I think it bundles the little executables into an archive. There's no reason it can't bundle up the 16 bit apps and run them.
- Dan
I only get one file for all tests in one directory, e.g. the kernel32 tests are in this file. -rwxr-xr-x 1 mr mr 1548553 2010-08-23 20:11 kernel32_test.exe.so
And when I ask programs/winetest to extract files only I end up with only one kernel32_test.exe file. And not every single test as it own program.
I am aware that programs/winetest can bundle and run the testprograms as single entities, but that is not the way it is done for the windows 32 bit tests.
So I would just like to be sure what would be accepted before I try to make a final patch series.
Best Regards Morten Rønne
On Thu, Sep 2, 2010 at 7:20 PM, Morten Rønne morten.roenne@tdcadsl.dk wrote:
Have you seen http://code.google.com/p/win16test/ ?
I only get one file for all tests in one directory, e.g. the kernel32 tests are in this file. -rwxr-xr-x 1 mr mr 1548553 2010-08-23 20:11 kernel32_test.exe.so
Oh, right, win16test's Makefile and probably its test.h are kind of simpleminded. You probably want to have just one 16 bit test app per dll. Hopefully the test cases from win16test will be a useful starting point aside from their wimpy build system.
-
Dan Kegel -
Morten Rønne