Am Samstag, den 30.04.2011, 14:41 + schrieb Dan Kegel:
> Alexey wrote:
>
> > i currently digg in comctl32 to find why my app fails. I found that
> > string conversation AtoW in some places silently fails. The problem is
> > that the destination for string is just a fresh pointer (not NULL).
>
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=10648
Your paranoid android
On Saturday 30 April 2011 17:18:54 Stefan Dösinger wrote:
> 9-11) Distributor / End use choice. Note that some compiler
> flags(especially the framepointer one) can break apps and copy protection
> systems.
Forget about -O3. I can't get any Windows game working with that. Apparently I
am already l
Hi Stefan,
What do you think about using inline spinlocks (in asm code maybe) to
implement locks?
Clearly an optimized spinlock would mean different code for different
compilers/architectures, but shouldn't it be the best solution?
For your reference, once I commented out the GL locks to see St
Hi,
Here's another update.
First I expanded my performance tests at https://84.112.174.163/~git/perftest
a bit. The old tests were renamned to streamsrc_d3d and streamsrc_gl, and I
added another set of tests that just tests the draw overhead without ever
changing any states: drawprim_d3d and dr
Alexey wrote:
> i currently digg in comctl32 to find why my app fails. I found that
> string conversation AtoW in some places silently fails. The problem is
> that the destination for string is just a fresh pointer (not NULL).
> Str_SetPtrAtoW check if it is NULL pointer and if not it trys to
> Re
Interestingly enough I just had this error and it was solved by
sudo apt-get install oss4-base oss4-dev
On 4/30/11 3:05 PM, Eric Pouech wrote:
Le 30/04/2011 12:15, Jacek Caban a écrit :
On 4/29/11 11:58 PM, Eric Pouech wrote:
Le 29/04/2011 23:07, Dan Kegel a écrit :
While testing a game with current gecko, I saw the error
wine: Call from 0x7bc4ad90 to unimplemented function
msvcrt.dll._snwprin
Le 30/04/2011 12:15, Jacek Caban a écrit :
On 4/29/11 11:58 PM, Eric Pouech wrote:
Le 29/04/2011 23:07, Dan Kegel a écrit :
While testing a game with current gecko, I saw the error
wine: Call from 0x7bc4ad90 to unimplemented function
msvcrt.dll._snwprintf_s,
aborting
The game needed a nativ
On Sat, Apr 30, 2011 at 12:48:49PM +0200, Stefan Dösinger wrote:
> On Saturday 30 April 2011 12:31:28 Marcus Meissner wrote:
> > As distribution packager I wonder if I should build without debug or not.
> > A special package (wine-nodebug)?
> > Or just leave out TRACE() messages?
> Is there a confi
On Saturday 30 April 2011 12:31:28 Marcus Meissner wrote:
> As distribution packager I wonder if I should build without debug or not.
> A special package (wine-nodebug)?
> Or just leave out TRACE() messages?
Is there a configure option for disabling debugging? I couldn't find any when I
was lookin
On Sat, Apr 30, 2011 at 05:18:03AM +0200, Henri Verbeet wrote:
> On 30 April 2011 00:41, Stefan Dösinger wrote:
> > I don't know how much the effect of marking a few functions hidden changes
> > that
> > though. In the d3d code most things are already either static or hidden, and
> > still not us
On 4/29/11 11:58 PM, Eric Pouech wrote:
Le 29/04/2011 23:07, Dan Kegel a écrit :
While testing a game with current gecko, I saw the error
wine: Call from 0x7bc4ad90 to unimplemented function
msvcrt.dll._snwprintf_s,
aborting
The game needed a native msvcrt, so I had installed one with winetr
On Sat, Apr 30, 2011 at 12:41:19AM +0200, Stefan Dösinger wrote:
> On Friday 29 April 2011 21:01:36 Marcus Meissner wrote:
> > I do not think there will be noticable speed-up.
> Actually, not using -fPIC gives a ~2-3% speed boost in a number of d3d
> benchmarks.
>
> I don't know how much the effe
14 matches
Mail list logo
