wine-devel June 2010

wine-devel@winehq.org

121 participants
318 discussions

Start a nNew thread

Re: usp10/tests: having numbers in the ScriptStringXtoCP tests causes unpredictable behavior
by lats 17 Jun '10

17 Jun '10

When does this unpredictability occur? The tests have always run ok for me.

2 1

wined3d: Add NPOT quirk for GeforceFX 5200
by Roderick Colenbrander 17 Jun '10

17 Jun '10

1 0

Re: msvcrt/tests: Re-order tests to work around weird win_skip failure bug. (try 2)
by Alexandre Julliard 17 Jun '10

17 Jun '10

Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> writes: > Try 2: Re-order function bodies as well. > > From a51f6b7f855ccb1d9252a3d5e2698cdbe73ad053 Mon Sep 17 00:00:00 2001 > From: Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> > Date: Fri, 11 Jun 2010 14:13:52 +0100 > Subject: msvcrt/tests: Re-order tests to work around weird win_skip failure bug. > > Paul Vriens found which test caused the breakage. There's no need to reorder the functions, but there's a need to understand why that test is breaking win_skip. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2]kernel32/tests: Test the collation table much more
by Alexandre Julliard 17 Jun '10

17 Jun '10

André Hentschel <nerv(a)dawncrow.de> writes: > I added some ranges to test, so it is easy extensible That's still not a very convincing test... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: (resend) usp10/tests: Windows 95 does not set invalid glyphs to 0 but instead 0x80
by testbot＠testbot.winehq.org 17 Jun '10

17 Jun '10

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=2742 Your paranoid android. === WVISTAADM (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000 === W2K8SE (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000

1 0

Re: usp10/tests: Windows 95 does not set invalid glyphs to 0 but instead 0x80
by testbot＠testbot.winehq.org 17 Jun '10

17 Jun '10

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=2739 Your paranoid android. === WVISTAADM (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000 === W2K8SE (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000

1 0

Re: [PATCH] winspool/tests: Handle the Windows bug in GetPrinterDataEx
by testbot＠testbot.winehq.org 17 Jun '10

17 Jun '10

1 0

Re: PGO and wine
by Peter Davies 17 Jun '10

17 Jun '10

On 16 June 2010 02:37, Dan Kegel <dank(a)kegel.com> wrote: > But does PGO improve performance measurably? > Probably, to test it I need a program that runs wine like a typical program, that I can run autonomously. Anyone have any ideas? Peter

5 4

wrong link between bug and AppDB
by wylda＠volny.cz 16 Jun '10

16 Jun '10

Hi, i just made a mistake and linked bug 9264 with http://appdb.winehq.org/objectManager.php?sClass=version&iId=20179. But i wanted to link 19264 instead of 9264. What are the correct steps to fix this mistake? -- Kaspersky Internet Security 2010 + Kaspersky Mobile Security jen za 1199,-Kč. Ochraňte svůj počítač i mobil před zneužitím či ztrátou dat. Kupte si 2 produkty za cenu jednoho. www.kaspersky.cz

2 1

Re: [PATCH] ntdll: The FPU control word for newly created threads is 0x27f.
by Alexandre Julliard 16 Jun '10

16 Jun '10

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c > index 36f1499..0d383bd 100644 > --- a/dlls/ntdll/thread.c > +++ b/dlls/ntdll/thread.c > @@ -384,6 +384,7 @@ static void start_thread( struct startup_info *info ) > thread_data->pthread_id = pthread_self(); > > signal_init_thread( teb ); > + signal_init_thread_fpu(); > server_init_thread( func ); > pthread_sigmask( SIG_UNBLOCK, &server_block_set, NULL ); This should be done inside signal_init_thread(), that's already meant for platform-specific setup, there's no need to add a separate entry point. Also you may want to do an fninit if new threads are not supposed to inherit FPU state. -- Alexandre Julliard julliard(a)winehq.org

2 2

← Newer
1
...
16
17
18
19
20
21
22
...
32
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel June 2010