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

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

by Hans Leidekker

On Saturday 27 October 2007 22:29:00 Jakob Eriksson wrote: > I often find cygwin a relief when working with Windows. Yes, I also run cygwin on my Windows guests. I have openssh running on them and export the Wine tree to the guests via samba so I can do: $ make crosstest $ ssh vm /cygdrive/w/dlls/wininet/tests/wininet_crosstest.exe ftp from my Linux development host. This works for most tests and it gives me a fast edit-compile-test cycle because I don't have to leave the shell I'm working in. -Hans

Oct. 27, 2007

Re: ddraw:d3d tests failing consistently

by Jakob Eriksson

Francois Gouget wrote: > > It seems what you want is unit tests that would garantee that WineD3D > behaves in the way which _you_ have decided. Most of the time that's the > same as writing a _conformance_ test, but apparently in this specific > case it's different. If that's so, then maybe we have to see how we can > distinguish the two (separate test suites, enabling additional tests > when running in Wine, etc). > > This sort of infrastructure could also be useful in the case I > mentionned above, where a specific version of Windows returns something > stupid, but where we'd very much prefer to match the behavior of the > other non-buggy versions. > This is very interesting and what I always thought lacking in Wine testing. We need both a way of checking that Wine works like Windows and, our a test to our own standards. regards, Jakob

Oct. 27, 2007

MENU_TrackMenu trouble

by nicholai＠t-online.de

Hello, I'm struggling to make recent Chessbase applications such as Fritz 9 and 10 work with wine. A free download which shows the same symptoms described below is available here: http://fritzserver.org/download/CBLightEnglishSetup.exe I have tried to look into this and this is what I've found: The application uses TrackPopupMenuEx() (user32/menu.c) which in wine is just a call to TrackPopupMenu(). The latter function calls MENU_TrackMenu() and that's where things seem to go wrong. In the loop going through the message queue the application will crash (see output below) whenever the following message is sent: SendMessageW( mt.hOwnerWnd, WM_ENTERIDLE, MSGF_MENU, (LPARAM)win ); If I uncomment that line, the application will stay alive but I will obviously experience weird menu behaviour. I'm stuck trying to find out what the problem is and would really appreciate any help on how to proceed with this Thanks and best regards, Nicholai ------------------------------------------------------------------------------------------------------------------------------- wine: Unhandled page fault on read access to 0x00000020 at address 0x15a60c5 (thread 03da), starting debugger... Unhandled exception: page fault on read access to 0x00000020 in 32-bit code (0x015a60c5). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:015a60c5 ESP:0034ea64 EBP:0034eb10 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:0272e930 EDX:782ba9e0 ESI:015a60c0 EDI:0272e930 Stack dump: 0x0034ea64: 015a60c0 782021cb 00000002 00000000 0x0034ea74: 62a7f85f 00000121 0272e930 00138218 0x0034ea84: 00000000 00000000 015cfe20 782bafa4 0x0034ea94: 7fffffff 7bc3f3de 00000000 00000000 0x0034eaa4: 00000090 7bc326a1 00000000 00000010 0x0034eab4: 0034eb04 7bc40bff 00110014 7bc8443c Backtrace: =>1 0x015a60c5 in sviewnet (+0x760c5) (0x0034eb10) 2 0x78201ca1 in mfc80 (+0x31ca1) (0x0034eb30) 3 0x78200a43 in mfc80 (+0x30a43) (0x0034eb98) 4 0x78200c53 in mfc80 (+0x30c53) (0x0034ebbc) 5 0x781fedad in mfc80 (+0x2edad) (0x0034ec04) 6 0x7ed63b8a WINPROC_wrapper+0x1a() in user32 (0x0034ec34) 7 0x7ed6429e in user32 (+0xa429e) (0x0034ec74) 8 0x7ed685db in user32 (+0xa85db) (0x0034f144) 9 0x7ed69a0b WINPROC_call_window+0x15b() in user32 (0x0034f184) 10 0x7ed3036c in user32 (+0x7036c) (0x0034f1f4) 11 0x7ed340a2 in user32 (+0x740a2) (0x0034f254) 12 0x7ed3451a SendMessageW+0x4a() in user32 (0x0034f294) 13 0x7ed2d327 in user32 (+0x6d327) (0x0034f354) 14 0x7ed2e0af TrackPopupMenu+0x11f() in user32 (0x0034f394) 15 0x7ed2e14e TrackPopupMenuEx+0x5e() in user32 (0x0034f3c4) 16 0x015a757a in sviewnet (+0x7757a) (0x000005f0) 17 0x00000000 (0x00000000)

Oct. 27, 2007

Re: Lots of 'make test' failures on Windows

by Jakob Eriksson

Francois Gouget wrote: > > 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. > This is soooo good. test.winehq.org will became several times more useful than before. A consistent track record from the same installations of Windows. regards, Jakob

Oct. 27, 2007

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

by Jakob Eriksson

