October 2007 - Wine-Devel - list.winehq.org

wine tests question?

by Vijay Kiran Kamuju

Hi, I have been looking into http://test.winehq.org/data/. And I have got a question, when i saw the test data. Why do some tests do not return the data about tests they haven't run/skipped. They spew messages something like below: mapi32:prop start dlls/mapi32/tests/prop.c 1.20 mapi32:prop done (-1073741819) mapi32:util start dlls/mapi32/tests/util.c 1.9 mapi32:util done (-1073741819) I am trying to figure out a reason so that i can fix this. can you guys help me out? thanks, VJ

Oct. 27, 2007

Re: ddraw:d3d tests failing consistently

by Stefan Dösinger

Am Samstag, 27. Oktober 2007 06:42:31 schrieb H. Verbeet: > On 26/10/2007, Francois Gouget <fgouget(a)free.fr> wrote: > > Parallels is a bit of a special case because it does not just replace > > the graphics driver, but the DirectX dlls altogether. However VMware 5.5 > > does not do that. > > That's precisely the problem. I would add, what about Neomagic chips > > then? By your reasonning there's only Windows on Nvidia and Windows on > > ATI, and maybe not even the latter. If you look at various game boxes in the software shop next to you, you will very often find notes like "Works on ATI radeon and Nvidia geforce cards. Mobile versions of the cards are unsupported". Means, that if you have a Destop radeon or gf card, you're lucky. If you have a mobile radeon or gf card, and the game doesn't work, your problem. If you have an Intel card, don't even try to start the game. One of those games was the Settlers 2 remake. It just crashed on a friend's laptop with an Intel chip. I put a Win32 build of WineD3D into the game's directory, and see, it runs(slow, but perfectly playable). What did WineD3D fix? Definitly not the client d3d9 lib, it is the same on all Windows boxes. It was the driver part that broke the game. So the Nvidia / ATI specific behavior *is* an issue for us. I just ran the d3d9 tests on my mother's laptop with an Intel card, and many tests failed. Many failures remind me of the behavior of WineD3D before it was fixed to fix some game(e.g. cubemap address modes, vertex shader fog). Other failures look quite severe too: Offscreen rendering fails, the z test fails in a really odd way(trying to make a screenshot). The mouse pointer leaves a visible mark on the screen. It seems that even vmware does better. > WineD3D is in a bit of a special position there, because it actually > does replace both the Direct3D dlls and the driver. While of course it > shouldn't test the behaviour of a specific version of drivers from a > specific vendor, it *should* at least for a part test the behaviour of > a driver that behaves according to the specs. All in all only the visual tests test the behavior of the driver, the others are focusing on the client library. > > Anyway... Can this be fixed by better checking the Direct3D > > capabilities? Does the test check for some undocumented feature or a > > documented one? Do we know that it works with the Nvidia, ATI and Intel > > drivers? If not, then maybe it should be removed? > > I don't think the caps will really be useful here, but we could > retrieve the card and driver name, and skip the test for some > combinations. IDirect3D9::GetAdapterIdentifier() for example should > return enough information for d3d9. I'm not sure we want to go there > though, Alexandre has said before that the tests should simply fail on > broken setups. Yes, that will work to filter out vmware, but I don't think we should do that. The test just does its job when it fails on broken drivers.

Oct. 27, 2007

Re: Make test drill, next steps, call for help with Winetest

by Hans Leidekker

On Saturday 27 October 2007 14:03:02 Francois Gouget wrote: > That's something I've wanted to do for some time and this finally > spured me to action. So here's a script that will do essentially the > same thing but with VMware Workstation. Cool! I think I'll borrow some of your nice extra options. I'm moving towards VirtualBox now, it's FOSS, as good as VMware for my purposes and less painful to keep running on a bleeding edge Linux distro. -Hans

Oct. 27, 2007

Re: Lots of 'make test' failures on Windows

by Francois Gouget

