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

Re: oleaut32: Indentation Fix
by Alexandre Julliard Dec. 20, 2012

Dec. 20, 2012

Andrew Talbot <andrew.talbot(a)talbotville.com> writes: > Changelog: > oleaut32: Indentation Fix. Please avoid reformatting hundreds of lines for no reason. Only fix the parts where the indentation is actually incorrect. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: windowscodecs: Adjust a type in PngDecoder_Frame_GetColorContexts.
by Alexandre Julliard Dec. 19, 2012

Dec. 19, 2012

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > Current snapshots of GCC 4.8.0 issue a warning about some of the > new code in windowscodecs/pngformat.c: > > pngformat.c: In function 'PngDecoder_Frame_GetColorContexts': > pngformat.c:882:5: warning: passing argument 5 of 'ppng_get_iCCP' from > incompatible pointer type [enabled by default] > if (ppng_get_iCCP(This->png_ptr, This->info_ptr, &name, &compression_type,&profile, &len)) > pngformat.c:882:5: note: expected 'png_bytepp' but argument is of type 'char **' > > The patch below addresses this. That will break on older libpng. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 0/5] Moving bare consoles to wineconsole (try #2)
by Alexandre Julliard Dec. 19, 2012

Dec. 19, 2012

Eric Pouech <eric.pouech(a)orange.fr> writes: > The following series implements a new scheme for managing 'bare' consoles. > We now force every program started without a wine parent to be run under > wineconsole (transparently for the user). > This is done using a new backend in wineconsole called 'line'. This backend > only takes care of input; output is kept as a client side operation. > All terminal related code is moved from dlls/kernel32 to programs/wineconsole. > > This basically ensures that: > - Only wineconsole reads from standard input (and writes into input queue). > This fixes bug reported by Jason when $CONIN is opened with read access only. > - It also enforces that wineconsole always has control of the unix terminal, > hence ensuring that we properly reset the terminal settings upon exit. > > Code looks way cleaner now. > > Try #2 (changes from previous patch) > - fix changelog of first patch (was WineHelp...) > - fix date in header for new file > - remove setting title code (will be fixed in later patch) Actually the problem is not only the title. For instance it's still sending escape sequences when stdout is redirected. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: wininet: Map socket errors to ERROR_INTERNET_CANNOT_CONNECT in create_netconn_socket.
by Marvin Dec. 19, 2012

Dec. 19, 2012

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=23542 Your paranoid android. === W7PRO (32 bit http) === http.c:3337: Test failed: HttpSendRequest failed: 12002

2 1

Re: dsound: change mix rate of primary buffer
by Andrew Eikum Dec. 18, 2012

Dec. 18, 2012

On Tue, Dec 18, 2012 at 08:08:03PM +0100, sebastien chev wrote: > Thank you for the tips. I will look at these. > I guess you're probably also thinking about the mix buffer in dsound itself. That does always mix to float, and there isn't a way to change it right now. What are you planning to use this for? We could support different mix buffer formats, but I'm not sure this use case is worth the effort. Andrew

1 0

Clang static analyzer results / wine-1.5.19-186-g1cd0c4a
by Austin English Dec. 18, 2012

Dec. 18, 2012

Now that http://source.winehq.org/git/wine.git/commitdiff/4adfb787f4e8c36a37ce1d53a7… is in (and clang has improved), several wine/clang bugs are fixed. For those curious, there is one remaining test failure on my machine, with clang instead of gcc: http://bugs.winehq.org/show_bug.cgi?id=25828 The static analyzer results were made with: llvm: git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk(a)170295 91177308-0d34-0410-b5e6-96231b3b80d8 clang: git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk(a)170294 91177308-0d34-0410-b5e6-96231b3b80d8 wine: wine-1.5.19-186-g1cd0c4a ./configure --disable-tests was used to reduce noise austin(a)debian-home:~$ du -h wine-1.5.19-186-g1cd0c4a.tar.bz2 39M wine-1.5.19-186-g1cd0c4a.tar.bz2 austin(a)debian-home:~$ sha1sum wine-1.5.19-186-g1cd0c4a.tar.bz2 bf86469ab3929faf996b76d4a8e533edcf24fd29 wine-1.5.19-186-g1cd0c4a.tar.bz2 Available at http://www.mediafire.com/?0gioifbgw363az3 -- -Austin

1 0

winealsa: Separate read and write pointers.
by Joerg-Cyril.Hoehle＠t-systems.com Dec. 18, 2012

Dec. 18, 2012

Andrew Eikum wrote: >This [lock-less] seems to be the main goal of the patch. It'll not be bad to fix the capture bug independently. >and maybe we can get that into Wine after the next release? That requires agreement on the lock-less protocol. Basis: atomic 32bit updates. Do we want distinguished alignment declarations for e.g. This->held_frames? Write: InterlockedExchange/Increment/etc. is clear Read: Open for discussion Basically, all I need is a snapshot of a 32bit entity, i.e. an atomic read. The code doesn't bother whether that value is stale or not. It works in either case. All that is required is that it's updated some time eventually (i.e. not running off local cache for hours). Back in the old days, people used foo = (volatile X) bar; or even volatile X bar; ... foo=bar; Such code has been present e.g. in mciseq for the last 10 years. Currently, this has my preference for Intel: foo = bar; // e.g. held = This->held_frames; __asm__ __volatile__("":::"memory"); /* compiler barrier is enough for x86 */ I wouldn't be opposed to held = (volatile DWORD) This->held_frames; Purists spit at volatile for threading, but that's what has been used for decades and continues to be used (just google some random threading app...) I've also suggested InterlockedExchange(&held, This->held_frames) but that's just wasting a read of the obsolete value of held. So why use that form? Do we need to care for anything else than Intel? One may envision other approaches, e.g. a second critical section for the callback and Start/Stop only. But This->held_frames is updated within IAC_Get/ReleaseBuffer, so that doesn't solve the issue. POSIX purists would say that a protocol is needed between the two communicating threads (the Get/Release one and the cb, not the Start/Stop thread). But I don't care about POSIX requirements imposed by weird 8/16/24/32/40/64 bit HW and strange non-UNIX systems when the target is Wine-Is-Not-an-Emulator. Regards, Jörg Höhle

1 0

Re: winealsa: Separate read and write pointers.
by Andrew Eikum Dec. 18, 2012

Dec. 18, 2012

On Mon, Dec 17, 2012 at 05:01:29PM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Furthermore, this patch eases integration of my lock-less code, which > I'll not release for now, by cleanly separating read and write > pointers during playback and capture. No more adding of two volatile > entities moving in opposite directions! > This seems to be the main goal of the patch. I tested it against my usual set of applications both with and without PulseAudio. This patch seems fine to me. I'll take a look at your lockless patch on bug 29531, and maybe we can get that into Wine after the next release? Andrew

1 0

dsound: change mix rate of primary buffer
by sebastien chev Dec. 18, 2012

Dec. 18, 2012

It seems that no matter what the Windows side program choose for DirectSoundCreate, the DSound subsystem initialize itself with the higher spec sound available (for example 48Khz Float32, or 48kHz Int16 if no Float32 available). While not a big deal on current linux PC, using this on ARM device kill performance. A DirectSound subsystem for ARM, with Integer only for the mixbuffer (as most ARM still use softfloat) and 22kHz should be less taxing for performances.

2 1

Re: mmdevapi: Prevent race condition upon Start.
by Alexandre Julliard Dec. 18, 2012

Dec. 18, 2012

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > What happened every so often, even on a single-core machine(!), is > that CreateTimerQueue(dueTime=0=immediate) would see the timer thread > created and the callback invoked before the function returns. Since > This->started was not set yet, our callback would return immediately, > in effect causing sound to start only one 10ms period later. > That's obviously was not intended by the author. > So let's set This->started before CTQ. This doesn't make sense, there's a critical section. -- Alexandre Julliard julliard(a)winehq.org

2 1