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

Re: cmd/tests: Test del /s recursion in subdirectories with colons.
by Frédéric Delanoy 31 Aug '11

31 Aug '11

On Tue, Aug 30, 2011 at 14:19, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > -- > Issue was fixed by 94d2312fe2fdd77669ac826afa24e6821571ebba. This test is to > prevent future regressions, as suggested by Frederic. > > Windows doesn't accept colons in directory names, so it will just fail on the > mkdir/rmdir commands and not affect the tests. > > --- > programs/cmd/tests/test_builtins.cmd | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/programs/cmd/tests/test_builtins.cmd b/programs/cmd/tests/test_builtins.cmd > index 1250e89..34c44f5 100644 > --- a/programs/cmd/tests/test_builtins.cmd > +++ b/programs/cmd/tests/test_builtins.cmd > @@ -854,6 +854,7 @@ rmdir del_q_dir > echo ------------ Testing del /s -------------- > mkdir "foo bar" > cd "foo bar" > +mkdir "foo:" > echo hi > file1.dat > echo there > file2.dat > echo bub > file3.dat > @@ -868,6 +869,7 @@ for %%f in (1 2 3) do if exist file%%f.dat echo Del /s failed on file%%f > for %%f in (1 2 3) do if exist file%%f.dat del file%%f.dat > if exist "file with spaces.dat" echo Del /s failed on "file with spaces.dat" > if exist "file with spaces.dat" del "file with spaces.dat" > +rmdir "foo:" > cd .. > rmdir "foo bar" You don't test the result of your 'mkdir "foo:"'. You can't know from the test whether the dir was created and removed, or never existed. You should use something like "if exist ... echo blablabla", or a 'dir /b' in a directory to verify it's not created. Be aware that error messages are generally lost/discarded, so you have to test differently

2 3

Re: [PATCH] ntdll: provide a timestamp debug channel, which prints a millisecond resolution timestamp in front of debug output, very useful to debug deadlocks (resend)
by Alexandre Julliard 31 Aug '11

