So if anyone has been wondering why I don't run the tests on Win98 anymore... I still do! The problem is that since 2008/05/08 something prevents winetest from submitting the results.
The 200805062030 winetest build works fine so that leaves a two/three days window where things went wrong. Unfortunately I have been unable to pinpoint a specific test that causes the problem.
Here's a log I generated with the 200805211000 build: http://fgouget.free.fr/tmp/winetest.log
I let winetest run for 90 minutes (normally it's over in about 15), then Windows was frozen, not responding to Ctrl-Alt-Del, using all the CPU and I had to hit VMware's reset button.
The last test that was run is setupapi:parser, but according to the log it completed fine, and I can run it by hand just fine. Still according to the log the next test did not even start.
Unfortunately the list of potential suspects is quite long. It would help if I could at least cross-build winetest but I always get errors (e.g. due to d3dx9_36). What happened to the resolution to get rid of the dependency on MinGW libraries? Alternatively, where's the lastest version of w32api with d3dx9_36?
commit 382ed33b7a770d532bcf4b7dc392ee929c987c7a Author: Vitaliy Margolen wine-patches@kievinfo.com Date: Thu May 8 08:11:19 2008 -0600 dinput: Default value for unassigned POVs should be -1.
commit b92d1c7fbef30114b3aa7f3197a5df3556c98b12 Author: Paul Vriens paul.vriens.wine@gmail.com Date: Thu May 8 15:06:53 2008 +0200 crypt32/tests: Cleanup registry after tests.
commit 5714c4deee6f3c0cc30098d056fa4ce39a333878 Author: Alexandre Julliard julliard@winehq.org Date: Thu May 8 11:12:03 2008 +0200 user32: The client rectangle is in screen coordinates for the initial WM_NCCALCSIZE.
commit 09cb415109447c4be086f1c756f8a168628457f7 Author: Guy Albertelli galberte@neo.rr.com Date: Thu May 8 00:46:38 2008 -0400 listview: Return correct value from WM_NOTIFYFORMAT with test.
commit 864e24d2e586b796c2069576ca6d8fe4e7b8cef7 Author: Maarten Lankhorst m.b.lankhorst@gmail.com Date: Wed May 7 16:31:02 2008 -0700 kernel32: Fix temporary path test.
commit db8e63af27b75d098db6f9a61a6fb0ab7d70d83f Author: Maarten Lankhorst m.b.lankhorst@gmail.com Date: Wed May 7 15:44:48 2008 -0700 kernel32: Fix process tests to pass in Windows.
commit fd7b277d8ac23706b1c819d2ed1fd0ee9833fd06 Author: Maarten Lankhorst m.b.lankhorst@gmail.com Date: Tue May 6 15:06:17 2008 -0700 rpcrt4: Fix ndr_marshall test failures. Created with help from Robert Shearman.
commit 51c28a1493c844eff4f4625d3398da5ee5d707fd Author: Dmitry Timoshkov dmitry@codeweavers.com Date: Wed May 7 20:34:36 2008 +0900 gdi32: More carefully compare EMF records in tests.
commit 3da466a9f75076f618a5440805cd211a98c7b628 Author: Kai Blin kai.blin@gmail.com Date: Wed May 7 12:35:06 2008 +0200 secur32: Fix ntlm tests on Vista.
commit 02c66c2312d9bf98d0fc0d5d4ce56b8564718026 Author: Rob Shearman rob@codeweavers.com Date: Wed May 7 11:11:09 2008 +0100 rpcrt4: Add better traces for the server test. Handle failure to use one or more protocol sequences more gracefully, as ncacn_np servers aren't support on Win9x and ncacn_ip_tcp fails on some machines.
commit 473717fefd06650e1e8d80c8dc0e16ab583cc673 Author: Detlef Riekenberg wine.dev@web.de Date: Tue May 6 20:26:05 2008 +0200 winspool: Set PrinterPorts for win3.x/win9.x compatibility.
commit 7c051f13941b15bd0a399431e36cae16b8fe092e Author: Maarten Lankhorst m.b.lankhorst@gmail.com Date: Tue May 6 14:14:56 2008 -0700 winetest: Fix CreateProcess so that debugger tests run without timing out.
commit deee97d9eaa7dfe28a9e39f288c3c7ed39f6e7c8 Author: Paul Vriens paul.vriens.wine@gmail.com Date: Tue May 6 18:08:09 2008 +0200 advapi32/tests: Add another test.
commit 6477a1c1bfd7966ff75b6847156a765ec088b0b3 Author: Alexandre Julliard julliard@winehq.org Date: Tue May 6 15:54:07 2008 +0200 kernel32: Set the USERPROFILE and ALLUSERSPROFILE environment variables based on the ProfileList registry keys.
commit c4d75213abe21dcd7697d2f9151a186ebb3f8c8d Author: Alexander Dorofeyev alexd4@inbox.lv Date: Tue May 6 00:49:34 2008 +0300 ddraw/tests: Add tests for IDirect3DDevice7_Load.
I'm ignoring wininet and ntdll changes because they don't run due to missing imports.
On Thursday 22 May 2008 12:06:58 Francois Gouget wrote:
Alternatively, where's the lastest version of w32api with d3dx9_36?
The patches (against w32api v3.8) are available here: http://www.astro.gla.ac.uk/%7Epaulm/Cross/mingw-w32api-patches-2008-05-22.ta...
HTH,
Paul.
Francois Gouget fgouget@free.fr writes:
Unfortunately the list of potential suspects is quite long. It would help if I could at least cross-build winetest but I always get errors (e.g. due to d3dx9_36). What happened to the resolution to get rid of the dependency on MinGW libraries?
It's still the plan, but the obvious fix doesn't quite work because of MinGW's broken atexit() handling. I need to spend some more time on this.
Hello Francois,
2008/5/22 Francois Gouget fgouget@free.fr:
So if anyone has been wondering why I don't run the tests on Win98 anymore... I still do! The problem is that since 2008/05/08 something prevents winetest from submitting the results.
The 200805062030 winetest build works fine so that leaves a two/three days window where things went wrong. Unfortunately I have been unable to pinpoint a specific test that causes the problem.
Here's a log I generated with the 200805211000 build: http://fgouget.free.fr/tmp/winetest.log
I let winetest run for 90 minutes (normally it's over in about 15), then Windows was frozen, not responding to Ctrl-Alt-Del, using all the CPU and I had to hit VMware's reset button.
The last test that was run is setupapi:parser, but according to the log it completed fine, and I can run it by hand just fine. Still according to the log the next test did not even start.
Unfortunately the list of potential suspects is quite long. It would help if I could at least cross-build winetest but I always get errors (e.g. due to d3dx9_36). What happened to the resolution to get rid of the dependency on MinGW libraries? Alternatively, where's the lastest version of w32api with d3dx9_36?
You can build mingw using wine headers.
If you have a ${GIT_TREE} with the sources, and a compiled ${LINUX_TREE} :
pwd to an empty directory (${MINGW_TREE}) to build mingw in:
Then do this:
cat > no_except.h << __EOF__ /* exceptions noop */ #define __try #define __except(x) if (0) #define __finally #define _try #define _except if (0) #define _finally
__EOF__
"${GIT_TREE}/configure" --host=i586-mingw32msvc \ --with-wine-tools="${LINUX_TREE}" --without-freetype --without-x
XCPPFLAGS="-include ${MINGW_TREE}/no_except.h -I$WINE_SRC/include "\ "-DUSE_COMPILER_EXCEPTIONS -DUSE_WIN32_OPENGL"
XLDFLAGS="-L ${MINGW_TREE}/libs -L ${MINGW_TREE}/libs/wine"
function imake { make LDFLAGS="${XLDFLAGS}" CPPFLAGS="${XCPPFLAGS}" $@ }
imake -C libs imake -C include imake -C dlls implib cp -v dlls/*/*.a libs rm -f libs/libmsvcrt.a # Use mingw msvcrt library
cd dlls for testdir in */tests; do imake -C "${testdir}" done cd ..
imake -C programs/winetest
This was based on john klehm's script, but I had made some modifcations to run it in an automated fashion with the rest of my build scripts.
Cheers, Maarten.
Francois Gouget wrote:
So if anyone has been wondering why I don't run the tests on Win98 anymore... I still do! The problem is that since 2008/05/08 something prevents winetest from submitting the results.
The 200805062030 winetest build works fine so that leaves a two/three days window where things went wrong. Unfortunately I have been unable to pinpoint a specific test that causes the problem.
Could you try running the user32/sysparams test manually? That's where the "screen" of my win98 turns black and the "box" doesn't seem to respond anymore.
Paul Vriens wrote:
Francois Gouget wrote:
So if anyone has been wondering why I don't run the tests on Win98 anymore... I still do! The problem is that since 2008/05/08 something prevents winetest from submitting the results.
The 200805062030 winetest build works fine so that leaves a two/three days window where things went wrong. Unfortunately I have been unable to pinpoint a specific test that causes the problem.
Could you try running the user32/sysparams test manually? That's where the "screen" of my win98 turns black and the "box" doesn't seem to respond anymore.
Could this be the issue:
sysparams.c:2225: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2238: Test failed: Set bpp 8, but WM_DISPLAYCHANGE reported bpp -1 sysparams.c:2230: Tests skipped: Setting depth 16 failed(ret = -2) sysparams.c:2230: Tests skipped: Setting depth 24 failed(ret = -2) sysparams: 790 tests executed (0 marked as todo, 28 failures), 2 skipped.
(Output from "user32_test.exe sysparams > log.txt" checked after a restart)
Paul Vriens wrote:
Paul Vriens wrote:
Francois Gouget wrote:
So if anyone has been wondering why I don't run the tests on Win98 anymore... I still do! The problem is that since 2008/05/08 something prevents winetest from submitting the results.
The 200805062030 winetest build works fine so that leaves a two/three days window where things went wrong. Unfortunately I have been unable to pinpoint a specific test that causes the problem.
Could you try running the user32/sysparams test manually? That's where the "screen" of my win98 turns black and the "box" doesn't seem to respond anymore.
Could this be the issue:
sysparams.c:2225: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2238: Test failed: Set bpp 8, but WM_DISPLAYCHANGE reported bpp -1 sysparams.c:2230: Tests skipped: Setting depth 16 failed(ret = -2) sysparams.c:2230: Tests skipped: Setting depth 24 failed(ret = -2) sysparams: 790 tests executed (0 marked as todo, 28 failures), 2 skipped.
(Output from "user32_test.exe sysparams > log.txt" checked after a restart)
Sorry for the spam.
I just saw my win98 box (VMware) was set to 8bit (256 color) for some reason.
Running the sysparams tests on a win98 where the display is set to 8bit renders the box useless. Changing the display to 32bit makes the tests work again.
So apart from the test that has to be fixed to cope with this, what made by display go to 8bit?
2008/5/27 Paul Vriens paul.vriens.wine@gmail.com:
Paul Vriens wrote:
Paul Vriens wrote:
Francois Gouget wrote:
So if anyone has been wondering why I don't run the tests on Win98 anymore... I still do! The problem is that since 2008/05/08 something prevents winetest from submitting the results.
The 200805062030 winetest build works fine so that leaves a two/three days window where things went wrong. Unfortunately I have been unable to pinpoint a specific test that causes the problem.
Could you try running the user32/sysparams test manually? That's where the "screen" of my win98 turns black and the "box" doesn't seem to respond anymore.
Could this be the issue:
sysparams.c:2225: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2238: Test failed: Set bpp 8, but WM_DISPLAYCHANGE reported bpp -1 sysparams.c:2230: Tests skipped: Setting depth 16 failed(ret = -2) sysparams.c:2230: Tests skipped: Setting depth 24 failed(ret = -2) sysparams: 790 tests executed (0 marked as todo, 28 failures), 2 skipped.
(Output from "user32_test.exe sysparams > log.txt" checked after a restart)
Sorry for the spam.
I just saw my win98 box (VMware) was set to 8bit (256 color) for some reason.
Running the sysparams tests on a win98 where the display is set to 8bit renders the box useless. Changing the display to 32bit makes the tests work again.
So apart from the test that has to be fixed to cope with this, what made by display go to 8bit?
I have noticed that if the DirectDraw/3D tests (especially the visual tests) crash, they will not restore the screen resolution back, so I sometimes end up with a 600x480 or 800x600 screen (this is especially true when enabling compiz effects on Ubuntu 8.04).
Are your DirectDraw/3D tests crashing and since you are running in a VM you are not seeing the resolution change (or have it defaulted to the one used by the tests, with the exception of the colour depth)?
- Reece
-
Alexandre Julliard -
Francois Gouget -
Maarten Lankhorst -
Paul Millar -
Paul Vriens -
Reece Dunn