Robert Shearman wrote: > Jakob Eriksson wrote: [...] >> (That Codeweavers do not have such an installation yet, is beoynd me. Or >> if you do, please make it automatically submit its findings to >> test.winehq.org!) > > We do. I've got a machine that regularly runs the test on Windows 2003 > on real hardware: > http://test.winehq.org/data/200710241000/2003_rshearman/report And I have recently put together a script for running winetest in VMware virtual machines unattended (see my other post). So going forward I will be running it on Windows 98, Windows XP and Windows 2003 nightly. -- Francois Gouget fgouget(a)codeweavers.com

Oct. 27, 2007

Re: Make test drill, next steps, call for help with Winetest

by Francois Gouget

On Mon, 15 Oct 2007, Hans Leidekker wrote: [...] > I have written attached script to facilitate automated winetest runs. > It needs a VirtualBox virtual machine with either Windows or a Wine platform > configured to run autorun.inf files. > worry about winetest screwing up your installation. [...] That's something I've wanted to do for some time and this finally spured me to action. So here's a script that will do essentially the same thing but with VMware Workstation. Like your script it downloads winetest using wget, then generates an ISO with an autorun.inf file so the tests will start automatically in the VM. It also uses snapshots so the state of the virtual machine is preserved. Typically you would use it like this: * I have not found a way to 'insert' the CD if the cdrom device is not already connected in the VM. So you must first ensure that's the case. You can do so in a 'winetest' snapshot, the script will automatically switch to that snapshot. * Creating a winetest snapshot is probably a good idea anyway, if only to ensure it's a relatively clean environment. * Then run the script as follows: winetest /path/to/virtual/machine.vmx --tag mytests --no-submit The --no-submit option is so that the tests don't submit their results to http://test.winehq.org/. The goal here is to avoid sending lots of duplicate results while you're experimenting. Once you're confident things work just as expected, remove the option. There are other options to specify which version of winetest.exe to grab, to set the timeout on the tests execution, etc. Things still on the todo list: * the script also grabs the winetest.exe signature and attempts to verify it. But I don't know where to find the corresponding public key (651FD487) so I don't know if this really works. * the script gets the 'latest' winetest.exe version by default, but when there are compilation problems I guess this may stay stuck at the same revision for some time. So it would be nice if the script could know which version it's getting so it could skip the tests if that version is too old, or has already been tested. * I wonder if this works with VMware Server? It would be nice as Server is free. The script uses snapshots quite a bit though so it may not work. Let me know how it goes if you try. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

Oct. 27, 2007

Re: What if heap errors caused 'make test' to fail?

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > On 10/26/07, Alexandre Julliard <julliard(a)winehq.org> wrote: >> > http://bugs.winehq.org/show_bug.cgi?id=10179 >> >> That's not heap corruption, it's the expected behavior of GlobalHandle >> when called with a pointer to a moveable block. > > Good - then the bug is just that Wine is generating > a spurious scary warning. How can we either > suppress that warning, or make it more accurate? Well, that's why it's a WARN, it indicates that something may be wrong, but may also be a normal failure. If it were only displayed in cases where there's a real error it would be an ERR (and it actually is an ERR when called for internal pointers that we know should be valid). -- Alexandre Julliard julliard(a)winehq.org

Oct. 27, 2007

Re: ddraw:d3d tests failing consistently

by H. Verbeet

