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

RFC - ws2_32/socket.c: SIO_KEEPALIVE_VALS vs TCP_KEEPIDLE/TCP_KEEPINTVL
by Bruno Jesus 30 Aug '11

30 Aug '11

This discussion is related to the test failing in bug 21271: http://bugs.winehq.org/show_bug.cgi?id=21271 The SIO_KEEPALIVE_VALS message on windows takes parameters as miliseconds, on some other systems there are the equivalent TCP_KEEPIDLE/TCP_KEEPINTVL which takes the parameters as seconds. To solve this there is a division by 1000 on wine source code but the problem is that values < 1000 become 0 making the setsockopt function return error. Is it reasonable to do a check to see if the result of the division is zero and then set the variable to one so we can get closer to the windows implementation and not fail the setsockopt function? It will obviously not match 100% the windows implementation but it seems to be as close as we can get and as far as I can think it's better for the applications to receive a one second keepalive then never receiving any. SIO_KEEPALIVE_VALS bibliography (read specially the remarks): http://msdn.microsoft.com/en-us/library/dd877220%28v=vs.85%29.aspx TCP_KEEPIDLE/TCP_KEEPINTVL bibliography (almost no information, sorry) http://linux.die.net/man/7/tcp http://www.yolinux.com/TUTORIALS/Sockets.html Wine source code link (ignore the fact that there may be a read on address zero that is only checked later): http://source.winehq.org/source/dlls/ws2_32/socket.c#L3362 I have tested locally and will try to add tests to wine git but I prefered to start the discussion first. If I have missed something or this was already discussed accept my apologies in advance. Best wishes, Bruno

2 1

re: wineview: Rename view to wineview and install it
by Dan Kegel 30 Aug '11

30 Aug '11

Alexandre wrote: > I don't think we need to rename it. $ which view /usr/bin/view $ view --version VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Apr 16 2010 12:33:18) ... I'm pretty sure view has been taken for many years as the way to invoke vi in read-only mode. - Dan

2 1

Re: [4/6] ddraw: Convert dwZBufferBitDepth into a DDPIXELFORMAT (try 2)
by Henri Verbeet 30 Aug '11

30 Aug '11

On 30 August 2011 12:57, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static DWORD make_bitmask(DWORD count) > +{ > + DWORD ret = 0; > + for (count--; count != ~0U; count--) ret |= 1 << count; > + return ret; > +} You could probably do something like "return count ? ~0U >> (32 - count) : 0;" In this specific case you probably don't care about 0 though, so you might as well just do something like "out->u4.ddpfPixelFormat.u3.dwZBitMask = ~0U >> (32 - in->u2.dwZBufferBitDepth);".

1 0

Re: wineview: Rename view to wineview and install it
by Alexandre Julliard 30 Aug '11

30 Aug '11

André Hentschel <nerv(a)dawncrow.de> writes: > i think wineview is a better name for installation > this also merges the resources I don't think we need to rename it. Also the accelerators are supposed to be translatable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] vbscript: Added SetScriptSite tests
by Marvin 30 Aug '11

30 Aug '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=13830 Your paranoid android. === W2KPROSP4 (32 bit vbscript) === vbscript.c:134: Test failed: unexpected call OnStateChange_CLOSED === WXPPROSP3 (32 bit vbscript) === vbscript.c:134: Test failed: unexpected call OnStateChange_CLOSED === W2K3R2SESP2 (32 bit vbscript) === vbscript.c:134: Test failed: unexpected call OnStateChange_CLOSED === WVISTAADM (32 bit vbscript) === vbscript.c:134: Test failed: unexpected call OnStateChange_CLOSED === W2K8SE (32 bit vbscript) === vbscript.c:134: Test failed: unexpected call OnStateChange_CLOSED === W7PRO (32 bit vbscript) === vbscript.c:134: Test failed: unexpected call OnStateChange_CLOSED === W7PROX64 (32 bit vbscript) === vbscript.c:134: Test failed: unexpected call OnStateChange_CLOSED === W7PROX64 (64 bit vbscript) === vbscript.c:134: Test failed: unexpected call OnStateChange_CLOSED

2 1

Re: [1/5] ddraw: Introduce a function to convert a DDSURFACEDESC to a DDSURFACEDESC2
by Henri Verbeet 30 Aug '11

30 Aug '11

On 29 August 2011 19:20, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +/* Note that this function writes the full sizeof(DDSURFACEDESC2) size, don't use it So no need to clear it first.

2 4

Re: cmd: Don't parse colons as stream separators when splitting paths.
by Frédéric Delanoy 30 Aug '11

30 Aug '11

On Sun, Aug 28, 2011 at 00:39, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > Fixes an infinite recursion when running a command such as "del file.txt /S" > in a directory that has some subdirectory with a colon in its name. > > The filename:stream syntax can be used on native to access alternate data > streams on NTFS partitions. Such support would obviously need to be > implemented by the underlying filesystem, so there is no point in parsing > this is Wine. > > --- > programs/cmd/batch.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/programs/cmd/batch.c b/programs/cmd/batch.c > index 03c92ee..bbefcfb 100644 > --- a/programs/cmd/batch.c > +++ b/programs/cmd/batch.c > @@ -222,8 +222,8 @@ void WCMD_splitpath(const WCHAR* path, WCHAR* drv, WCHAR* dir, WCHAR* name, WCHA > } else if (drv) > *drv = '\0'; > > - /* search for end of string or stream separator */ > - for(end=path; *end && *end!=':'; ) > + /* search for end of string */ > + for(end=path; *end; ) > end++; > > /* search for begin of file extension */ > -- Might be a good idea to add a simple testcase

