kernel32/tests: remove win9x hacks (try 2)

James McKenzie jjmckenzie51 at
Thu Feb 24 22:47:56 CST 2011

On 2/24/11 4:50 AM, Alexandre Julliard wrote:
> Damjan Jovanovic<damjan.jov at>  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

More information about the wine-devel mailing list