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

hhctrl: IDTB_XXX resource strings
by Francois Gouget Aug. 31, 2011

Aug. 31, 2011

The native hhctrl.ocx does not have any resrouce strings. My understanding is that we have them in Wine because we use them as tooltips for the toolbar items. That's good I guess. However a number of them make no sense at all and are a pain to translate. For instance: IDTB_NOTES "IDTB_NOTES" IDTB_BROWSE_FWD "IDTB_BROWSE_FWD" IDTB_BROWSE_BACK "IDT_BROWSE_BACK" or IDTB_JUMP1 "Jump1" IDTB_JUMP2 "Jump2" What's the difference between 'Jump1' and 'Jump2'? Also I have found no proper documentation on this. So does anyone know what to put there so we have strings that correctly describe what these toolbar buttons do? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ question = ( to ) ? be : ! be; -- Wm. Shakespeare

2 6

Re: [PATCH 4/5] mountmgr.sys: Also unlink a:: drive when removing a dos device
by Alexandre Julliard Aug. 31, 2011

Aug. 31, 2011

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -818,6 +818,7 @@ NTSTATUS remove_dos_device( int letter, const char *udi ) > if ((path = get_dosdevices_path( &p ))) > { > p[0] = 'a' + drive->drive; > + unlink( path ); That's not done on purpose, to make it more likely that we use the same drive letter next time the device is mounted. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/5] kernel32: Add UDF support
by Alexandre Julliard Aug. 31, 2011

Aug. 31, 2011

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > Based on Steven Wallace work. > Should fix the wine side of bug #26273 It fails here: ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so volume.c && touch volume.ok volume.c:105: Tests skipped: can't test removing fake drive volume.c:359: Test failed: GetVolumeInformationA root failed, last error 66 volume.c:401: Test failed: GetVolumeInformationA with \ failed, last error 66 volume.c:423: Test failed: GetVolumeInformationA failed, last error 66 volume.c:434: Test failed: GetVolumeInformationA failed, last error 66 volume.c:445: Test failed: GetVolumeInformationA failed, root=C:\, last error=66 volume.c:451: Test failed: GetVolumeInformationA did fail, root=\\?\C:\, last error=66 volume.c:458: Test failed: GetVolumeInformationA did fail, root=\\.\C:\, last error=66 volume.c:486: Test failed: GetVolumeInformationA failed, root=\\?\Volume{00000000-0000-0000-0000-000000000043}\, last error=66 make[1]: *** [volume.ok] Error 8 -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 3/5] kernel32: Improve GetVolumeInformation filesystem flags
by Alexandre Julliard Aug. 31, 2011

Aug. 31, 2011

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > if (fsname) lstrcpynW( fsname, ntfsW, fsname_len ); > if (filename_len) *filename_len = 255; > - if (flags) *flags = FILE_CASE_PRESERVED_NAMES; > + if (flags) *flags = FILE_NAMED_STREAMS | FILE_SUPPORTS_ENCRYPTION | FILE_SUPPORTS_OBJECT_IDS > + | FILE_SUPPORTS_REPARSE_POINTS | FILE_SUPPORTS_SPARSE_FILES | FILE_VOLUME_QUOTAS > + | FILE_FILE_COMPRESSION | FILE_PERSISTENT_ACLS | FILE_UNICODE_ON_DISK > + | FILE_CASE_PRESERVED_NAMES | FILE_CASE_SENSITIVE_SEARCH; I'm not sure it's a good idea to claim features we don't support. Do you have an app that needs this? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: user32: fix potential crash when loading unsupported files (with tests) (try 2) (resend)
by Alexandre Julliard Aug. 31, 2011

Aug. 31, 2011

Vitaly Perov <vitperov(a)etersoft.ru> writes: > @@ -1238,6 +1260,12 @@ static void test_LoadImage(void) > test_LoadImageFile("JPG", jpgimage, sizeof(jpgimage), "jpg", 0); > test_LoadImageFile("PNG", pngimage, sizeof(pngimage), "png", 0); > > + /* Corrupted images */ > + test_LoadCorruptedImageFile("corrupted_BMP", bmpimage, sizeof(bmpimage), "bmp", 1); > + test_LoadCorruptedImageFile("corrupted_GIF", gifimage, sizeof(gifimage), "gif", 0); > + test_LoadCorruptedImageFile("corrupted_JPG", jpgimage, sizeof(jpgimage), "jpg", 0); > + test_LoadCorruptedImageFile("corrupted_PNG", pngimage, sizeof(pngimage), "png", 0); > + That's an interesting test, but it has nothing to do with your fix. We shouldn't crash on loading corrupted files, but we shouldn't crash if idReserved is 0 either. Your proposed fix is just hiding the problem. Checking idReserved may or may not be a good idea, independently of fixing that crash, but that would need a different test. -- Alexandre Julliard julliard(a)winehq.org

1 0

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

Aug. 31, 2011

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 Aug. 31, 2011

Aug. 31, 2011

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 Aug. 31, 2011

Aug. 31, 2011

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 Aug. 31, 2011

Aug. 31, 2011

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 Aug. 31, 2011

Aug. 31, 2011

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 Aug. 30, 2011

Aug. 30, 2011

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 Aug. 30, 2011

Aug. 30, 2011

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 Aug. 30, 2011

Aug. 30, 2011

>>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 Aug. 30, 2011

Aug. 30, 2011

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 Aug. 30, 2011

Aug. 30, 2011

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

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

Aug. 30, 2011

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 Aug. 30, 2011

Aug. 30, 2011

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 Aug. 30, 2011

Aug. 30, 2011

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 Aug. 30, 2011

Aug. 30, 2011

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 Aug. 30, 2011

Aug. 30, 2011

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 Aug. 30, 2011

Aug. 30, 2011

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 Aug. 30, 2011

Aug. 30, 2011

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 Aug. 30, 2011

Aug. 30, 2011

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 Aug. 30, 2011

Aug. 30, 2011

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 Aug. 29, 2011

Aug. 29, 2011

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