RFC: test of 16 bit wine (DOS)

[Morten Rønne]

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