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

Re: Severe startup latencies for Windows applications run under wine

by Ben Peddell

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/

Aug. 30, 2011

Re: widl: duplicate type in case of argument with range attribute

by Jérôme Gardou

Hello. Maybe the comment isn't clear enough. The ranges are correctly output into the format string, but the offset of each output is lost during the processing. For instance, declaring a function like this one : DWORD Test( [in, range(0, 1024)] DWORD dwParam1, [in, range(0, 255)] DWORD dwParam2); would output both parameter declarations into the type format string with correct range values, but the offsets into the procedure format string would both point to the last one. I'll try to write a test to show this behaviour, but I'm not sure of how to integrate this in wine test suite. Note : this problem manifests itself when -Oif flag is enabled. Regards. Jérôme. Le 30/08/2011 12:46, Alexandre Julliard a écrit : > 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. >

Aug. 30, 2011

Re: RFC - ws2_32/socket.c: SIO_KEEPALIVE_VALS vs TCP_KEEPIDLE/TCP_KEEPINTVL

by Juan Lang

Hi Bruno, > 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 Yes, it's reasonable. I think API-level compatibility is generally more important to appilcations than timing-level compatibility. I.o.w. function(args) -> result should be invariant across Windows and Wine. The time required to before function(args) yields result is oftentimes not guaranteed in Windows, so a little fuzziness here is often okay. --Juan

Aug. 30, 2011

Re: wineview: Rename view to wineview and install it

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > 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. Nobody is suggesting that this would go in /usr/bin. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2011

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

by Dan Kegel

> 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 - Dan

Aug. 30, 2011

re: wineview: Rename view to wineview and install it

by Dan Kegel

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

Aug. 30, 2011

Re: Testing edge cases and undocumented behavior

by Scott Ritchie

On 08/30/2011 04:05 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > For instance, Scott Ritchie's example is not unusual: > + * If lpszStr is Null, returns how long a formatted string would be. > This is a very common pattern. Probably MSDN forgot to mention it. > Expect apps to use that when they find out it works. > In this particular case, MSDN does mention it, however it doesn't mention all the testable behavior such as exactly when the buffer isnt modified. This is why once we test exhaustively like this our own API docs end up being better than MSDN itself. Incidentally, the tests themselves are very informative example code, and if we were trying to create a resource for developers like MSDN they'd probably have a place there. > What I don't understand about Scott's patches is why there's half a > dozen of them. One patch for the code, one for the tests about > StrFromTimeInterval, possibly even join them. > A little birdie told me that Alexandre likes small incremental patches, so I provided each test in the small increment that I noticed their need in. It does seem like the sort of thing I should combine in the future though. Thanks, Scott Ritchie

Aug. 30, 2011

Re: [4/6] ddraw: Convert dwZBufferBitDepth into a DDPIXELFORMAT (try 2)

by Henri Verbeet

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);".

Aug. 30, 2011

RFC - ws2_32/socket.c: SIO_KEEPALIVE_VALS vs TCP_KEEPIDLE/TCP_KEEPINTVL

by Bruno Jesus

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

Aug. 30, 2011

Testing edge cases and undocumented behavior

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Michael Stefaniuc wrote: >What you do want to test is: >- the de jure API (as documented), and >- the de facto API (as used by applications You plead for operational profile testing. I say that the API "as used by applications" is unknown to me because the 100000 apps out there don't send me email about their API usage. So I'm left with extremely few apps to test, and my judgement. My judgement tells me to complete your list: - the expected corner cases of the API or the programming language. + e.g. buffer sizes 0 or even < 0 with C + reference counts with COM + class inheritance with C++ For instance, Scott Ritchie's example is not unusual: + * If lpszStr is Null, returns how long a formatted string would be. This is a very common pattern. Probably MSDN forgot to mention it. Expect apps to use that when they find out it works. What I don't understand about Scott's patches is why there's half a dozen of them. One patch for the code, one for the tests about StrFromTimeInterval, possibly even join them. >An extreme case would be to try to test how much time/CPU cycles a >function call takes and trying to replicate that in Wine. >In general that doesn't matter but is is observable and testable. I have audio in mind so I don't care about "in general". With audio, it matters, as seen in the MS compatibility kit: http://technet.microsoft.com/en-us/library/cc766308%28WS.10%29.aspx See IgnoreMCISTOP. Complete the list further: - the timing of the audio API - the timing of events (e.g. mmdevapi EVENTCALLBACK) and - the timing and invoking thread of callbacks (bugs #3930, 27795) Actually, I've been thinking about performing timing tests of the mmdevapi Start and Stop methods. One noteworthy point is that I *may* perform such tests to validate my beliefs about how mmdevapi works (e.g. is it so fast as if it solely flips a bit polled by the timer job?), but that does not necessarily imply that I'll add tests to the source. I've performed many more tests than you'll eventually find in tests/. Regards, Jörg Höhle

Aug. 30, 2011