On Wed, Feb 23, 2011 at 11:38 AM, Austin English austinenglish@gmail.com wrote:
-- -Austin
So test.winehq.org doesn't test Win9x any more, but why are we throwing away perfectly good Win9x tests that took years to get in?
On Wed, Feb 23, 2011 at 03:17, Damjan Jovanovic damjan.jov@gmail.com wrote:
On Wed, Feb 23, 2011 at 11:38 AM, Austin English austinenglish@gmail.com wrote:
-- -Austin
So test.winehq.org doesn't test Win9x any more, but why are we throwing away perfectly good Win9x tests that took years to get in?
Because the code is essentially dead.
On 2/23/11 12:13 PM, Austin English wrote:
On Wed, Feb 23, 2011 at 03:17, Damjan Jovanovicdamjan.jov@gmail.com wrote:
On Wed, Feb 23, 2011 at 11:38 AM, Austin English austinenglish@gmail.com wrote:
-- -Austin
So test.winehq.org doesn't test Win9x any more, but why are we throwing away perfectly good Win9x tests that took years to get in?
Because the code is essentially dead.
Ok. I agree with that thought, but riched20.dll has different functionality based upon different versions of Windows. Thus riched20 functions will vary based upon the version of Windows we are trying to emulate.
As I stated, I run dOOm II, which basically is a Windows95 First Person Shooter. There are other old games like this that I feel that Wine should support because this functionality is going away with Microsoft Windows. Windows 3.1/3.11 is already gone, for the most part. Thus, like Damjan said, the tests are there and have been proven. I agree that no new Windows9x tests should be added, except where needed, to the existing codebase.
James McKenzie
On Wed, Feb 23, 2011 at 9:13 PM, Austin English austinenglish@gmail.com wrote:
On Wed, Feb 23, 2011 at 03:17, Damjan Jovanovic damjan.jov@gmail.com wrote:
On Wed, Feb 23, 2011 at 11:38 AM, Austin English austinenglish@gmail.com wrote:
-- -Austin
So test.winehq.org doesn't test Win9x any more, but why are we throwing away perfectly good Win9x tests that took years to get in?
Because the code is essentially dead.
-- -Austin
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.
And does this mean that Windows 3.1 (and DOS?) tests aren't welcome now?
Damjan
Damjan Jovanovic damjan.jov@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.
And does this mean that Windows 3.1 (and DOS?) tests aren't welcome now?
As part of the winetest infrastructure, they are not welcome, and never have been. Nobody runs winetest on Win 3.1, and it would be a major effort to make it work there. It's not worth the trouble.
* On Thu, 24 Feb 2011, Alexandre Julliard wrote:
The win9x support makes the tests less strict, by allowing additional behaviors, and that only when running on Windows.
Is that a problem?
Running them on Wine is pointless since these code paths are never executed.
I may be missing the point, but Wine uses broken() function already. Similar function, eg. dead_9x(), could be easily created to check for such cases.
And does this mean that Windows 3.1 (and DOS?) tests aren't welcome now?
As part of the winetest infrastructure, they are not welcome, and never have been.
I have at least one Win16 app which behaves differently on Win16, on XP and on Wine [*]. What's the right way to get it running OK on Wine then (without appropriate Win16API tests) ?
S.
Saulius Krasuckas saulius2@ar.fi.lt writes:
I have at least one Win16 app which behaves differently on Win16, on XP and on Wine [*]. What's the right way to get it running OK on Wine then (without appropriate Win16API tests) ?
Fix the bug without a test, or work on adding a 16-bit test suite. This has nothing whatsoever to do with running 32-bit tests on Win95.
* On Thu, 24 Feb 2011, Alexandre Julliard wrote:
Saulius Krasuckas saulius2@ar.fi.lt writes:
I have at least one Win16 app which behaves differently on Win16, on XP and on Wine [*]. What's the right way to get it running OK on Wine then (without appropriate Win16API tests) ?
Fix the bug without a test, or work on adding a 16-bit test suite.
Thanks. Do you mean something like integrating OpenWatcom C compiler optionally into dlls/*/tests?
And then running 16-bit part of winetest on Win3.1? WinXP seems to be broken in my case. While Win98 seems OK.
This has nothing whatsoever to do with running 32-bit tests on Win95.
Yes, that's two separate topics in one msg.
What is best in your opinion to do for those still interested in win9x's 32-bit behaviour? The only alternative coming to my mind is forking winetest.
S.
Saulius Krasuckas saulius2@ar.fi.lt writes:
Thanks. Do you mean something like integrating OpenWatcom C compiler optionally into dlls/*/tests?
And then running 16-bit part of winetest on Win3.1? WinXP seems to be broken in my case. While Win98 seems OK.
No, winetest would run on XP. If your app doesn't work on XP then it's unlikely to work on Wine. We are *not* going to replicate the Win95 16-bit architecture.
What is best in your opinion to do for those still interested in win9x's 32-bit behaviour? The only alternative coming to my mind is forking winetest.
Sure, go ahead and create a git tree from the stable branch, and maintain the Win9x tests in there, if that's your idea of fun.
On 2/25/11 10:33 AM, Alexandre Julliard wrote:
Saulius Krasuckassaulius2@ar.fi.lt writes:
Thanks. Do you mean something like integrating OpenWatcom C compiler optionally into dlls/*/tests?
And then running 16-bit part of winetest on Win3.1? WinXP seems to be broken in my case. While Win98 seems OK.
No, winetest would run on XP. If your app doesn't work on XP then it's unlikely to work on Wine. We are *not* going to replicate the Win95 16-bit architecture.
I've been looking at the use of is_win9x and all the tests do for riched20 (except one) is check for the presence of UNICODE calls, namely lstrcmpW. I would like to rename the variable and redo the test. Is this acceptable or should the test itself be dropped?
James McKenzie
On 2/24/11 4:50 AM, Alexandre Julliard wrote:
Damjan Jovanovicdamjan.jov@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
-
Alexandre Julliard -
Austin English -
Damjan Jovanovic -
James McKenzie -
James McKenzie -
Saulius Krasuckas