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

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

by Alexandre Julliard

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

Aug. 30, 2011

d3dx9_36/tests: Fix printing a NULL string

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

André Hentschel suggested: >Should stop the crash on Solaris and maybe others >- trace("parent_data = (%p) -> %s\n", parent_data, (char *)parent_data); >+ trace("parent_data (%p) -> %s\n", parent_data, parent_data ? (char *)parent_data : "(null)"); This is sooo backwards. You don't want to try and find all places where (null) may be printed. I remember seeing (null) in logs here and there, so you're telling us that turning on Wine logs in Solaris can randomly crash Wine because it crashes on printf("%s", NULL)? I'm very surprised. I thought Solaris was one of the first machines - decades ago - where I observed "(null)" for NULL. (Or is that really glibc only?) Regards, Jörg Höhle

Aug. 30, 2011

Re: wineview: Rename view to wineview and install it

by Alexandre Julliard

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

Aug. 30, 2011

Re: [PATCH 2/3] vbscript: Added SetScriptSite tests

by Jacek Caban

On 08/30/11 11:43, Marvin wrote: > 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. > Please ignore tests patch. I will resend it once our implementation will be sufficiently complete. Other two patches should be good to go. Jacek

Aug. 30, 2011

Re: [PATCH 2/3] vbscript: Added SetScriptSite tests

by Marvin

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

Aug. 30, 2011

Re: winelib an fpc

by Paul Chitescu

On Tuesday 30 August 2011 01:57:30 am Reinier Napoles Martinez wrote: > >>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 Essentially what you need to do is to write your application as a winelib application. That means it will have a code similar to a Win32 EXE but will be in ELF format. I have no idea if/how you can do that using fpc. An alternative would be to write a winelib proxy program and talk to it through a socket or some other form of IPC. Finally, if your application depends too much on some DLL (especially things you cannot easily proxy like graphics) just make it a Win32 EXE. Paul

Aug. 30, 2011

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

by Stefan Dösinger

On Monday 29 August 2011 21:54:52 Stefan Dösinger wrote: > Technically that's true for this specific function since the result is only > used by our code and never the application. Yet I prefer to keep the > memset for consistency with other code that handles DDSURFACEDESC(2) > structures. I tried to change the clear value to 0xff instead of 0x00 and got test failures. So it looks like we have buggy code somewhere else. I'm investigating.

Aug. 30, 2011

Re: [PATCH 1/5] cmd/tests: add more tests for command line parsing

by Frédéric Delanoy

On Tue, Aug 30, 2011 at 00:34, Martin Wilck <mwilck(a)arcor.de> wrote: > This patch adds some tests for command line parsing and treatment > of quotes and special characters in the command line and in program > names and parameters. The .exp file was created using Win XP. > Follow-up patches will fix the marked TODOs. > --- > programs/cmd/tests/rsrc.rc | 6 + > programs/cmd/tests/test_parsing.cmd | 158 +++++++++++++++++++++++++++++++ > programs/cmd/tests/test_parsing.cmd.exp | 77 +++++++++++++++ > 3 files changed, 241 insertions(+), 0 deletions(-) > create mode 100644 programs/cmd/tests/test_parsing.cmd > create mode 100644 programs/cmd/tests/test_parsing.cmd.exp Some of those tests are already present in the test_builtins.cmd* (e.g. the spacing tests) You should probably integrated your tests in there: that makes it easier to spot regressions and helps prevent tests duplication Also, see http://www.winehq.org/pipermail/wine-devel/2011-August/091817.html Frédéric Delanoy

Aug. 30, 2011

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

by Frédéric Delanoy

2011/8/30 Octavian Voicu <octavian.voicu(a)gmail.com>: > 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... %CD% indeed doesn't work on NT4, and there is a test for that already IIRC. You can circumvent that with @pwd@ (starting path) [just using "cd" is equivalent to "echo %cd%" and works everywhere] An interesting test would be to use stuff like C:foo or Z:\foo for regressions (or more portably @drive@) Also don"t put stuff like "ECHO is off" in expected file, that's not portable on non-English locales You can use quotes, like e.g. echo 'whatever' Frédéric

Aug. 30, 2011

Severe startup latencies for Windows applications run under wine

by Alan W. Irwin

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 __________________________

Aug. 30, 2011