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

Re: kernel32/tests: test that GetModuleFileName returns an absolute path

by Dmitry Timoshkov

Thomas Faber <thfabba(a)gmx.de> wrote: > diff --git a/dlls/kernel32/tests/Makefile.in b/dlls/kernel32/tests/Makefile.in > index dce27db..2ce3ec6 100644 > --- a/dlls/kernel32/tests/Makefile.in > +++ b/dlls/kernel32/tests/Makefile.in > @@ -1,5 +1,5 @@ > TESTDLL = kernel32.dll > -IMPORTS = user32 advapi32 > +IMPORTS = user32 advapi32 shlwapi Adding a shlwapi dependency to the kernel32 test suite is not a good idea, please find a way to avoid it. -- Dmitry.

Dec. 25, 2011

Re: kernel32/tests: test that GetModuleFileName returns an absolute path

by Thomas Faber

On 2011-12-25 17:12, Dmitry Timoshkov wrote: > Thomas Faber <thfabba(a)gmx.de> wrote: > >> diff --git a/dlls/kernel32/tests/Makefile.in b/dlls/kernel32/tests/Makefile.in >> index dce27db..2ce3ec6 100644 >> --- a/dlls/kernel32/tests/Makefile.in >> +++ b/dlls/kernel32/tests/Makefile.in >> @@ -1,5 +1,5 @@ >> TESTDLL = kernel32.dll >> -IMPORTS = user32 advapi32 >> +IMPORTS = user32 advapi32 shlwapi > > Adding a shlwapi dependency to the kernel32 test suite is not a good idea, > please find a way to avoid it. Hmm okay. I'll just use strchr(path, '\\') as a substitute for PathIsRelative then, though that's not as accurate of course. Thanks. -Tom

Dec. 25, 2011

Re: [PATCH RFC 5/5] dsound: convert from fixed to floating point

by Chris Robinson

On Saturday, December 24, 2011 9:20:38 PM Alexander E. Patrakov wrote: > Andrew Eikum converted the buffer position calculation code from fixed > point to floating point, because floating-point code is more readable. > I agree with him. FWIW, I'm not sure using floating point for the position index is that good of an idea since it needs to be converted to integer all the time. Float-to-int conversions are very slow because it involves reading the FPU control word, setting a new control word with the proper rounding mode (which takes several cycles), storing the float value as an integer, then setting the old control word back (which again takes several cycles). It does this every time a float gets converted to an int, and does something similar when you truncate/floor the float value. In addition, you have potential rounding errors caused by precision loss as the exponent gets larger. Fixed-point doesn't have this issue since the precision is fixed, and the result will always be consistent. E.g., val + step*3 == val + step + step + step is true with fixed-point, but may not be true with floating-point and can result in a value that's larger or smaller than you expect. In some circumstances, it could even cause you to read past the end of the buffer. If you're concerned about cleanliness, perhaps some simple inline functions could be used to hide the bit-manipulation.

Dec. 25, 2011

Re: DIB crash with gdb

by Marcus Meissner

On Fri, Dec 23, 2011 at 11:56:35PM -0600, Ken Thomases wrote: > > On Dec 23, 2011, at 3:10 PM, Michael Ost wrote: > > > This all makes sense, and pulls the code together for me. Thanks! > > You're welcome. > > > I assume this is a recent development, because I was successfully using gdb with our last wine version - 1.1.7. > > Nope. This is how it has worked for a long, long time. Don't know what else has changed. Maybe some of the other work on the DIB engine has changed whether/when the DIB accesses cause access violations that you're seeing. Yes, the DIB engine should no longer let this happen with the last 1.3. releases since around September or so. Otherwise, in gdb you can type "pass" to pass the signal on to the program. Ciao, Marcus

Dec. 25, 2011

Re: [PATCH RFC 5/5] dsound: convert from fixed to floating point

by Alexander E. Patrakov

"Alexander E. Patrakov" <patrakov(a)gmail.com> wrote: > "Alexander E. Patrakov" <patrakov(a)gmail.com> wrote: > > > Andrew Eikum converted the buffer position calculation code from > > fixed point to floating point, because floating-point code is more > > readable. I agree with him. > > > > I am not sending further patches out, because it is not yet clear > > which of the two proposed patchsets for bug 14717 will be the final > > one. Anyway, both of the approaches depend on all the patches that I > > sent today. > > > > Please ignore this patch for now, it has at least one bug. Please ignore the "ignore", I need some coffee. -- Alexander E. Patrakov