31 Aug '11

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -164,8 +165,16 @@ static int NTDLL_dbg_vlog( enum __wine_debug_class cls, struct __wine_debug_chan > /* only print header if we are at the beginning of the line */ > if (info->out_pos == info->output || info->out_pos[-1] == '\n') > { > + if (TRACE_ON(timestamp)) > + { > + LARGE_INTEGER now; > + extern timeout_t server_start_time; Don't add extern statements all over the place, there are functions to return tick counts. Also you probably want a more readable formatting. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 1/4] msi: speed up WHERE statement evaluation by evaluating the condition as early as possible
by Alexandre Julliard 31 Aug '11

31 Aug '11

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -639,6 +715,8 @@ static UINT WHERE_execute( struct tagMSIVIEW *view, MSIRECORD *record ) > while ((table = table->next)); > > rows = msi_alloc( wv->table_count * sizeof(*rows) ); > + memset( rows, 0xFF, sizeof( rows ) ); > + If the goal is to set them to -1, please do that explicitly. Also defining some appropriate constant for invalid rows would be even better. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ieframe: Fix a few incorrect pointer/integer casts on x64.
by Michael Stefaniuc 31 Aug '11

31 Aug '11

Hello Octavian, in general please use the ULongToHandle*() / HandleToULong() macro family instead of the explicit casting. Octavian Voicu wrote: > --- > dlls/ieframe/iexplore.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/ieframe/iexplore.c b/dlls/ieframe/iexplore.c > index 99e3003..82c2e79 100644 > --- a/dlls/ieframe/iexplore.c > +++ b/dlls/ieframe/iexplore.c > @@ -937,7 +937,7 @@ static HDDEDATA WINAPI dde_proc(UINT type, UINT uFmt, HCONV hConv, HSZ hsz1, HSZ > switch(type) { > case XTYP_CONNECT: > TRACE("XTYP_CONNECT %p\n", hsz1); > - return (HDDEDATA)!DdeCmpStringHandles(hsz1, ddestr_openurl); > + return (HDDEDATA)(INT_PTR)!DdeCmpStringHandles(hsz1, ddestr_openurl); > > case XTYP_EXECUTE: { > WCHAR *url; > @@ -961,7 +961,7 @@ static HDDEDATA WINAPI dde_proc(UINT type, UINT uFmt, HCONV hConv, HSZ hsz1, HSZ > break; > } > > - ret = (HDDEDATA)open_dde_url(url); > + ret = (HDDEDATA)(ULONG_PTR)open_dde_url(url); This is the only user of open_dde_url() so that helper might as well return a HDDEDATA instead of an ULONG. But that's something for Jacek to decide. > > heap_free(url); > return ret; > @@ -999,7 +999,7 @@ static void init_dde(void) > if(!ddestr_openurl) > WARN("Failed to create string handle: %u\n", DdeGetLastError(dde_inst)); > > - res = (ULONG)DdeNameService(dde_inst, ddestr_iexplore, 0, DNS_REGISTER); > + res = (UINT)(UINT_PTR)DdeNameService(dde_inst, ddestr_iexplore, 0, DNS_REGISTER); > if(res != DMLERR_NO_ERROR) > WARN("DdeNameService failed: %u\n", res); > } thanks bye michael

1 0

Testing edge cases and undocumented behavior
by Joerg-Cyril.Hoehle＠t-systems.com 31 Aug '11

31 Aug '11

Scott Ritchie wrote: >There was a bit of a philosophical discussion on #winehackers about the >merits of creating tests for functions that might be testing undefined >or unimportant behavior. Windows behaves one way, we behave another, >the tests measure this delta, but it's unknown if this will actually >improve a real world application. Vincent Povirk wrote an excellent reply. I hope somebody will turn that into a Wiki page. >More broadly, should we resist any change without a particular >(real-world) application in hand that needs it? This is stupid because you're always late. Like a fireman. a) Somebody who wrote the bug report is waiting for the bug to be fixed ASAP. b) It takes a lot of effort to analyse huge and cryptic log files to find out what the particular delta is. >Or should we err on the side of testable behavior, What you test is what you know. It's not erring. If you don't know what the behaviour should be, you can't add a FIXME pointing out that Wine deviates from native behaviour. When I asked about testing depth w.r.t. the MCI a few years ago, Paul Vriens advised to test to the bones. IMHO that's good advice. I recommend beginners to start writing tests *first*. Doing so, you learn a lot about the component Wine purports to mimic. You can then even start to predict failures! Somehow I believe I'm a very untypical Wine contributor. I'm not bug driven. Quite to the contrary, my thesis is that once you've tested a component to the bones *and* replicated the observable behaviour, there will be few opportunities left for people to report bugs. The basic alternative is that if you have free time now, you can either try to understand obscure logs of some component you're not exactly familiar with and more or less well documented, perhaps single-step your way through the debugger, *OR* you can spend time shedding light on said component via tests, mostly working with logs you control because you're working with full source to your test and the Wine code. That's what I was doing with the audio parts of the MCI before WinMM was rewritten to use mmdevapi. Now that's what I'm doing with mmdevapi. After that, should I still have the energy, I'll look at WinMM audio. Other benefit: - Tests get executed daily whereas an application X can be made to work in wine-X yet break again in X+1 until somebody notices. Regards, Jörg Höhle

4 4

win7 pro sp1 x64 testbot live
by Maarten Lankhorst 30 Aug '11

30 Aug '11

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

1 0

Where is the best place to report a fscanf bug found under wine-1.3.27?
by Alan W. Irwin 30 Aug '11

30 Aug '11

Today I discovered while debugging a fairly complex application that I built under MinGW/MSYS/wine that the scanf family of functions was introducing float (32-bit floating-point) noise into double (64-bit floating-point) results. I implemented a simple test code to make it extremely easy to replicate this issue: cat test_fscanf.c #include <stdlib.h> #include <stdio.h> void main(void) { double x; while(fscanf(stdin, " %le ", &x) == 1) { printf("%25.17e\n", x); } } On Linux you can build it and run it with these expected results with some numerical noise in the last place: gcc test_fscanf.c echo "1.1e+01 1.1e+00 1.1e-01 1.1e-02 1.1e-03 1.1e-04" | ./a.out 1.10000000000000000e+01 1.10000000000000009e+00 1.10000000000000001e-01 1.09999999999999994e-02 1.10000000000000007e-03 1.10000000000000004e-04 But if you do the same build on wine you get these noisy results for all the values with negative exponents (but positive exponents are fine for some reason). 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.10000001639127737e-001 1.10000003278255491e-002 1.10000004917383261e-003 1.10000006556511075e-004 The level of noise is consistent with some float (as opposed to double) logic incorrectly being used in the fscanf library function for negative exponents, and I had similar bad numerical noise results from sscanf with my complex application. My hardware is 64-bit. My wine is 32-bit wine-1.3.27 built on a Debian Squeeze box with the standard 32-bit Debian build dependencies for wine. The wine gcc is from the MinGW version you get with the automatic MinGW/MSYS installer from a few days ago. It's version number is bash.exe-3.1$ gcc --version gcc.exe (GCC) 4.5.2 ... The above wine test was run in a wineconsole running the MSYS version of bash. So for my wine installation (which has no access to Microsoft libraries), how can I find out which library is providing the fscanf functionality that is introducing float noise into double results for the above test programme? I need that information so that I can properly report the above bug. If someone here knows exactly where to make the fix and is inspired to do so, I would be happy to test the result with my more complex ephcom2 application (reading and interpolating JPL ephemerides, see http://sourceforge.net/news/?group_id=567377&id=302987 for the latest release announcement). That release was POSIX only, but I hope to make the next version work properly on Windows as well. The current status is that ephcom2 builds and mostly tests well under wine except for the above numerical noise in sscanf results which I would like to get rid of to see if there are any other remaining generic Windows issues in the software. 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 __________________________

4 3

Re: winelib an fpc
by Reinier Napoles Martinez 30 Aug '11

30 Aug '11

>>This won't work. Simply doing a dlopen on the wine libraries won't get >>your environment setup properly. what can i do then to setup the wine environment correctly and use the wine libraries from fpc. thanks -- ********************************************************************* En la tierra hace falta personas que trabajen más y critiquen menos, que construyan más y destruyan menos, que prometan menos y resuelvan más que esperen recibir menos y dar más que digan mejor ahora que mañana. Che *********************************************************************

3 2

Re: widl: duplicate type in case of argument with range attribute
by Alexandre Julliard 30 Aug '11

30 Aug '11

Jérôme Gardou <jerome.gardou(a)laposte.net> writes: > @@ -1418,6 +1418,11 @@ static var_t *declare_var(attr_list_t *attrs, decl_spec_t *decl_spec, const decl > type_t *func_type = decl ? decl->func_type : NULL; > type_t *type = decl_spec->type; > > + /* In case of a range attribute, duplicate the type to keep track of > + * the min/max values in the type format string */ > + if(is_attr(attrs, ATTR_RANGE)) > + type = duptype(type, 1); You shouldn't need that. The range should go with the variable and be output again for each type. Please add a test case showing the problem. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: Severe startup latencies for Windows applications run under wine
by Ben Peddell 30 Aug '11

30 Aug '11

On 08/30/11 10:33, Alan W. Irwin wrote: > On 2011-08-30 08:20+1000 Ben Peddell wrote: >> Some things I have seen while investigating: >> >> I created a program which had a startup that immediately called >> ExitProcess to attempt to eliminate most of the initialization of the >> process being forked. >> >> On Windows 7 x64 SP1 on an AMD 5050e: >> bash.exe takes about 22.2ms to fork. >> make.exe takes about 8.8ms to fork. >> cmd.exe takes about 5.9ms to fork. >> >> Under wine 1.2.1 on linux 2.6.38 on an AMD 5050e: >> bash.exe takes about 236ms to fork nothing, and 182ms to fork /bin/true. >> make.exe takes about 77ms to fork nothing, and 25ms to fork /bin/true. >> wine-cmd takes about 9ms to fork nothing. >> >> Under wine-git on linux 2.6.38 on an AMD 5050e: >> bash.exe takes about 190ms to fork nothing, and 147ms to fork /bin/true >> make.exe takes about 71ms to fork nothing and 20ms to fork /bin/true. >> wine-cmd takes about 9ms to fork nothing. > > Just out of curiosity do you have any explanation of why /bin/true provided > faster make.exe results than your quick-exiting programme both for > wine-1.2.1 and wine-git? I suspect that the fork/exec emulation detects if the executable is a MSYS executable, and if so, takes a fast path, skipping a lot of the initialization that the MSYS executable would have done. > >> >> Even the native bash takes twice as long to fork as make - 1.1ms vs >> 0.5ms. >> >> It looks to me like the fork emulation in MSYS is encountering a >> bottleneck, and not actual process creation. > > I assume you meant "encountering a _wine_ bottleneck" since clearly > above your MSYS tests of make.exe and bash.exe on Windows don't have > the large startup latencies you encounter with wine-1.2 and wine-git. > > How does the MSYS version of make (make.exe that you tried above) > compare in this regard with the MinGW version of make > (MinGW/bin/mingw32-make.exe) that specifically excludes everything to > do with MSYS? My guess is you will encounter a similar wine > bottleneck for this case as well, but it is worth verifying that. I suspect mingw32-make uses fork() emulation when launching MSYS programs, and CreateProcess() otherwise - the execution time for msys-echo and msys-true are on par with those under msys-make, and the execution time for ExitProcess.exe is on par with that under wine-cmd. > > And now you have done a clean comparison with the same software stack > it is clear that wine-git somewhat reduces the bottleneck compared to > wine-1.2. Thus, I expect my own planned clean comparisons to show the > same. So I have changed the subject line appropriately. > > Now, if someone could just figure out what the wine bottleneck is that > is causing these severe start-up latencies for Windows applications.... A modification of the timestamp patch from Bernhard Loos should help us find what calls are taking the longest. bash: running /bin/echo: +0ms:0024:Call KERNEL32.CreateProcessA(bash) => tid 0028 +8ms:0028:Call KERNEL32.__wine_kernel_init() +11ms:0024:Call KERNEL32.WaitForMultipleObjects() +21ms:0028:DLLs loading +43ms:0028:Process starting +45ms:0028:Call KERNEL32.SetEvent() => wake 0024 +45ms:0024:Call KERNEL32.WriteProcessMemory() +45ms:0028:Call KERNEL32.WaitForSingleObject() write-process-memory 10 times, totalling 500kB +134ms:0024:Ret KERNEL32.WriteProcessMemory() +134ms:0028:Ret KERNEL32.SetFileApisToANSI() ??? +148ms:0028:Call KERNEL32.CreateProcessA(echo) => tid 002b +155ms:002b:Call KERNEL32.__wine_kernel_init() +157ms:0028:Ret KERNEL32.CreateProcessA() +158ms:0028:Call KERNEL32.WaitForMultipleObjects() +163ms:002b:DLLs loading +163ms:002b:Process starting +169ms:0028:Call KERNEL32.ExitProcess() +172ms:002b:Call KERNEL32.ExitProcess() bash: running ExitProcess.exe: +0ms:0024:Call KERNEL32.CreateProcessA(bash) => tid 0034 +7ms:0034:Call KERNEL32.__wine_kernel_init() +11ms:0024:Call KERNEL32.WaitForMultipleObjects() +20ms:0034:DLLs loading +42ms:0034:Process starting +44ms:0034:Call KERNEL32.SetEvent() => wake 0024 +44ms:0024:Call KERNEL32.WriteProcessMemory() +44ms:0034:Call KERNEL32.WaitForSingleObject() write-process-memory 10 times, totalling 500kB +130ms:0024:Ret KERNEL32.WriteProcessMemory() +130ms:0034:Ret KERNEL32.WaitForSingleObject() looking at attributes of a whole heap of directories... +215ms:0034:Call KERNEL32.CreateProcessA(ExitProcess.exe) => tid 0037 +221ms:0037:Call KERNEL32.__wine_kernel_init() +223ms:0034:Ret KERNEL32.CreateProcessA() +224ms:0034:Call KERNEL32.WaitForMultipleObjects() +224ms:0037:Call KERNEL32.ExitProcess() +225ms:0034:Call KERNEL32.ExitProcess() -- Ben Peddell IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools http://klightspeed.killerwolves.net/

2 1