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

Re: update to regression testing framework

by Francois Gouget

On Thu, 11 Apr 2002, Paul Millar wrote: [...] > > -ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); > > +named_ok( "Adding atom \"$name\" via GlobalAddAtomA()", ($atom >= > > 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); > > Here's the rationale: when a test result is displayed (currently only on > failure or success in a todo block) the file name and line number are > included. If the test file is altered then any tests after the edit will > have different line numbers. This makes these tests look like new ones: an > undesirable behaviour but not too big an issue. Explicitly naming tests is > a way of making the test results line-number independent. Ok, so the goal is to make it possible to automatically analyze the test results. I see you point then. [...] > meaning) and they may appear at an arbitrary point. A test name always > appears in the same line as the test result, producing lines like: > > tests/atom.pl:Checking GlobalAddAtom[AW](i) i < 0xc0000: Test succeeded > > IMHO, this is a lot cleaner than using trace messages, although there's > still the potential redundancy between a test's name and its error > message. Yes, seems cleaner than test messages but there is the problem of redundancy between the 'name' and the error message. Also, it seems that for your purposes all tests should use named_ok otherwise you will not be able to identify all tests. This means modifying all tests, and/or just having ok. No? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

April 11, 2002

Re: update to regression testing framework

by Paul Millar

On Wed, 10 Apr 2002, Francois Gouget wrote: > > o If you set WINETEST_CONTINUE_ON_FAIL environment variable to 1, "make > This looks like it is equivalent to make -k. Oops, didn't know about that one :) I'll remove the WINETEST_CONTINUE_ON_FAIL code ... > > o The commands "named_ok", "set_name" and "unset_name" now exist (in C > > and Perl). You can use these to specify a name for tests either > > individually (via named_ok) or for a region (via set_name and > > unset_name) > > I'm not too sure about these: > > -ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); > +named_ok( "Adding atom \"$name\" via GlobalAddAtomA()", ($atom >= > 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); Here's the rationale: when a test result is displayed (currently only on failure or success in a todo block) the file name and line number are included. If the test file is altered then any tests after the edit will have different line numbers. This makes these tests look like new ones: an undesirable behaviour but not too big an issue. Explicitly naming tests is a way of making the test results line-number independent. > Did you know that you can also do: > > ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err), > "could not find atom $name, atom=$atom, err=$wine::err" ); > This seems pretty similar and works in perl and C. Yep. But I'd say there's a difference between an error message and a test name: both describe what the test checks for, but labelling a successful test by the error message seems a bit ugly to me. (btw, naming test works under both Perl and C too :) > +set_name( "Checking GlobalAddAtom[AW](i) i < 0xbffff"); > for ($i = 0x0001; ($i <= 0xbfff); $i += 27) > { > ok( GlobalAddAtomA($i) && !defined($wine::err) ); > ok( GlobalAddAtomW($i) && !defined($wine::err) ); > } > +unset_name(); > > would be better as: > > named_tests( "Checking GlobalAddAtom[AW](i) i < 0xbffff") { > for ($i = 0x0001; ($i <= 0xbfff); $i += 27) > { > ok( GlobalAddAtomA($i) && !defined($wine::err) ); > ok( GlobalAddAtomW($i) && !defined($wine::err) ); > } > } Agreed. > But I am not sure it adds that much to: > > trace( "Checking GlobalAddAtom[AW](i) i < 0xbffff"); > for ($i = 0x0001; ($i <= 0xbfff); $i += 27) > { > ok( GlobalAddAtomA($i) && !defined($wine::err) ); > ok( GlobalAddAtomW($i) && !defined($wine::err) ); > } You could use trace, but IMHO there's a difference between using trace and named_tests. Trace messages have arbitrary content (and so arbitrary meaning) and they may appear at an arbitrary point. A test name always appears in the same line as the test result, producing lines like: tests/atom.pl:Checking GlobalAddAtom[AW](i) i < 0xc0000: Test succeeded IMHO, this is a lot cleaner than using trace messages, although there's still the potential redundancy between a test's name and its error message. Thoughts? ---- Paul Millar

April 11, 2002

Re: Handling of messages above WM_USER in pack_message

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > I don't know if this global approach is valid, but at least it helped me to > get winhlp32 working called with WinHelpA from an application. In what other > way can we cope with user defined messages and their related structures in > inter-process SendMessage? We can't. User messages cannot pass data around, WinHelpA will need to do that differently. The best way to find out how is probably to watch winhlp32 with a message spy under Windows. -- Alexandre Julliard julliard(a)winehq.com

April 11, 2002

16-bit apps starting and stopping notification

by Andriy Palamarchuk

I found an issue for a hang of 16-bit application (www.formdocs.com) installer. The app registers with NotifyRegister16 callback function and looks like it hangs while waiting for completion of child process. The last part of relay trace is attached. NotifyRegister16 function of ToolHelp dll is used to register handler for following events: NFY_UNKNOWN NFY_LOADSEG NFY_FREESEG NFY_STARTDLL NFY_STARTTASK NFY_EXITTASK NFY_DELMODULE NFY_RIP NFY_TASKIN NFY_TASKOUT NFY_INCHAR NFY_OUTSTRING NFY_LOGERROR NFY_LOGPARAMERROR Note, this works for 16-bit applications only. These events also used by debuggers to debug 16-bit applications. Can somebody give me a hint how is better to approach implementation of NFY_EXITTASK, NFY_STARTTASK events generation? How important do you think is to implement this functionality, since it is for 16-bit apps only? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

April 10, 2002

Re: Wine & ActiveX?

by Andriy Palamarchuk

--- Mark Lehrer <mark(a)knm.org> wrote: > Is there a document that can help us > with debugging > procedures? Obviously running Visual Studio is not > an option... but > what is the best way to start looking at what may be > going wrong? See http://www.wihehq.com/trouble Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

April 10, 2002

RE: update to regression testing framework

by Geoffrey Hausheer

> -----Original Message----- > From: Paul Millar paulm(a)astro.gla.ac.uk > Subject: update to regression testing framework > o The commands "named_ok", "set_name" and "unset_name" now > exist (in C > and Perl). You can use these to specify a name for tests either > individually (via named_ok) or for a region (via set_name and > unset_name) > What is the benefit of this? The current framework supports 'ok(test,printf-style string)' which seems to be fine for debugging in general, and 'trace' to just print out general purpose information about what the test is doing. Thanks, .Geoff

April 10, 2002

Re: update to regression testing framework

by Francois Gouget

On Wed, 10 Apr 2002, Paul Millar wrote: > Hi, > > The attached patch changes the way the regression testing works slightly. > The default behaviour should be the same, but there's some optional > "enhancements": > > o If you set WINETEST_REPORT_SUCCESS environment variable to 1, > successful tests are reported as well as unsuccessful ones. I don't know if this is really useful but why not. > o If you set WINETEST_CONTINUE_ON_FAIL environment variable to 1, "make > test" will run all tests from all modules, rather than failing on the > first failing module. This looks like it is equivalent to make -k. > o The commands "named_ok", "set_name" and "unset_name" now exist (in C > and Perl). You can use these to specify a name for tests either > individually (via named_ok) or for a region (via set_name and > unset_name) I'm not too sure about these: -ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); +named_ok( "Adding atom \"$name\" via GlobalAddAtomA()", ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); Did you know that you can also do: ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err), "could not find atom $name, atom=$atom, err=$wine::err" ); This seems pretty similar and works in perl and C. Also about the following: +set_name( "Checking GlobalAddAtom[AW](i) i < 0xbffff"); for ($i = 0x0001; ($i <= 0xbfff); $i += 27) { ok( GlobalAddAtomA($i) && !defined($wine::err) ); ok( GlobalAddAtomW($i) && !defined($wine::err) ); } +unset_name(); would be better as: named_tests( "Checking GlobalAddAtom[AW](i) i < 0xbffff") { for ($i = 0x0001; ($i <= 0xbfff); $i += 27) { ok( GlobalAddAtomA($i) && !defined($wine::err) ); ok( GlobalAddAtomW($i) && !defined($wine::err) ); } } This way one would not accidentally forget to unset the name. But I am not sure it adds that much to: trace( "Checking GlobalAddAtom[AW](i) i < 0xbffff"); for ($i = 0x0001; ($i <= 0xbfff); $i += 27) { ok( GlobalAddAtomA($i) && !defined($wine::err) ); ok( GlobalAddAtomW($i) && !defined($wine::err) ); } Traces are not printed by default but will be if you run the test as: runtest -v ... instead of runtest -q ... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

April 10, 2002

update to regression testing framework

by Paul Millar

Hi, The attached patch changes the way the regression testing works slightly. The default behaviour should be the same, but there's some optional "enhancements": o If you set WINETEST_REPORT_SUCCESS environment variable to 1, successful tests are reported as well as unsuccessful ones. o If you set WINETEST_CONTINUE_ON_FAIL environment variable to 1, "make test" will run all tests from all modules, rather than failing on the first failing module. o The commands "named_ok", "set_name" and "unset_name" now exist (in C and Perl). You can use these to specify a name for tests either individually (via named_ok) or for a region (via set_name and unset_name) The patch changes both the C and Perl frameworks. I'm pretty sure the Perl is right but someone who actually knows Perl ought to check it :) The second patch illustrates these by changing dlls/kernel/tests/atom.pl and dlls/kernel/tests/directory.c (apologies to Alexandre & Dmitry if I got the test semantics wrong). HTH ---- Paul Millar ChangeLog: Adding test names and some optional behaviour.

