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

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

by David Laight

On Mon, Aug 29, 2011 at 06:43:41PM -0700, Alan W. Irwin wrote: > double x; > while(fscanf(stdin, " %le ", &x) == 1) You are using the wrong format, %le is for 'long double', this will probably overwrite too much data. David -- David Laight: david(a)l8s.co.uk

Aug. 30, 2011

Re: d3dx9_36/tests: Fix printing a NULL string

by David Laight

On Tue, Aug 30, 2011 at 12:44:05PM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > 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?) Probably glibc, solaris was one of the first unix (I saw) to fault on accesses to address zero and certainly the current solaris libc will fault. David -- David Laight: david(a)l8s.co.uk

Aug. 30, 2011

Re: winelib an fpc

by Roderick Colenbrander

On Tue, Aug 30, 2011 at 9:43 AM, Paul Chitescu <paulc(a)voip.null.ro> wrote: > 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 > > > > I'm not sure what fpc allows. Perhaps it is possible (I'm not sure) to write a tiny C application with a main function which 'links' to your pascal code. That way (if possible) you would bootstrap Wine with a basic winelib application. Roderick

Aug. 30, 2011

WineHQ Maintenance.

by Jeremy Newman

We will be performing upgrades and maintenance to the WineHQ.org server starting at 1800 CDT on Wednesday August 31st. This process will take the server off-line for about an hour. The Websites (www,appdb,forums), and Mailing lists, and Git will be off-line during this period. -Newman

Aug. 30, 2011

Re: cmd/tests: Test del /s recursion in subdirectories with colons.

by Octavian Voicu

2011/8/30 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > 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. That's the whole point! I tested in cmd prompt on a Windows XP machine (and I assume all Windows versions act the same in this regard), and mkdir refuses to create a directory with colons in its name (same goes with explorer). Even if it might be possible to create a directory with a colon in its name by using some API, it's not relevant. So this test is strictly for Wine -- but it does have to pass on Windows too. The test I wrote is designed to fail (with a stack overflow) if you revert my earlier patch. It's not like any (sane) Windows application will be trying to create directories with colons in their names, but if it happens that the users has such a directory, you don't want Wine to go crashing because of it. > 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 I don't see the point of actually testing if the directory was created, because it will always fail on Windows (and you can't really mark this failure as broken, because it's standard Windows behavior). Octavian

Aug. 30, 2011

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

by Alexandre Julliard

Jérôme Gardou <jerome.gardou(a)laposte.net> writes: > Anyway, I've looked into this a bit, and it seems that the place to > write a proper test is rpcrt4 test suite. > While writing the test would per se be very easy, the problem won't > show up if -Oif isn't set on the tested idl file. Adding this to the > EXTRAIDLFLAGS variable in Makefile.in would do the trick, but I doubt > that this is what you want. Ultimately we'll want to use -Oicf there, but for now you can simply add the test without changing the Makefile, so that there's an easy way to see the problem. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2011

Re: cmd/tests: Test del /s recursion in subdirectories with colons.

by Frédéric Delanoy

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

Aug. 30, 2011

re: Severe startup latencies for Windows applications run under wine

by Dan Kegel

Try oprofile instead. ( A really old intro is at http://www.winehq.org/wwn/249#oprofile%20&%20Wine )

Aug. 30, 2011

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

by Jérôme Gardou

Le 30/08/2011 17:50, Jérôme Gardou a écrit : > 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. >> > Sorry, I forgot that the policy here was to reply after the previous mail. Anyway, I've looked into this a bit, and it seems that the place to write a proper test is rpcrt4 test suite. While writing the test would per se be very easy, the problem won't show up if -Oif isn't set on the tested idl file. Adding this to the EXTRAIDLFLAGS variable in Makefile.in would do the trick, but I doubt that this is what you want. Any hint on the way to proceed would be greatly appreciated. Regards. Jérôme

Aug. 30, 2011

Re: Severe startup latencies for Windows applications run under wine

by Octavian Voicu

On Tue, Aug 30, 2011 at 6:56 PM, Ben Peddell <klightspeed(a)netspace.net.au>wrote: > A modification of the timestamp patch from Bernhard Loos should help us > find what calls are taking the longest. > Speaking of that, I've been trying to compile cmd tests with profiling (-pg, for use with gprof), but no luck. I added -pg to both compile & link phases. Looking at disassembled .exe.so binary, it doesn't have the gprof code that a proper gprof executable would have, so I'm guessing winegcc does some magic that is not compatible with -pg. Anybody managed to make it work? Octavian

Aug. 30, 2011