August 2011 - Wine-Devel - list.winehq.org

Re: Testing edge cases and undocumented behavior

by Steven Edwards

On Fri, Aug 26, 2011 at 6:00 AM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > It is a good advice. But that doesn't means one has to submit tests that > don't make sense. It seems like a simple comment describing the undocumented behavior would help. I wrote some tests years ago (the details are not important because I don't remember them) based upon something in MSDN and found that I could pass some extra foo and undocumented magic would result. My point is, I wish now I had written down in the form of a one or two line comment, what I saw, so that in the future if I or someone else were tracking down a bug in that component, that little note might save someone else hours of effort. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Aug. 31, 2011

Re: [3/7] dinput: Added enumerated devices to ConfigureDevices dialog

by Octavian Voicu

On Wed, Aug 31, 2011 at 3:11 AM, Lucas Zawacki <lfzawacki(a)gmail.com> wrote: > Any pointers on what's the set of winapi functions used to store and > retrieve data in windows? I've searched MSDN for almost 30 minutes and > no luck. Try SetWindowLongPtr [1] / GetWindowLongPtr [2]. You probably want to use the W variants of the functions, though the A/W distinction doesn't make much sense in this case. Octavian [1] http://msdn.microsoft.com/en-us/library/ms644898(v=VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/ms633585(v=VS.85).aspx

Aug. 31, 2011

Re: [3/7] dinput: Added enumerated devices to ConfigureDevices dialog

by Lucas Zawacki

> It doesn't make sense to pass the info as WM_INITDIALG parameter if it's > going to be stored in global variables anyway. A better way would be to > store this in the window info. > Any pointers on what's the set of winapi functions used to store and retrieve data in windows? I've searched MSDN for almost 30 minutes and no luck.

Aug. 31, 2011

Re: [PATCH 1/5] cmd/tests: add more tests for command line parsing

by Martin Wilck

> IMHO we should probably split it only when it's reasonably complete, > where we'd have a broader view. Well, it's up to you. I just made an attempt to merge my stuff into test_builtins and gave up after 2 hours :-( > Also, test_parsing name is probably a bit too generic (not that > test_builtins isn't ;) ) > > But you can still submit it in the meantime, maybe AJ will accept it. > Just make sure there's no duplication AFAICT there is no real duplication. 4 TODOs in the current test_builtins are removed by the last of my patches, so there is some overlap, but I wouldn't call it a duplicate. > Also, when you have to make tests work on NT4->2k8 *and* wine at *all* > times, you sometimes have to make your hands dirty. I tested my stuff only on XP. Perhaps someone can help me out testing other native versions. > Just ask if you don't understand the @keywords(a). Doc is a bit lacking; > I might add a quick wiki help page if desired. Yes, that'd be helpful (IMO just a README file in the tests/ directory would be even better). It took me a while to get started with the cmd testing code. > Did you correctly register via > http://www.winehq.org/mailman/listinfo/wine-patches? I was hoping this was an open ML (and last time tried it was). OK, I'll subscribe and re-submit. > Nice job by the way. Thanks a lot, it seems that you took on a big task with cmd, good luck! Martin

Aug. 30, 2011

Re: [PATCH 1/5] cmd/tests: add more tests for command line parsing

by Frédéric Delanoy