April 10, 2002

Re: Wine & ActiveX?

by Uwe Bonnes

>>>>> "Mark" == Mark Lehrer <mark(a)knm.org> writes: Mark> Hello! Mark> We are trying to make one of our applications work under Wine on Mark> Red Hat 7.2. We have a lot of talent here in both Linux and Mark> Windows, but no Wine experts (yet!). Mark> Unfortunately it only gets as far as showing the splash screen Mark> before it freezes. Is there a document that can help us with Mark> debugging procedures? Obviously running Visual Studio is not an Mark> option... but what is the best way to start looking at what may be Mark> going wrong? It uses ActiveX so perhaps that is the trouble. We Mark> took out all of the DCOM stuff already. The first thing to try is to enable debugmsg, perhaps try with --debugmsg +relay. When the program hangs, you can see whether it loops or hangs in one function. There are about 100 debugchanels available. Learn about them in the .spec files and the source. Hope this is a first start. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 10, 2002

Wine & ActiveX?

by Mark Lehrer

Hello! We are trying to make one of our applications work under Wine on Red Hat 7.2. We have a lot of talent here in both Linux and Windows, but no Wine experts (yet!). Unfortunately it only gets as far as showing the splash screen before it freezes. Is there a document that can help us with debugging procedures? Obviously running Visual Studio is not an option... but what is the best way to start looking at what may be going wrong? It uses ActiveX so perhaps that is the trouble. We took out all of the DCOM stuff already. Thanks! Mark

April 10, 2002