April 2002 - Wine-Devel - list.winehq.org

RE: minor regression testing patch

by Geoffrey Hausheer

> -----Original Message----- > From: Alexandre Julliard julliard(a)winehq.com {WineHQ-devel} > Version checks are a bad idea because this is not how Wine is > implemented. For instance GetLongPathName under Wine doesn't try to > fail if you are running with -winver win95, it just works. Adding > version checks in the tests just means that some functions won't get > tested if you run with the wrong version. > > The right way is to always call the function no matter the version, > and check that the call either succeeds as expected, or fails in the > way that it's supposed to fail on a platform that doesn't support it. The problem I forsee with this is that it makes writing tests a bit tricky for functions that behave differently on different platforms (i.e. defining the failure conditions correctly). Otherwise, it is a good thing to strive for. I'll try to modify the tests I've written to behave in this manner, and see how much work it is. Unfortunately, it is somewhat difficult, since I don't (in general) have access to the platforms which don't support the functions. So I can write tests that pass on Win2k, Win98, and wine, but as soon as someone runs it on win95 or nt4.0, it will likely fail (since I have no idea what the failure mechanism will be on these platforms, and thus can't gaurd against it) until someone can provide enough feedback to allow the test to be fixed. My assumption has always been: Make the function work correctly on Windows, and then add todo's to support wine. Thus I've put the effort in upfront to catch errors when the application runs on an MS OS. It sounds to me that you are proposing a more wine-centric testing base (make the tests work in Wine, and fix problems encountered in Windows as they pop up...or be a lot more knowledgeable than me at how Windows is supposed to behave). So far I have written all my tests based purely on the MSDN spec, and then tweaked them when an OS behaves differently than documented. If I don't use OS-specific checks, I just feel like I'm leaving a known whole in my test if I don't account for the the cases which are documented not to work (and which I don't know how they will behave). For instance the thread.c test that I wrote makes (some) checks for access control, which only work on win2k+. The way I wrote the test, it just worked in win98 when I finally got around to testing it. Had I just executed the checks, I would have had no idea how Win98 would behave (hopefully with a nice SetError, but god only knows), and the test would certainly have failed on win98 until I was able to try it and figure out how it dealt with this unsupported functionality. Lastly, what is the recomendation for dealing with cases like this: lstrcpyA(tmpstr,"aaaaaaaa"); len1=GetTempPathA(len,tmpstr); /*this should fail because len is too small */ ok(len1==len+1, "GetTempPathA should return string length %d instead of %d",len+1,len1); if(WIN2K_PLUS(version)) { /* in Win2k, the path won't be modified, but in win98, wine it is */ todo_wine { ok(lstrcmpiA(tmpstr,"aaaaaaaa")==0, "GetTempPathA should not have modified the buffer"); } } One answer is not to test this, since it is not documented what the result will be, but the OSes certainly behave differently, and it is possible that some program takes advantage of this. I'm sure there are other similar cases, and I'd like to know (in general) what the right solution will be. I'm probably making a mountain out of a molehill, and I'll just try modifying my tests to work the way Alexandre proposes. I'm just afraid this is setting additonal obstacles for (non Wine) developers to write regression tests. Thanks, .Geoff

April 24, 2002

Wine[X] and Grand Prix 3 (Microprose)

by Rene Rebe

Hi all. I just turned my last 10 hours into configuring Wine to run Formula One Grand Prix 3 from Microprose. After several tries using the latest Wine and WineX (making many mistakes with the registry files ...) I got it to run using the last-night WineX cvs soruce ;-) I only have trhee graphic problems: a) the menus (where you configure several game options/details) do not appear in the right colors. Like a 8bit image displayed with the wrong color-pallete. b) in the race with very perfect weather (0% rain risk) - where the sky should be completely blue - the sky doesn't get painted at all -> resulting in "tearing" textures, because this area doesn't get refresh. (when some clouds show up the graphic is perfect) and c) Direct3D is not recognized at all -> resulting that the game runs in software-rendered mode. For a) I guess it migth be a wrong 16bit mode (or even an 8 bit mode) - my XFree-4.2.0 is running in 16bit mode normally. 24bit XFree results in the same mess and 8bit X results in a slighty worser images. About b) I guess some bitblt or clear function is nor working properly. I also tested the PerferctGraphics and DoubleBuffer option of Wine yielding the same results ... For c) OpenGL on my Matrox G450 is configured and runs fine - I have no clue whatever Wine[X] needs to provide Direct3D ... ? I can provide whatever trace output is needed - and would also offer to write some code if someone points me to the place in the souce where something is missing (I know C and C++ ...). I could also provide trace output to get (generic) Wine run the game. (It seems to be a problem that more DirectDraw is missing?). The rest of the game runs just fine, including Sound and Joystick support. Configuration: - Linux 2.4.19-pre7 - glibc-2.2.6 - gcc-2.95.3 - XFree-4.2.0 - AMD Athlon 1700XP; Matrox MGA 450 (OpenSouce driver) [- ROCK Linux (http://www.rocklinux.org) k33p h4ck1n6 René -- René Rebe (Registered Linux user: #248718 <http://counter.li.org>) eMail: rene.rebe(a)gmx.net rene(a)rocklinux.org Homepage: http://drocklinux.dyndns.org/rene/ Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms.

April 24, 2002

Re: Unit testing

by Michael Cardenas

If that's the bug, maybe we can come up with a better error message. On Wednesday 24 April 2002 04:30 pm, Francois Gouget wrote: > On Wed, 24 Apr 2002, Jakob Eriksson wrote: > [...] > > > START_TEST(alloc) > > ^^^^^ > > The above means that your file is called 'alloc.c'. Reciprocally, > the above should match the name of the C file in which the test is > otherwise you will get the 'func_alloc' error that you had. -- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi

April 24, 2002

cups support apparently broken

by Michael Cardenas

Hello all. Apparently wine's cups support is broken. With our old version of wine, wine would correctly detect the current cups printer, but it couldn't actually print to it. So, you would see the print dialog, but when you hit the print button nothing happened. Now, I have cups installed and a build of yesterday's cvs and when I try to print wine tells me that there are no printers installed and I should "point to settings on the windows start menu, click printers" and add a printer. Anyone have any ideas on how this broke? thank you michael -- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi

April 24, 2002

word can't open documents...

by Michael Cardenas

With yesterday's cvs, opening a document causes it to crash with this output on the console: fixme:listview:LISTVIEW_UnsupportedStyles LVS_SHAREIMAGELISTS fixme:listview:LISTVIEW_SetItemCount flags LVSICF_NOINVALIDATEALL LVSICF_NOSCROLL not implemented fixme:file:FindFirstChangeNotificationA this is not supported yet (non-trivial). fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj sdlkj s.doc", 0x00000001, 0x40552218, 0x4055263c): stub fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents", 0x00000001, 0x40553d68, 0x4055418c): stub fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj sdlkj s.doc", 0x00000001, 0x4055435c, 0x40554780): stub fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj sdlkj s.doc", 0x00000001, 0x405532b0, 0x405536d4): stub X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 1 (X_CreateWindow) Value in failed request: 0x0 Serial number of failed request: 30392 Current serial number in output stream: 30395 -- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi

April 24, 2002

Re: Unit testing

by Francois Gouget

On Wed, 24 Apr 2002, Jakob Eriksson wrote: [...] > START_TEST(alloc) ^^^^^ The above means that your file is called 'alloc.c'. Reciprocally, the above should match the name of the C file in which the test is otherwise you will get the 'func_alloc' error that you had. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

April 24, 2002

Re: C/L utility to translate unix and dos paths

by Michael Wetherell

On Wednesday 24 Apr 2002 7:51 pm, you wrote: > --- Michael Wetherell <mike.wetherell(a)ntlworld.com> > > wrote: > > Yes I know cygpath, winepath is intended to be a > > kind of Wine version of the > > same thing. > > > > The programs aren't interchangeable though, cygpath > > knows about Cygwin's > > mount points while winepath knows about Wine's DOS > > drives. > > Agree. Thought you may not know about cygpath and this > information will be interesting for you. > > Andiry > Yes thanks, it was interesting, many options. Mike

April 24, 2002

Re: Unit testing

by Jakob Eriksson

#include "winbase.h" #include "winerror.h" #include "wine/test.h" static void test__hread(void) { LPCSTR lpPathName = "testfile.txt"; HFILE filehandle; filehandle = _lcreat(lpPathName, 0); ok(filehandle != HFILE_ERROR, "_lcreat failed."); /* _hwrite();*/ ok(DeleteFileA(lpPathName) != 0, "DeleteFile failed."); } START_TEST(alloc) { test__hread(); } this is my, of course very incomplete test for _hread(). But it doesn't even compile and I don't understand why. I get this error: ----------------- ../../programs/winetest/runtest -q -P wine -M kernel32.dll -T ../.. tests/atom.pl && touch tests/atom.ok Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REEN TRANT -I/usr/X11R6/include -o tests/file.o tests/file.c ld -r ../../programs/winetest/wtmain.o tests/testlist.o tests/alloc.o tests/directory.o tests/path.o tests/process. o tests/thread.o tests/file.o -o tests/kernel32_test.tmp.o tests/file.o: In function `func_alloc': /home/jakov/src/WINE/wine/dlls/kernel/tests/file.c(.text+0x7c): multiple definition of `func_alloc' tests/alloc.o(.text+0xe80):/home/jakov/src/WINE/wine/dlls/kernel/tests/alloc.c: first defined here ld: Warning: size of symbol `func_alloc' changed from 39 to 24 in tests/file.o make: *** [tests/kernel32_test.tmp.o] Error 1 ----------------- What's func_alloc got to do with anything? What is it? -- regards, Jakob Eriksson The wages of sin is debugging. -- Ron Jeffries

April 24, 2002

Re: wine and aol7 [was: Re: New Winsock2 patch series - now tested]

by Michael Cardenas

Attached is a patch that corrects martin wilck's previous patch. It just adds an if flags before deref'ing the flags variable. Not sure if this is the most correct, but it corrects the crash. Files affected: wine/files/file.c Patch against cvs from 04232002 with martin wilck's 4th in his last series of patch applied. Fixes a crash for aol7 and internet explorer (the only two apps I tested, probably for lots of other apps also) On Wednesday 24 April 2002 02:20 pm, Michael Cardenas wrote: > Hello Martin. > > I tested your new series of patches with aol7 and I get a crash. Attached

April 24, 2002

err:ntdll:RtlpWaitForCriticalSection

by Insyde

Hi, Starting a program with: wine --winver win2k --debugmsg -relay,+x11drv,+snoop+dll iyp022.exe (the same error occurs with --winver win98/win95) gives me the folowing error: x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=021f wine: Unhandled exception, starting debugger... x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=021f err:win:WIN_FindWndPtr window 30021 belongs to other process err:win:WIN_FindWndPtr window 30021 belongs to other process In the debbuger windows I have some debug msgs that the debbuger is trying to load and at the end it shows this message: Unhandled exception: wait failed on critical section 0x400f164c (loader_section in libntdll.dll.so) First chance exception: wait failed on critical section 0x400f164c (loader_section in libntdll.dll.so) and this message keeps repeating. How can I solve this? Already tryed with native ntdll.dll and it doesn't work. The program runs OK under Windows. Another problem I'm having is that if I don't specify --winver it doesn't work at all. Is it right? Thanks, Ricardo.

April 24, 2002