Dec. 25, 2011

Re: [PATCH RFC 5/5] dsound: convert from fixed to floating point

by Alexander E. Patrakov

"Alexander E. Patrakov" <patrakov(a)gmail.com> wrote: > Andrew Eikum converted the buffer position calculation code from fixed > point to floating point, because floating-point code is more readable. > I agree with him. > > I am not sending further patches out, because it is not yet clear > which of the two proposed patchsets for bug 14717 will be the final > one. Anyway, both of the approaches depend on all the patches that I > sent today. > Please ignore this patch for now, it has at least one bug. - freqAcc += adj; - adv = (freqAcc >> DSOUND_FREQSHIFT); - freqAcc &= (1 << DSOUND_FREQSHIFT) - 1; - ipos += adv * istride; + freqAcc += dsb->freqAdjust; + ipos += ((DWORD)freqAcc) * istride; + freqAcc -= truncf(freqAcc); The last line of this hunk is wrong, should be "=", not "-=". -- Alexander E. Patrakov

Dec. 25, 2011

Re: Status of DIB engine ?

by Massimo Del Fedele

Il 24/12/2011 08:59, Alexandre Julliard ha scritto: > Massimo Del Fedele<max(a)veneto.com> writes: > >> So, the question : have I understood right from changelogs and text is completed >> in DIB engine, so I can help to make it a bit faster, or it's still missing >> something so I should just wait ? > > Text is done. Most likely Autocad is using some other call that still > goes through X11. You should be able to see this in debug traces. > Hi Alexander, that's weird, because when I developed the former engine, I solved the slowness just when I introduced text output. Anyways, I'll try to look at logs if I can find the problem. Max

Dec. 24, 2011

Re: Status of DIB engine ?

by Alexandre Julliard

Massimo Del Fedele <max(a)veneto.com> writes: > So, the question : have I understood right from changelogs and text is completed > in DIB engine, so I can help to make it a bit faster, or it's still missing > something so I should just wait ? Text is done. Most likely Autocad is using some other call that still goes through X11. You should be able to see this in debug traces. -- Alexandre Julliard julliard(a)winehq.org

Dec. 24, 2011

Re: DIB crash with gdb

by Ken Thomases

On Dec 23, 2011, at 3:10 PM, Michael Ost wrote: > This all makes sense, and pulls the code together for me. Thanks! You're welcome. > I assume this is a recent development, because I was successfully using gdb with our last wine version - 1.1.7. Nope. This is how it has worked for a long, long time. Don't know what else has changed. Maybe some of the other work on the DIB engine has changed whether/when the DIB accesses cause access violations that you're seeing. > But it no longer sounds workable to use gdb for debugging winelib applications, which is a drag. Are you suggesting using winedbg instead? Well, you can use winedbg with $BreakOnFirstChance set to 0, for some apps. (Setting $BreakOnFirstChance to 0 only has to be done once for a given WINEPREFIX. It's saved in the registry.) You can also try that "handle SIGSEGV nostop noprint pass" command I gave you. You might try starting with that signal-handling setup and then, when you get close to where you expect a true crash to happen, switch it back ("handle SIGSEGV stop print nopass"). Some day, the DIB engine will be complete and this memory protection scheme will not be necessary to coordinate DIB access between memory and the X server. > Do you know if it can be used as a drop-in replacement in, say, Qt Creator (which is my IDE of choice)? No, it can't. Its interface is not identical to gdb's. Regards, Ken

Dec. 24, 2011

Re: Mac OS X specific bugs

by Damjan Jovanovic

On Fri, Dec 23, 2011 at 7:11 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > > Also, there's one thing that has annoyed me for months. Since one of > Damjan Jovanovic's patches, my /tmp/ directory gets spammed with .icons > files, thousands of them after some time. IIRC on Linux, it's always > the same .desktop files that are recreated, so it doesn't matter. I > once wrote a private patch to restore Linux behavior on Mac, because I've > described in the Wiki's Mac FAQ how to turn these .desktop into .command > files with icons. > IIRC the discussion at the time was that making an application bundle is better than .command files with icon resource forks. Sorry I haven't gotten to completing the Mac support for Winemenubuilder yet - it seems that I'd have to use various MacOS APIs, and I don't even have access to a Mac. > Happy new year, > Jörg Höhle > Happy new year Damjan

Dec. 24, 2011