2 3

Severe startup latencies for Windows applications run under wine
by Alan W. Irwin 30 Aug '11

30 Aug '11

Hi Ben: Thanks for your further tests. On 2011-08-30 08:20+1000 Ben Peddell wrote (but then later forwarded to list so I am repeating my off-list reply to the list as well): > 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? > > 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. 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.... 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 __________________________

1 0

Severe regression in wine startup latencies
by Alan W. Irwin 30 Aug '11

30 Aug '11

The startup latency of commands run under wine-1.3.27 is much worse than it used to be. I did the following experiment with bash-3.1.17 that you get with the latest (mingw-get-inst-20110802.exe) MinGW/MSYS installer. wineconsole --backend=curses MinGW/msys/1.0/bin/bash.exe Then I ran the following commands within that MSYS bash environment. bash.exe-3.1$ which echo /z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe bash.exe-3.1$ time echo "hello" hello real 0m0.000s user 0m0.000s sys 0m0.000s This shows there is at least one command (echo) available under wine that executes with essentially zero latency. So the problem cannot be the time wine takes to read the executable file (/z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe in this case). But the rest of the commands I tried had latencies near 1 second. (I only report the second run in each case to make sure as much as possible is cached in memory for maximum speed.) bash.exe-3.1$ time bash --version GNU bash, version 3.1.17(1)-release (i686-pc-msys) Copyright (C) 2005 Free Software Foundation, Inc. real 0m0.905s user 0m0.160s sys 0m0.060s bash.exe-3.1$ time cmake-2.8.5-win32-x86/bin/cmake --version cmake version 2.8.5 real 0m0.922s user 0m0.080s sys 0m0.020s bash.exe-3.1$ time make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i686-pc-msys real 0m0.540s user 0m0.100s sys 0m0.020s bash.exe-3.1$ time gcc --version gcc.exe (GCC) 4.5.2 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. real 0m0.901s user 0m0.080s sys 0m0.040s Those are horrendous latencies. The last time I did such tests (for wine-1.3.9) the corresponding latency numbers were almost an order of magnitude better, and Linux latencies were two orders (!) of magnitude better than these. ==============Linux latency results here To prove those Linux latency results once again here are the corresponding results under Linux: wine(a)raven> which echo /bin/echo wine(a)raven> time echo "hello" hello real 0m0.000s user 0m0.000s sys 0m0.000s wine(a)raven> time bash --version GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. real 0m0.001s user 0m0.004s sys 0m0.000s wine(a)raven> time cmake --version cmake version 2.8.2 real 0m0.008s user 0m0.004s sys 0m0.008s wine(a)raven> time make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for x86_64-pc-linux-gnu real 0m0.001s user 0m0.004s sys 0m0.000s wine(a)raven> time gcc --version gcc (Debian 4.4.5-8) 4.4.5 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. real 0m0.001s user 0m0.000s sys 0m0.000s ==========End of Linux latency results I compiled wine-1.3.27 with -O3, and I run it with the wineserver turned on and export WINEDEBUG='fixme-all' Why is its command startup latency typically an order of magnitude worse than previous wine versions (1.3.9 is the one I previously tested in detail), and ~two orders of magnitude worse than the Linux case? Although startup latencies are not much of an issue if you are running just one command such as a game, they are a serious issue for those like me attempting to build software on the wine platform. I previously complained here about this issue for cmake-1.3.9 where cmake configuration and make commands were roughly 2-3 times slower than the corresponding Linux case because both commands execute _a lot_ of subcommands where latency delays accumulate like crazy. But now that the wine-1.3.27 latency is 10 times worse than in the 1.3.9 case, typical cmake configurations are something like 25 (!) times slower than the corresponding Linux command. What can be done to address this bad command-startup latency regression for wine? I would be happy to run any tests that might point to a solution. For example, I did run "top" from time to time while running the very long cmake configuration step, and the cpu's (I have a duo core system) were mostly idle indicating the latency bottleneck (whatever it is) does not involve excessive amounts of cpu time. However, wineserver was always high in the "top" list of commands that were grabbing the most cpu. If wine sets up a detailed GUI environment for every command it runs is there an easy way to turn that off in case that is the cause of the startup latency? (All the builds I want to do on the MinGW/MSYS/wine platform are strictly from the MSYS bash command line with no GUI required.) 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 __________________________

3 5

buildbot status
by Dan Kegel 29 Aug '11

29 Aug '11

The buildbot now uses ccache, which sped up builds tremendously. Cycle time of build slaves with ccache using is 10-11 minutes; the e8400 and q9300 are almost as fast as the i7 now. (Dunno about the celeron yet.) A few more flaky tests are now blacklisted, and the cluster has been running all afternoon without a glitch. I hope to turn on email notifications sometime this week.

3 6