2011/8/30 Martin Wilck <mwilck(a)arcor.de>: > Hi Frédéric, > >> Some of those tests are already present in the test_builtins.cmd* >> (e.g. the spacing tests) >> You should probably integrated your tests in there: that makes it >> easier to spot regressions and helps prevent tests duplication > > I can certainly do that if you prefer (and I will), but I don't agree > that having all tests in a single big file is an advantage. Splitting > the unit tests over multiple files would make it much easier to relate > output lines to script lines and do focused work on certain areas. Cmd test suite would probably eventually benefit from this on the long term, but it's still very incomplete in a number of areas (thanks for helping improve it BTW). IMHO we should probably split it only when it's reasonably complete, where we'd have a broader view. (it also makes viewing regression easier for the devs since the parser is rather fragile, and everything is a bit intertwined) Also, test_parsing name is probably a bit too generic (not that test_builtins isn't ;) ) But you can still submit it in the meantime, maybe AJ will accept it. Just make sure there's no duplication > For > anyone who doesn't work on it regularly, test_builtins.cmd is a nightmare. Just look at cmd parser code if you really want to be afraid ;) I'm a bit responsible for this, but the current parser has numerous shortcomings/bugs that sometimes force to use ugly workarounds. Also, when you have to make tests work on NT4->2k8 *and* wine at *all* times, you sometimes have to make your hands dirty. (e.g. a restriction is that you need the same # of lines of the processed cmd file, and the expected file, on all windowses and wine. There's no support for skip() or win_skip() either like is available in the other regular C unit tests. I guess that eating one's own dogfood...) Just ask if you don't understand the @keywords(a). Doc is a bit lacking; I might add a quick wiki help page if desired. Basically the most important ones are @todo_wine@ and @or_broken@ (respectively to indicate the test fails on wine, or have alternate results in other windowses) Wine testbot can also help (https://testbot.winehq.org/index.pl) >> Also, see http://www.winehq.org/pipermail/wine-devel/2011-August/091817.html > > I'm not sure why you're telling me that. Well the mentioned link was about splitting tests ("Cmd tests timeout and splitting tests") The discussion thread was about splitting the test file into distinct subfiles, such as 1 per builtin or so do a timeout on some linux machines. (Cmd's testsuite run in a matter of seconds on windowses, but much longer on distinct linux/bsd test machines) > My patches aren't about > performance but correctness. They won't affect performance negatively, > either. Of course not, since it's only in the test proc > Regards, > Martin Nice job by the way. Frédéric > PS: any idea why my patches didn't make it to wine-patches? Did you correctly register via http://www.winehq.org/mailman/listinfo/wine-patches?

Aug. 30, 2011

re: [SOLVED] [PATCH]Where is the best place to report a fscanf bug found under wine-1.3.27?

by Alan W. Irwin

On 2011-08-30 08:33-0700 Dan Kegel wrote: >> Today I discovered .. that the scanf family of functions was >> introducing float (32-bit floating-point) noise into double (64-bit >> floating-point) results. > > I see it here, too: > > $ sudo apt-get install mingw32 > $ i586-mingw32msvc-gcc test_fscanf.c > $ echo "1.1e+01 > 1.1e+00 > 1.1e-01 > 1.1e-02 > 1.1e-03 > 1.1e-04" | ~/wine-git/wine a.exe > 1.10000000000000000e+001 > 1.10000000000000009e+000 > 1.10000001639127737e-001 > 1.10000003278255491e-002 > 1.10000004917383261e-003 > 1.10000006556511075e-004 > > You can work around it with 'winetricks vcrun6', after which the test > program outputs: > 1.10000000000000000e+001 > 1.10000000000000010e+000 > 1.10000000000000000e-001 > 1.09999999999999990e-002 > 1.10000000000000010e-003 > 1.10000000000000000e-004 > > So the problem is in wine's msvcrt.dll. > > You could narrow it down further by printing out the raw byte strings > for the numbers > and then sprinking that printout through the path from when scanf is > called to where printf returns. > (Or, I suppose, step through it with a debugger instead.) > > But the best place to report the bug is http://bugs.winehq.org Hi Dan: Thanks for these hints. It was good to know of that workaround involving downloading a Microsoft library to replace the one from wine in case I needed it. However, I prefer a direct fix if possible so I looked further and finally found the code in question in the _FUNCTION_ routine in wine-1.3.27/dlls/msvcrt/scanf.h. Sure enough it has an inappropriate float in it which appears to be the source of the trouble. Therefore, I tried this patch: --- scanf.h_original 2011-08-30 12:35:25.000000000 -0700 +++ scanf.h 2011-08-30 12:36:23.000000000 -0700 @@ -346,7 +346,7 @@ /* handle exponent */ if (width!=0 && (nch == 'e' || nch == 'E')) { int exponent = 0, negexp = 0; - float expcnt; + double expcnt; nch = _GETC_(file); if (width>0) width--; /* possible sign on the exponent */ rebuilt wine-1.3.27, and I now have this result: bash.exe-3.1$ echo "1.1e+01 1.1e+00 1.1e-01 1.1e-02 1.1e-03 1.1e-04" | ./a.exe 1.10000000000000000e+001 1.10000000000000009e+000 1.10000000000000001e-001 1.10000000000000011e-002 1.10000000000000028e-003 1.10000000000000031e-004 Pretty good, if I do say so myself, for someone who has only a superficial understanding of the scanf code! I will follow up with a proper bug report at http://bugs.winehq.org so this patch isn't lost. But before I do that I am going to charge ahead with ephcom2 build and tests to make sure this scanf function family fix for wine-1.3.27 works in that much more complicated case as well. Best wishes, and thanks again for the hints. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Aug. 30, 2011

Re: [PATCH 1/5] cmd/tests: add more tests for command line parsing

by Martin Wilck

Hi Frédéric, > Some of those tests are already present in the test_builtins.cmd* > (e.g. the spacing tests) > You should probably integrated your tests in there: that makes it > easier to spot regressions and helps prevent tests duplication I can certainly do that if you prefer (and I will), but I don't agree that having all tests in a single big file is an advantage. Splitting the unit tests over multiple files would make it much easier to relate output lines to script lines and do focused work on certain areas. For anyone who doesn't work on it regularly, test_builtins.cmd is a nightmare. > Also, see http://www.winehq.org/pipermail/wine-devel/2011-August/091817.html I'm not sure why you're telling me that. My patches aren't about performance but correctness. They won't affect performance negatively, either. Regards, Martin PS: any idea why my patches didn't make it to wine-patches?

Aug. 30, 2011

win7 pro sp1 x64 testbot live

by Maarten Lankhorst

Hi all, I've added a win7 sp1 testbot, it's currently in the extra vm's pool, so it requires some extra actions to find it, but if you want to run your tests against windows 7 sp1 with ie9 installed, you should now be able to. Happy testing!! ~Maarten

Aug. 30, 2011

Re: Where is the best place to report a fscanf bug found under wine-1.3.27?

by Eric Pouech

Le 30/08/2011 20:38, Peter Rosin a écrit : > Den 2011-08-30 20:18 skrev David Laight: >> On Mon, Aug 29, 2011 at 06:43:41PM -0700, Alan W. Irwin wrote: >>> double x; >>> while(fscanf(stdin, " %le ",&x) == 1) >> You are using the wrong format, %le is for 'long double', this will >> probably overwrite too much data. > Nope, you are mistaken and the OP is correct. > > %e float > %le double > %Le long double > > Cheers, > Peter > > > from what I understand, double and long double have the same precision under msvc, while they don't on linux (and gcc) likely a problematic conversion somewhere in the code path A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Aug. 30, 2011

Re: Where is the best place to report a fscanf bug found under wine-1.3.27?

by Peter Rosin

Den 2011-08-30 20:18 skrev David Laight: > On Mon, Aug 29, 2011 at 06:43:41PM -0700, Alan W. Irwin wrote: >> double x; >> while(fscanf(stdin, " %le ", &x) == 1) > > You are using the wrong format, %le is for 'long double', this will > probably overwrite too much data. Nope, you are mistaken and the OP is correct. %e float %le double %Le long double Cheers, Peter

Aug. 30, 2011