Re: [PATCH 1/3] extrac32: Implement more strict command line processing.

2013-03-28 Thread Sergey Guralnik
On 2013-03-26 10:17, Sergey Guralnik wrote: Is some problem with this series? -- Sergey

Re: secur32: Take schannel backend capabilities into account when configuring enabled protocols.

2013-03-28 Thread Juan Lang
On Thu, Mar 28, 2013 at 12:31 PM, Ken Thomases wrote: > On Mar 28, 2013, at 6:05 AM, Jacek Caban wrote: > > > --- a/dlls/secur32/schannel_macosx.c > > +++ b/dlls/secur32/schannel_macosx.c > > @@ -630,6 +630,11 @@ static OSStatus schan_push_adapter(SSLConnectionRef > transport, const void *buff, >

Re: secur32: Take schannel backend capabilities into account when configuring enabled protocols.

2013-03-28 Thread Ken Thomases
On Mar 28, 2013, at 6:05 AM, Jacek Caban wrote: > --- a/dlls/secur32/schannel_macosx.c > +++ b/dlls/secur32/schannel_macosx.c > @@ -630,6 +630,11 @@ static OSStatus schan_push_adapter(SSLConnectionRef > transport, const void *buff, > return ret; > } > > +DWORD schan_imp_enabled_protocols(

Re: gdi32: Copy gamma ramp validation from winex11 to make it driver independent (try 2)

2013-03-28 Thread Alexandre Julliard
André Hentschel writes: > +/* the bias could be because the app wanted something like a "red shift" > +* like when you're hit in Quake, but XVidMode doesn't support it, > +* so we have to reject a significant bias */ Clearly gdi32 doesn't care about XVidMode. > @@ -1325,6 +1405,18 @

Re: winemac: Track drawn surface rect to reduce black flicker for new or resized windows.

2013-03-28 Thread Ken Thomases
On Mar 27, 2013, at 3:31 PM, Ken Thomases wrote: > dlls/winemac.drv/macdrv.h | 12 +++- > dlls/winemac.drv/surface.c | 16 ++-- > dlls/winemac.drv/window.c | 17 ++--- > 3 files changed, 27 insertions(+), 18 deletions(-) > > <0001-winemac-Track-drawn-surface-r

Re: user32: ImmProcessKey is only called on WM_KEYDOWN and if the message is being removed

2013-03-28 Thread André Hentschel
Am 28.03.2013 14:41, schrieb Aric Stewart: > On 3/28/13 8:10 AM, Dmitry Timoshkov wrote: >> Aric Stewart wrote: >> > Worked out with testing on Japanese windows XP. Resolves issues with > keystrokes and accelerators in menus when the IME is active. You should really start adding

Re: user32: ImmProcessKey is only called on WM_KEYDOWN and if the message is being removed

2013-03-28 Thread Aric Stewart
On 3/28/13 8:10 AM, Dmitry Timoshkov wrote: > Aric Stewart wrote: > Worked out with testing on Japanese windows XP. Resolves issues with keystrokes and accelerators in menus when the IME is active. >>> >>> You should really start adding the tests and base your patches on test >>> result

Re: user32: ImmProcessKey is only called on WM_KEYDOWN and if the message is being removed

2013-03-28 Thread Dmitry Timoshkov
Aric Stewart wrote: > >> Worked out with testing on Japanese windows XP. Resolves issues with > >> keystrokes and accelerators in menus when the IME is active. > > > > You should really start adding the tests and base your patches on test > > results instead of some sort of speculation. > > > I

Re: user32: ImmProcessKey is only called on WM_KEYDOWN and if the message is being removed

2013-03-28 Thread Aric Stewart
On 3/27/13 9:25 PM, Dmitry Timoshkov wrote: > Aric Stewart wrote: > >> Worked out with testing on Japanese windows XP. Resolves issues with >> keystrokes and accelerators in menus when the IME is active. > > You should really start adding the tests and base your patches on test > results instead

Re: winemac: Null-terminate an snprintf-ed key name buffer in case of short buffer.

2013-03-28 Thread Ken Thomases
On Mar 28, 2013, at 2:26 AM, Per Johansson wrote: > On Wed, Mar 27, 2013 at 7:22 PM, Ken Thomases wrote: >> --- > > This has probably been discussed before, but shouldn't snprintfW be > safe against this kind of thing, the way POSIX snprintf is? I actually checked the man page for snprintf() wh

Re: winemac: Null-terminate an snprintf-ed key name buffer in case of short buffer.

2013-03-28 Thread Per Johansson
On Wed, Mar 27, 2013 at 7:22 PM, Ken Thomases wrote: > --- This has probably been discussed before, but shouldn't snprintfW be safe against this kind of thing, the way POSIX snprintf is? Regards, -- Per Johansson