kernel32/tests: remove win9x hacks (try 2)
jjmckenzie51 at gmail.com
Thu Feb 24 22:47:56 CST 2011
On 2/24/11 4:50 AM, Alexandre Julliard wrote:
> Damjan Jovanovic<damjan.jov at 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.
More information about the wine-devel