On 26/10/2007, Francois Gouget <fgouget(a)free.fr> wrote: > Parallels is a bit of a special case because it does not just replace > the graphics driver, but the DirectX dlls altogether. However VMware 5.5 > does not do that. > In practice the difference isn't that significant. While replacing the DirectX dlls completely allows you to break more tests, a rather large part of the functionality of Direct3D is actually implemented by the drivers. The drivers should behave according to the specifications of course, but the apparent need for the DCT and WHQL shows that this is hardly guaranteed. > That's precisely the problem. I would add, what about Neomagic chips > then? By your reasonning there's only Windows on Nvidia and Windows on > ATI, and maybe not even the latter. > Arguably that's actually the case for the situations where the results of those tests would make a difference. The point is that broken graphics drivers will break the test though, and there's not a whole lot we can reasonably do about it. > But Windows is not used on just one brand of graphics card, and our > tests should acknowledge that. The goal of our tests is to probe and > document the behavior of the Windows APIs, not the behavior of a > specific version of the Nvidia drivers. > WineD3D is in a bit of a special position there, because it actually does replace both the Direct3D dlls and the driver. While of course it shouldn't test the behaviour of a specific version of drivers from a specific vendor, it *should* at least for a part test the behaviour of a driver that behaves according to the specs. > Anyway... Can this be fixed by better checking the Direct3D > capabilities? Does the test check for some undocumented feature or a > documented one? Do we know that it works with the Nvidia, ATI and Intel > drivers? If not, then maybe it should be removed? > I don't think the caps will really be useful here, but we could retrieve the card and driver name, and skip the test for some combinations. IDirect3D9::GetAdapterIdentifier() for example should return enough information for d3d9. I'm not sure we want to go there though, Alexandre has said before that the tests should simply fail on broken setups.

Oct. 27, 2007

wine needs a relatively new version of fontforge?

by Lei Zhang

Hi, Dan K. and I both ran into bug 10103 [1] because the fontforge on our systems is too old. I noticed some of the font tests failed on my system for the same reason. So what is the minimum version of fontforge that will generate correct fonts? Should we add a check for it? - Lei [1] http://bugs.winehq.org/show_bug.cgi?id=10103

Oct. 27, 2007

Re: makefiles: add a notest target

by Lei Zhang

On 10/26/07, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Maarten Lankhorst wrote: > > Lei Zhang schreef: > >> This patch adds a notest target to build everything but the dll unit > >> tests and winetest. This cuts down build time by 25%. > >> > > Julliard will never accept such patch. In the hacks.git tree there is a > > patch I did that has a configuration time option for it. It would be > > cleaner if you used something like 'make SKIPTESTS=1'. I doubt that > > alexandre would ever accept any patch that would disable building tests, > > though. > And for a good reason. The tests started to rot and not even compile > when building wasn't part of the default make target. > > bye > michael > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > -------------------------------------------------------------------- > Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart > Handelsregister: Amtsgericht Stuttgart HRB 153243 > Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, > Werner Knoblich > This is not meant to be the default make target. I intended for it to be a time saver when one just needs a quick build, like when doing regression testing. Perhaps its better just to keep this out of the Wine tree, and let people apply the patch if they know what they're doing.

Oct. 26, 2007

Re: ddraw:d3d tests failing consistently

by Francois Gouget

On Fri, 26 Oct 2007, Stefan Dösinger wrote: > Am Freitag, 26. Oktober 2007 15:42:18 schrieb Jakob Eriksson: > > Agree 100%. Windows on vmware is still Windows. > No, I do not agree with that. Using that logic, Windows on Parallels would > still be Windows. However, Parallels uses WineD3D as their Direct3D driver. Parallels is a bit of a special case because it does not just replace the graphics driver, but the DirectX dlls altogether. However VMware 5.5 does not do that. > Is Windows on Parallels still Windows then, from a d3d point of view? > > How about Intel chips then? That's precisely the problem. I would add, what about Neomagic chips then? By your reasonning there's only Windows on Nvidia and Windows on ATI, and maybe not even the latter. But Windows is not used on just one brand of graphics card, and our tests should acknowledge that. The goal of our tests is to probe and document the behavior of the Windows APIs, not the behavior of a specific version of the Nvidia drivers. Anyway... Can this be fixed by better checking the Direct3D capabilities? Does the test check for some undocumented feature or a documented one? Do we know that it works with the Nvidia, ATI and Intel drivers? If not, then maybe it should be removed? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

Oct. 26, 2007