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

Re: Severe regression in wine startup latencies

by Ben Peddell

On 29/08/2011 2:37 AM, Alan W. Irwin wrote: > While I am doing those additional investigations, please consider > the question of why there is a huge difference between built-in and > executable latency for MSYS bash commands under wine. To start > that investigation it would be good to compare the wine results > for those two cases with the Windows results for those two cases. > (I assume the two time results for built-in versus executable will > be fairly similar in the Windows case, but that assumption needs to > be checked.) I don't have access to Windows myself. Anybody up for > doing that simple test and reporting the results back here? The > automatic MinGW/MSYS installer at > http://sourceforge.net/projects/mingw/files/Automated MinGW > Installer/mingw-get-inst/ makes it easy to install the relevant > MinGW/MSYS software on both wine and Windows. 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 execute a program. * make.exe takes about 8.8ms to execute a program. * cmd.exe takes about 5.9ms to execute a program. Under wine 1.2.1 on linux 2.6.38 on an AMD 5050e: * bash.exe takes about 236ms to execute a program. * bash.exe takes about 182ms to execute ${MINGW}/bin/true. * make.exe takes about 77ms to execute a program. * make.exe takes about 25ms to execute ${MINGW}/bin/true. * wine-cmd takes about 9ms to execute a program. Under wine-git on linux 2.6.38 on an AMD 5050e: * bash.exe takes about 190ms to execute a program. * bash.exe takes about 147ms to execute ${MINGW}/bin/true. * make.exe takes about 71ms to execute a program. * make.exe takes about 20ms to execute ${MINGW}/bin/true. * wine-cmd takes about 9ms to execute a program. 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. Times have actually improved between 1.2 and current. -- Ben Peddell IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools http://klightspeed.killerwolves.net/

Aug. 30, 2011

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

by Alan W. Irwin

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 __________________________

Aug. 30, 2011

Re: cmd: Don't parse colons as stream separators when splitting paths.

by Octavian Voicu

2011/8/29 Octavian Voicu <octavian.voicu(a)gmail.com> > Alexandre already committed the patch, so if native passes the test I can > send a test for the next iteration. On the other hand, if native chokes on > the colon, then we shouldn't add any testcases. If it works, might also > throw a @pwd@ in there. > I've got the results, see [2]. I tried doing cd to a foo:bar directory, but it fails on Windows. Not sure what's with all the extra failures, but except tests on NT (where %cd% is broken) the second %cd% shows that either the directory was not created, or cd failed to that directory. I guess we could throw in the test without the echo %cd% part, but I'm not sure if it wouldn't affect subsequent tests -- if cd fails, then cd .. will go one level upper. Not sure if the test is worth the trouble... Octavian [2] https://testbot.winehq.org/JobDetails.pl?Key=13828

Aug. 30, 2011

Re: buildbot status

by Dan Kegel

2011/8/29 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: >> - buildbot currently explodes while attaching patches to status >> emails if the patch contains a non-ascii character, >> http://trac.buildbot.net/ticket/2091 >> (I'll probably work around this by disabling the attachment.) > > Alternatively, avoid attaching patches containing .po or .rc files The patch that caused the problem choked on the first line, From: name-with-accent So it's not just .po files that cause the problem. I've disabled the attachment code, and am tweaking the message formatting now. Apologies for spamming patch authors with buildbot status results... the current buildbot crashes if you don't send results to the author, or I'd disable the messages. - Dan

Aug. 29, 2011

Re: buildbot status

by Frédéric Delanoy

On Mon, Aug 29, 2011 at 23:41, Dan Kegel <dank(a)kegel.com> wrote: > On Sun, Aug 28, 2011 at 8:53 PM, Dan Kegel <dank(a)kegel.com> wrote: >> I hope to turn on email notifications sometime this week. > > Buildbot is now sending email on failure. There are two caveats: > - it's emailing directly from a cable modem, not using an smtp relay, > so some mail systems may think it's spam > - buildbot currently explodes while attaching patches to status > emails if the patch contains a non-ascii character, > http://trac.buildbot.net/ticket/2091 > (I'll probably work around this by disabling the attachment.) Alternatively, avoid attaching patches containing .po or .rc files

Aug. 29, 2011

Re: winelib an fpc

by Reinier Napoles Martinez

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

Aug. 29, 2011

Re: winelib an fpc

by Steven Edwards

On Mon, Aug 29, 2011 at 2:05 PM, Reinier Napoles Martinez <rnapoles(a)hlg.uci.cu> wrote: > lib:=dlopen('/usr/lib/wine/user32.dll.so',1); This won't work. Simply doing a dlopen on the wine libraries won't get your environment setup properly. -- 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. 29, 2011

Re: buildbot status

by Dan Kegel

On Sun, Aug 28, 2011 at 8:53 PM, Dan Kegel <dank(a)kegel.com> wrote: > I hope to turn on email notifications sometime this week. Buildbot is now sending email on failure. There are two caveats: - it's emailing directly from a cable modem, not using an smtp relay, so some mail systems may think it's spam - buildbot currently explodes while attaching patches to status emails if the patch contains a non-ascii character, http://trac.buildbot.net/ticket/2091 (I'll probably work around this by disabling the attachment.) Future status updates will go to http://wiki.winehq.org/BuildBot - Dan

Aug. 29, 2011

winelib an fpc

by Reinier Napoles Martinez

best regards I would like to know if it is possible to use the wine libraries with freepascal compiler. kylix had a modified version of the wine libraries and I believe that it was possible to invoke them from pascal. I've tried several ways but all I get is "segment fault". sorry for my English. Thanks. program test01; {$MODE Delphi} uses types; Type BOOL = LongBool; function GetCursorPos(var lpPoint: TPoint): BOOL; stdcall; external 'libuser32.so' name 'GetCursorPos'; var a:Tpoint; begin WriteLn('Calling wine function'); GetCursorPos(a); WriteLn('End Calling wine function'); WriteLn(a.x); end. program test02; {$Mode Delphi} uses sysutils,types; Type BOOL = LongBool; TGetCursorPos=Function(var lpPoint: TPoint): BOOL;cdecl; Function dlopen(name: pchar;mode: longint):pointer;cdecl;external 'dl'; Function dlsym(lib: pointer; name: pchar):pointer;cdecl;external 'dl'; Function dlclose(lib: pointer):longint;cdecl;external 'dl'; var lib : pointer; GetCursorPos:TGetCursorPos; a:Tpoint; begin lib:=dlopen('/usr/lib/wine/user32.dll.so',1); if lib <> nil then @GetCursorPos:=dlsym(lib,'GetCursorPos') else begin WriteLn('library not loaded'); exit; end; if Assigned(GetCursorPos) then begin WriteLn('Calling GetCursorPos'); Try GetCursorPos(a); Except on E : Exception do WriteLn(E.Message); end; WriteLn('X:',a.x,' Y:',a.Y); end else begin WriteLn('function not loaded'); exit; end; dlclose(lib); end. -- ********************************************************************* 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 ********************************************************************* -- ********************************************************************* 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 *********************************************************************

Aug. 29, 2011

Re: [1/5] ddraw: Introduce a function to convert a DDSURFACEDESC to a DDSURFACEDESC2

by Stefan Dösinger

On Monday 29 August 2011 19:40:13 Henri Verbeet wrote: > 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. Well, the clear is part of the code that writes to the structure. The rest of the code only writes members that are set in the source DDSURFACEDESC.

Aug. 29, 2011