On 2/24/11 4:50 AM, Alexandre Julliard wrote:
Damjan Jovanovic<damjan....@gmail.com>  writes:

What's the first Git version of Wine on which Win9x tests started
being removed? Is it 226c44097b26dcb547d533cb1690f60182d1728e or
b7c18d104b2d68a2a07574f01bb306df3fc138d2? It might still be useful to
cross-compile tests on the version before that one and sporadically
run them against future versions of Wine.
You are missing the point. The win9x support makes the tests less
strict, by allowing additional behaviors, and that only when running on
Windows. Running them on Wine is pointless since these code paths are
never executed.
In this context, I will state that you are correct. My patch was to remove a test based on the getversion() code and actually test if a called UNICODE function exists. It was not to add any additional test case results specific to Windows9x/ME (and from the testing I did, there was no difference on a live Windows98SE system vice a live WindowsXP system.) Adding broken() calls just to make a test pass on Windows9x should be discouraged. Creating specific tests for Windows9x/ME is better, but at this point in time not needed. We need to move forward with incorporating more of the API/ABI at the current running level. If someone wants to dedicate to completing an old and very undocumented functions, this should not be discouraged, but rather encouraged to work on the current project.

However, if Wine has specific functionality to support Windows9x/ME based programs the tests should ensure that we don't break it when trying to add (for instance) Windows7 functionality. As to adding functions to emulate Windows9x/ME functions, that should only be done to clear a bug report and not as a priority. Some programs will now not run with Windows7 due to changes in the API/ABI.

James McKenzie



Reply via email to