At 05:33 AM 9/6/00 +0200, you wrote:
I did. MSDN says it is correct like this, but it could be a GDI32 feature.
Thanks for the info. I guess that it fixed some real app then :-)
I have a hunch that this could turn out yet another difference 16/32 bits api since
the MSDN does not cover much
On Tue, Sep 05, 2000 at 11:24:34AM -0500, Andreas Mohr wrote:
On Tue, Sep 05, 2000 at 05:42:03PM +0200, Ove Kaaven wrote:
Why do you ask here, it's easy to look up. The program is responsible for
deallocating the palette.
OK, sorry.
In the first place it's the program that is responsible.
On Tue, 5 Sep 2000, Andreas Mohr wrote:
Why do you ask here, it's easy to look up. The program is responsible for
deallocating the palette.
OK, sorry.
In the first place it's the program that is responsible.
But what if it doesn't do that ?
MSDN says:
"When you no longer need the
At 09:17 AM 9/5/00 +, you wrote:
yet another case of GDI heap overflow:
snip
Arranged trace :
Call kernel32.501: LocalAlloc(0040,0048) ret=1002caad fs=008f
Ret kernel32.501: LocalAlloc() retval=40381930 ret=1002caad fs=008f
Call gdi32.160: CreatePalette(40381930) ret=100257b3
At 06:47 PM 9/5/00 +, you wrote:
have you recently tried winmine; mine comes up in nice a nice 1 bit bw scheme
(hard to tell when it's started, but the gdi lock overhaul may be a good start)
Not recently...
nice surprise ! it looks really better this way :-)
I will try to find the reason...
At 06:47 PM 9/5/00 +, you wrote:
have you recently tried winmine; mine comes up in nice a nice 1 bit bw scheme
(hard to tell when it's started, but the gdi lock overhaul may be a good start)
No, nothing to do with the lock in this case; here is the 'fix':
wine:diff -ru init.c.orig init.c
