On 9/28/2012 20:43, Daniel Jelinski wrote:
Corrected from first try:
- uses GetWindowLong instead of GetWindowLongPtr
- does not touch dwStyle
Sorry, was busy to reply earlier.
I think this fix is ok if it really helps, thanks for working on this.
28.09.2012 18:14, Alexandre Julliard kirjoitti:
> Anssi Hannula writes:
>
>> Some Linux distributions (at least Mageia) build packages with
>> -Wp,-D_FORTIFY_SOURCE=2 by default. There is a check in configure which
>> checks for enabled fortify and adds "-U_FORTIFY_SOURCE
>> -D_FORTIFY_SOURCE=0".
Anssi Hannula writes:
> Some Linux distributions (at least Mageia) build packages with
> -Wp,-D_FORTIFY_SOURCE=2 by default. There is a check in configure which
> checks for enabled fortify and adds "-U_FORTIFY_SOURCE
> -D_FORTIFY_SOURCE=0". Unfortunately, -Wp,-Dfoo are applied after -Dfoo,
> so
Looks good, thanks.
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=21880
Your paranoid android
Сергей Мосин writes:
> The function WineEngAddFontMemResourceEx in gdi32/fretype.c contained
> strange XOR operation with some random number 0x87654321, instead of
> returning the real font handle.
Do you have an app that depends on this? What does it do with the
handle?
--
Alexandre Julliard
On Thu, 2012-09-27 at 23:07 +0200, Christian Costa wrote:
> >> if (!(cabinet_file = get_cabinet_filename(mi)))
> > The requirement that the continuous cabinet name matches the next cabinet
> > in the media table
> > might simply be too strict. Perhaps we need to try them one by one and let