Hans Leidekker wrote: > 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. > I achieved much the same thing by putting a wget script in the Auto-startup folder of Windows. Then I copy in this vmware windows virtual machine and start it. Then Windows itself downloads winetest and upon completion, does a shutdown -h now. (Via cygwin.) I often find cygwin a relief when working with Windows. Just FYI. regards, Jakob

Oct. 27, 2007

Re: ddraw:d3d tests failing consistently

by H. Verbeet

On 27/10/2007, Francois Gouget <fgouget(a)free.fr> wrote: > [...] > > > 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. > > Was he talking about broken Windows setups or broken Linux setups? > It's find to ignore clearly broken Linux setups (e.g. known buggy driver > version), but calling every Windows system that does not give the result > we want 'broken' is refusing to face reality. > http://www.winehq.org/pipermail/wine-devel/2007-October/059719.html Broken setups in general I'd say. Let me put this another way... those setups would fail Microsofts own DCT as well.

Oct. 27, 2007

Re: ddraw:d3d tests failing consistently

by Stefan Dösinger

Am Samstag, 27. Oktober 2007 21:07:59 schrieb Francois Gouget: > If the game fails on Windows, users will either blame the game maker or > Intel. We don't care. However if it fails in Wine, the user will blame > Wine, not Intel, and not the game maker. Yes, that is the point. > Was he talking about broken Windows setups or broken Linux setups? > It's find to ignore clearly broken Linux setups (e.g. known buggy driver > version), but calling every Windows system that does not give the result > we want 'broken' is refusing to face reality. On the Linux side we're trying to abort running the tests as good as possible. I.e., if we detect a broken driver we disable features about which we know that they cause problems like X server crashes. > > 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. > > Its job is to needlessly pollute the results? > > Again, the test's job is not to detect broken systems, but to document > the Windows behavior. > > It seems what you want is unit tests that would garantee that WineD3D > behaves in the way which _you_ have decided. Most of the time that's the > same as writing a _conformance_ test, but apparently in this specific > case it's different. If that's so, then maybe we have to see how we can > distinguish the two (separate test suites, enabling additional tests > when running in Wine, etc). I want to document the behavior real world apps expect, and the freedom d3d implementations have is very, very limited. Games are usually pushed out without any QA work, most vendors do not even bother to run their games with the reference rasterizer or the debug runtime. Many game failures in Wine can be reproduced on Windows by changing some usually harmless settings. Use the refrast, or the debug runtime, and everything's broken. I just had such a case(bug 9774), other examples include Battlefield 1942 and Rollcage. Windows apps are crappy software, Direct3D games are even worse. > This sort of infrastructure could also be useful in the case I > mentionned above, where a specific version of Windows returns something > stupid, but where we'd very much prefer to match the behavior of the > other non-buggy versions. This would indeed be useful. It would allow to mark a test failure with something softer than a total failure, something like warn(). We could then warn if we detect a known Linux driver bug or a Windows driver behavior that is different from what games expect.

Oct. 27, 2007

Re: ddraw:d3d tests failing consistently

by Francois Gouget

On Sat, 27 Oct 2007, Stefan Dösinger wrote: [...] > 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. If the game fails on Windows, users will either blame the game maker or Intel. We don't care. However if it fails in Wine, the user will blame Wine, not Intel, and not the game maker. [...] > > 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. Was he talking about broken Windows setups or broken Linux setups? It's find to ignore clearly broken Linux setups (e.g. known buggy driver version), but calling every Windows system that does not give the result we want 'broken' is refusing to face reality. When FindExecutable() returns success on NT4 instead of returning an error like it should, we don't say that NT4 is broken and that thus it's ok to let the test fail and that it is its job to fail. We don't do that because the test's job is not to detect bugs in Windows, but to document what the different versions of Windows do, and to make sure that Wine does the same as one of them. So we adjust the test to accept both results as valid so it succeeds on both systems. I don't see why it should be different for the DirectX tests. > 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. Its job is to needlessly pollute the results? Again, the test's job is not to detect broken systems, but to document the Windows behavior. It seems what you want is unit tests that would garantee that WineD3D behaves in the way which _you_ have decided. Most of the time that's the same as writing a _conformance_ test, but apparently in this specific case it's different. If that's so, then maybe we have to see how we can distinguish the two (separate test suites, enabling additional tests when running in Wine, etc). This sort of infrastructure could also be useful in the case I mentionned above, where a specific version of Windows returns something stupid, but where we'd very much prefer to match the behavior of the other non-buggy versions. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

Oct. 27, 2007

Re: wine tests question?

by Vijay Kiran Kamuju

Well, I have researched a bit error code -1073741819=0xc0000005 This a status_no_access violation, in winetest we should say the test crashed message On 10/27/07, Robert Shearman <rob(a)codeweavers.com> wrote: > Vijay Kiran Kamuju wrote: > > 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? > > > > Probably because it has crashed. > > -- > Rob Shearman > >

Oct. 27, 2007

Re: wine tests question?

by Robert Shearman

Vijay Kiran Kamuju wrote: > 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? > Probably because it has crashed. -- Rob Shearman

Oct. 27, 2007