June 2008 - Wine-devel - list.winehq.org

context.c diff file...
by celticht32＠aol.com 26 Jun '08

26 Jun '08

ok sorry for cutting and pasting the whole routine.. did not see to do just the diff ... (give the old guy a break.. I am an architect now not a programmer <G>) here is the diff : 119d118 < 122d120 <???? WineD3D_PixelFormat *cfgs = This->adapter->cfgs; 124,125c122,124 <???? TRACE("ColorFormat=%s, DepthStencilFormat=%s, auxBuffers=%d, numSamples=%d, pbuffer=%d, findCompatible=%d\n", <?????????? debug_d3dformat(ColorFormat), debug_d3dformat(DepthStencilFormat), auxBuffers, numSamples, pbuffer, findCompatible); --- >???? WineD3D_PixelFormat *cfgs = This->adapter->cfgs; >???? BOOL exactDepthMatch = FALSE;? /*Changed june 23,08 */?? >???? PIXELFORMATDESCRIPTOR pfd;???? /*Changed june 23,08 */ 148,150c147,151 <???? if(DepthStencilFormat) { <???????? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); <???? } --- > /* Changed Section June 24,08 */ > > /*??? if(DepthStencilFormat) {???????????????????? Changed June 19,08*/ >???? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); > /*??? } */ 153,154c154,155 <???? for(i=0; i<nCfgs; i++) { <???????? BOOL exactDepthMatch = TRUE; --- >???? for(i=0; i<nCfgs; i++) >?????? { 156c157 < --- >???????????????????? 160c161 <???????????? continue; --- >??????????? continue; 164c165 <???????????? continue; --- >??????????? continue; 166c167 <???????? /* We like to have aux buffers in backbuffer mode */ --- >??????? /* We like to have aux buffers in backbuffer mode */ 168c169 <???????????? continue; --- >??????????? continue; 172,181c173 <???????????? continue; < <???????? if(cfgs->redSize != redBits) <???????????? continue; <???????? if(cfgs->greenSize != greenBits) <???????????? continue; <???????? if(cfgs->blueSize != blueBits) <???????????? continue; <???????? if(cfgs->alphaSize != alphaBits) <???????????? continue; --- >????????????? continue; 183,188c175,176 <???????? /* We try to locate a format which matches our requirements exactly. In case of <????????? * depth it is no problem to emulate 16-bit using e.g. 24-bit, so accept that. */ <???????? if(cfgs->depthSize < depthBits) <???????????? continue; <???????? else if(cfgs->depthSize > depthBits) <???????????? exactDepthMatch = FALSE; --- >???????? if ((cfgs->redSize != redBits) || (cfgs->greenSize != greenBits) || (cfgs->blueSize != blueBits) || (cfgs->alphaSize != alphaBits)) >????????????? continue; 194,195c182,183 <???????? if(stencilBits != cfgs->stencilSize && !(This->adapter->brokenStencil && stencilBits <= cfgs->stencilSize)) <???????????? continue; --- >???????? if((stencilBits != cfgs->stencilSize) && !((This->adapter->brokenStencil && stencilBits) <= cfgs->stencilSize)) >????????????? continue; 199c187 <???????????? continue; --- >????????????? continue; 201,205c189,192 <???????? /* When we have passed all the checks then we have found a format which matches our <????????? * requirements. Note that we only check for a limit number of capabilities right now, <????????? * so there can easily be a dozen of pixel formats which appear to be the 'same' but <????????? * can still differ in things like multisampling, stereo, SRGB and other flags. <????????? */ --- >???????? /* We try to locate a format which matches our requirements exactly. In case of >????????? * depth it is no problem to emulate 16-bit using e.g. 24-bit, so accept that. */ >????????? if (cfgs->depthSize !=? depthBits) >???????????? continue; 208c195,197 <???????? if(exactDepthMatch) { --- >???????? if (exactDepthMatch) >??????????? { >???????????? TRACE("Exact Depth Match\n"); 211c200,202 <???????? } else if(!iPixelFormat) { --- >??????????? } >???????? if (!iPixelFormat) >?????????? { 214a206 >???????????? TRACE("Emulating %d\n",cfgs->iPixelFormat); 216c208,209 <???????? } --- >???????????? break; /* Added June 24,08 */ >?????????? } 220c213,215 <???? if(!iPixelFormat && !findCompatible) { --- > > /*??? if (!iPixelFormat && !findCompatible) >?????? { 223,225c218,222 <???? } else if(!iPixelFormat) { <???????? PIXELFORMATDESCRIPTOR pfd; < --- >?????? } > */ >?????? >???? if (!iPixelFormat) >?????? { 238c235 < --- >???????? 240,245c237,243 <???????? if(!iPixelFormat) { <???????????? /* If this happens something is very wrong as ChoosePixelFormat barely fails */ <???????????? ERR("Can't find a suitable iPixelFormat\n"); <???????????? return FALSE; <???????? } <???? } --- >???????? if (!iPixelFormat) >?????????? { >??????????? /* If this happens something is very wrong as ChoosePixelFormat barely fails */ >??????????? ERR("Can't find a suitable iPixelFormat\n"); >??????????? return FALSE; >?????????? } >?????? } 247c245 <???? TRACE("Found iPixelFormat=%d for ColorFormat=%s, DepthStencilFormat=%s\n", iPixelFormat, debug_d3dformat(ColorFormat), debug_d3dformat(DepthStencilFormat)); --- >???? TRACE("Found iPixelFormat\n"); 374a373 >???????????? TRACE("Choose Pixel Format Failed\n"); Chris

4 3

Re: netapi32: Set the buffer to NULL in NetApiBufferFree
by Juan Lang 26 Jun '08

26 Jun '08

Kai Blin wrote: > This fixes a Valgrind warning triggered by the NetApiBufferFree() test > where a buffer is free()d twice. @@ -52,6 +52,7 @@ NET_API_STATUS WINAPI NetApiBufferFree(LPVOID Buffer) { TRACE("(%p)\n", Buffer); HeapFree(GetProcessHeap(), 0, Buffer); + Buffer = NULL; return NERR_Success; } I don't get it. How does setting a local variable to NULL avoid a warning about freeing it twice? I'm not saying the patch is wrong, I'm just saying I don't get how Valgrind is tricked by this. --Juan

4 8

Re: [2/2] ntdll: rtlstr.c: Implement checking for control characters in RtlIsTextUnicode [try 7]
by Zac Brown 26 Jun '08

26 Jun '08

Zac Brown wrote: > Add checking for control characters in both standard and byte-reversed > forms to (Rtl)IsTextUnicode. > > Changelog: > * Add if-statement to ensure we only found control characters in the > first 256 indices. If we found them beyond that, we don't care since > Windows doesn't either. > > > > ------------------------------------------------------------------------ > > --- > dlls/ntdll/rtlstr.c | 23 +++++++++++++++++++++++ > dlls/ntdll/tests/rtlstr.c | 21 +++++---------------- > 2 files changed, 28 insertions(+), 16 deletions(-) > > diff --git a/dlls/ntdll/rtlstr.c b/dlls/ntdll/rtlstr.c > index deec931..802782f 100644 > --- a/dlls/ntdll/rtlstr.c > +++ b/dlls/ntdll/rtlstr.c > @@ -1591,7 +1591,10 @@ NTSTATUS WINAPI RtlFindCharInUnicodeString( > */ > BOOLEAN WINAPI RtlIsTextUnicode( LPCVOID buf, INT len, INT *pf ) > { > + static const WCHAR std_control_chars[] = {'\r','\n','\t',' ',0x3000,0}; > + static const WCHAR byterev_control_chars[] = {0x0d00,0x0a00,0x0900,0x2000,0x0030,0}; > const WCHAR *s = buf; > + WCHAR *tmp_ptr; > int i; > unsigned int flags = ~0U, out_flags = 0; > > @@ -1650,6 +1653,26 @@ BOOLEAN WINAPI RtlIsTextUnicode( LPCVOID buf, INT len, INT *pf ) > } > } > > + /* These two tests are not mutually exclusive so regardless of whether */ > + /* the string has the BOM for byte-reversed order, it still checks */ > + /* the string if the flag is set. */ > + > + /* Check for standard Unicode control characters. */ > + if (flags & IS_TEXT_UNICODE_CONTROLS) > + { > + tmp_ptr = strpbrkW(s, std_control_chars); > + if (tmp_ptr != NULL && (tmp_ptr - s) < len) > + out_flags |= IS_TEXT_UNICODE_CONTROLS; > + } > + > + /* Check for byte-reversed Unicode control characters. */ > + if (flags & IS_TEXT_UNICODE_REVERSE_CONTROLS && strpbrkW(s, byterev_control_chars) != NULL) > + { > + tmp_ptr = strpbrkW(s, byterev_control_chars); > + if (tmp_ptr != NULL && (tmp_ptr - s) < len) > + out_flags |= IS_TEXT_UNICODE_REVERSE_CONTROLS; > + } > + > if (pf) > { > out_flags &= *pf; > diff --git a/dlls/ntdll/tests/rtlstr.c b/dlls/ntdll/tests/rtlstr.c > index 74ba8ea..d5d8839 100644 > --- a/dlls/ntdll/tests/rtlstr.c > +++ b/dlls/ntdll/tests/rtlstr.c > @@ -1693,7 +1693,6 @@ static void test_RtlIsTextUnicode(void) > > flags = IS_TEXT_UNICODE_UNICODE_MASK; > ok(pRtlIsTextUnicode(unicode, sizeof(unicode), &flags), "Text should not pass a Unicode\n"); > - todo_wine > ok(flags == (IS_TEXT_UNICODE_STATISTICS | IS_TEXT_UNICODE_CONTROLS), > "Expected flags 0x6, obtained %x\n", flags); > > @@ -1712,7 +1711,7 @@ static void test_RtlIsTextUnicode(void) > be_unicode[i + 1] = (unicode[i] >> 8) | ((unicode[i] & 0xff) << 8); > } > ok(!pRtlIsTextUnicode(be_unicode, sizeof(unicode) + 2, NULL), "Reverse endian should not be Unicode\n"); > - todo_wine ok(!pRtlIsTextUnicode(&be_unicode[1], sizeof(unicode), NULL), "Reverse endian should not be Unicode\n"); > + ok(!pRtlIsTextUnicode(&be_unicode[1], sizeof(unicode), NULL), "Reverse endian should not be Unicode\n"); > > flags = IS_TEXT_UNICODE_REVERSE_MASK; > ok(!pRtlIsTextUnicode(&be_unicode[1], sizeof(unicode), &flags), "Reverse endian should be Unicode\n"); > @@ -1722,7 +1721,6 @@ static void test_RtlIsTextUnicode(void) > > flags = IS_TEXT_UNICODE_REVERSE_MASK; > ok(!pRtlIsTextUnicode(be_unicode, sizeof(unicode) + 2, &flags), "Reverse endian should be Unicode\n"); > - todo_wine > ok(flags == (IS_TEXT_UNICODE_REVERSE_CONTROLS | IS_TEXT_UNICODE_REVERSE_SIGNATURE), > "Expected flags 0xc0, obtained %x\n", flags); > > @@ -1750,11 +1748,8 @@ static void test_RtlIsTextUnicode(void) > ok(flags == 0, "Expected flags 0x0, obtained %x\n", flags); > > flags = IS_TEXT_UNICODE_CONTROLS; > - todo_wine > - { > - ok(pRtlIsTextUnicode(unicode, sizeof(unicode), &flags), "Test should pass on Unicode string lacking control characters.\n"); > - ok(flags == IS_TEXT_UNICODE_CONTROLS, "Expected flags 0x04, obtained %x\n", flags); > - } > + ok(pRtlIsTextUnicode(unicode, sizeof(unicode), &flags), "Test should pass on Unicode string lacking control characters.\n"); > + ok(flags == IS_TEXT_UNICODE_CONTROLS, "Expected flags 0x04, obtained %x\n", flags); > > flags = IS_TEXT_UNICODE_CONTROLS; > ok(!pRtlIsTextUnicode(be_unicode_no_controls, sizeof(unicode_no_controls) + 2, &flags), > @@ -1762,11 +1757,8 @@ static void test_RtlIsTextUnicode(void) > ok(flags == 0, "Expected flags 0x0, obtained %x\n", flags); > > flags = IS_TEXT_UNICODE_CONTROLS; > - todo_wine > - { > - ok(pRtlIsTextUnicode(mixed_controls, sizeof(mixed_controls), &flags), "Test should pass on a string containing control characters.\n"); > - ok(flags == IS_TEXT_UNICODE_CONTROLS, "Expected flags 0x04, obtained %x\n", flags); > - } > + ok(pRtlIsTextUnicode(mixed_controls, sizeof(mixed_controls), &flags), "Test should pass on a string containing control characters.\n"); > + ok(flags == IS_TEXT_UNICODE_CONTROLS, "Expected flags 0x04, obtained %x\n", flags); > > /* Test IS_TEXT_UNICODE_REVERSE_CONTROLS flag */ > flags = IS_TEXT_UNICODE_REVERSE_CONTROLS; > @@ -1784,18 +1776,15 @@ static void test_RtlIsTextUnicode(void) > flags = IS_TEXT_UNICODE_REVERSE_CONTROLS; > ok(!pRtlIsTextUnicode(be_unicode, sizeof(unicode) + 2, &flags), > "Test should pass with byte-reversed Unicode string containing control characters.\n"); > - todo_wine > ok(flags == IS_TEXT_UNICODE_REVERSE_CONTROLS, "Expected flags 0x40, obtained %x\n", flags); > > flags = IS_TEXT_UNICODE_REVERSE_CONTROLS; > ok(!pRtlIsTextUnicode(mixed_controls, sizeof(mixed_controls), &flags), "Test should pass on a string containing byte-reversed control characters.\n"); > - todo_wine > ok(flags == IS_TEXT_UNICODE_REVERSE_CONTROLS, "Expected flags 0x40, obtained %x\n", flags); > > /* Test with flags for both byte-reverse and standard Unicode characters */ > flags = IS_TEXT_UNICODE_CONTROLS | IS_TEXT_UNICODE_REVERSE_CONTROLS; > ok(!pRtlIsTextUnicode(mixed_controls, sizeof(mixed_controls), &flags), "Test should pass on string containing both byte-reversed and standard control characters.\n"); > - todo_wine > ok(flags == (IS_TEXT_UNICODE_CONTROLS | IS_TEXT_UNICODE_REVERSE_CONTROLS), "Expected flags 0x44, obtained %x\n", flags); > > HeapFree(GetProcessHeap(), 0, be_unicode); > > > ------------------------------------------------------------------------ > > Ignore this patch please.

1 0

AppDB patches
by Francois Gouget 26 Jun '08

26 Jun '08

I see that these patches have not yet been applied to the AppDB. Is there anything wrong with them? * [AppDB] Assorted spelling fixes. http://www.winehq.org/pipermail/wine-patches/2008-June/056192.html * [AppDB] application_queue: Fix update(). http://www.winehq.org/pipermail/wine-patches/2008-June/056193.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

2 1

context.c
by celticht32＠aol.com 26 Jun '08

26 Jun '08

Has anyone looked at the changes put on the list for context.c? Just had not heard anything.. I assume it is because I am new and all but still...just trying to help per the request on the wine site =) chris

3 2

valgrind regression in gdiplus
by Dan Kegel 26 Jun '08

26 Jun '08

Yesterday, there were a bunch of new valgrind warnings in gdiplus, and they're still there today. See http://kegel.com/wine/valgrind/logs-2008-06-26/vg-gdiplus_font.txt For instance, Invalid read of size 4 at GdipCreateFont (font.c:99) by test_createfont (font.c:57) by func_font (font.c:250) by run_test (test.h:449) by main (test.h:498) Address 0x4 is not stack'd, malloc'd or (recently) free'd ... Conditional jump or move depends on uninitialised value(s) at winetest_vok (test.h:272) by winetest_ok (test.h:301) by test_createfont (font.c:61) by func_font (font.c:250) by run_test (test.h:449) by main (test.h:498) Uninitialised value was created by a stack allocation at test_createfont (font.c:43) ... Syscall param write(buf) points to uninitialised byte(s) at (within /lib/ld-2.7.so) by (within /lib/tls/i686/cmov/libc-2.7.so) by _IO_file_xsputn (in /lib/tls/i686/cmov/libc-2.7.so) by (within /lib/tls/i686/cmov/libc-2.7.so) by vfprintf (in /lib/tls/i686/cmov/libc-2.7.so) by winetest_vok (test.h:279) by winetest_ok (test.h:301) by test_createfont (font.c:65) by func_font (font.c:250) by run_test (test.h:449) by main (test.h:498) Address 0x7f21d657 is on thread 1's stack Uninitialised value was created by a stack allocation at test_createfont (font.c:43)

1 0

opengl32: work around a crash in glGetString
by Louis. Lenders 26 Jun '08

26 Jun '08

>As I mentioned before this requires a test case. As i tried to explain , in a simple test glGetString just return null, it will not crash for me, like it does in the program. >I remember from the gl log that the program didn't create a WGL context at all. It isn't allowed >to make opengl calls because of that Allowed or not, the program does so, and on windows it installs just fine. >Perhaps without a context (if Windows allows it) you get some GDI software renderer string >back or so. It just returns (null) >Anyway at this point it sounds like a workaround instead of a fix for the real bug. Well, the bug might be outside wine, so then it would be workaround, yes, but still necessary IMO. I cannot see how i can make a testcase based on the output of autocad here: http://bugs.winehq.org/attachment.cgi?id=14005 , other then i did already. It's just an endless sequence of 'wglGetIntegerv','wglFinish', and 'wglFlush', and then a crash in glGetString. I cannot make a test program crash like that; the test program just returns null, like i said before A last stupid question for stefan: how can i make X load the mesa driver, instead of my nvidia? __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

2 1

Whats wrong with my patch.
by Przemysław Białek 26 Jun '08

26 Jun '08

Hi! I sent a patch last Friday to the wine-patches list. I think that I fulfill the rules that I read on winehq website. Patch is simple implementation of function GdipDrawEllipse, and is based on existing function GdipFillEllipse. This is my first patch to the Wine project. I don't have deeper Wine, and Windows knowledge, so I ask, what else I must do, to get this patch accepted. The link to the mail is below: http://www.winehq.org/pipermail/wine-patches/2008-June/056223.html -- Best Regards Przemysław Białek

3 3

Re: memory leak fix
by Huw Davies 26 Jun '08

26 Jun '08

On Thu, Jun 26, 2008 at 02:05:15AM -0700, Joris Huizer wrote: > Untested, but this seems trivial/obvious, unless I overlooked something > > > > > From 4026f68e4404c4b1822eefe0b3419db4f896e055 Mon Sep 17 00:00:00 2001 > From: Joris Huizer <jorishuizer(a)debian.(none)> > Date: Thu, 26 Jun 2008 11:07:11 +0200 > Subject: [PATCH] memory leak fix > > --- > dlls/gdiplus/font.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c > index 0bb9fc7..9ef8edc 100644 > --- a/dlls/gdiplus/font.c > +++ b/dlls/gdiplus/font.c > @@ -378,6 +378,7 @@ GpStatus WINGDIPAPI GdipCreateFontFamilyFromName(GDIPCONST WCHAR *name, > ffamily->FamilyName = GdipAlloc(LF_FACESIZE * sizeof (WCHAR)); > if (!ffamily->FamilyName) > { > + GdipFree(ffamily->tmw); > GdipFree(ffamily); > return OutOfMemory; > } That's a good start, but there's more. The function leaks an hfont both on success and in this failure case. Also there should be a ReleaseDC in the failure case. In addition it seems to me that the tmw element may as well be an embedded structure rather than a structure pointer. That'll save having to worry about alloc'ing/free'ing it. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: Memory leak patch
by Huw Davies 26 Jun '08

26 Jun '08

On Thu, Jun 26, 2008 at 03:25:30AM -0700, Joris Huizer wrote: > > > dlls/gdiplus/font.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > >diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c >index 9ef8edc..86122da 100644 >--- a/dlls/gdiplus/font.c >+++ b/dlls/gdiplus/font.c >@@ -42,6 +42,7 @@ static inline REAL get_dpi (void) > HDC hdc = GetDC(0); > GdipCreateFromHDC (hdc, &graphics); > GdipGetDpiX(graphics, &dpi); >+ GdipFree(graphics); > ReleaseDC (0, hdc); > > return dpi; This should be GdipDeleteGraphics. Huw. -- Huw Davies huw(a)codeweavers.com

1 0