December 2006 - Wine-Devel - list.winehq.org

Re: gdi32: Improve the fontconfig filtering hack so that Mac suitcase fonts get through.
by Paul Vriens Dec. 20, 2006

Dec. 20, 2006

On Tue, 2006-12-19 at 21:21 +0000, Huw Davies wrote: > + if(strcasecmp(ext, "pfa") && strcasecmp(ext, "pfb")) > AddFontFileToList(file, NULL, ADDFONT_EXTERNAL_FONT); Hi, this patch was committed but I don't think this 'if' statement is correct as it will never be entered. No clue if it's just changing '&&' into '||'. Cheers, Paul.

2 2

Re: kernel32: suppress an unneeded warning (try 3)
by Alexandre Julliard Dec. 20, 2006

Dec. 20, 2006

Juan Lang <juan_lang(a)yahoo.com> writes: > This time I added a test. It wouldn't have failed before, it would merely > produce a useless fixme. This suppresses that fixme by removing comments > before checking whether the read string overflows the buffer. > > ChangeLog: remove comments from string read in GetPrivateProfileIntW There is nothing special about ';' in values, other characters will terminate the number conversion too. It's probably safe to simply remove the FIXME, or maybe make it a WARN. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ws2_32: ws_sockaddr_u2ws should zero the WS_sockaddr before using it.
by Francois Gouget Dec. 20, 2006

Dec. 20, 2006

On Wed, 20 Dec 2006, Kai Blin wrote: @@ -946,6 +946,9 @@ static int ws_sockaddr_u2ws(const struct { int res; + /* Zero the ws_sockaddr structure before using */ + memset(wsaddr, 0, *wsaddrlen); Are you sure this is needed in ws_sockaddr_u2ws() or should it rather be done by getsockname() (as your test indicates). Also, do we know of a real-world application that needs this? Finally, this memset() makes the one in the AF_UNSPEC case redundant, and may itself be redundant with some of the memcpy()s... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

2 1

Re: [5/5] d3d9: Add a render target test
by Alexandre Julliard Dec. 20, 2006

Dec. 20, 2006

"H. Verbeet" <hverbeet(a)gmail.com> writes: > Test if the stuff I just sent works. > > Changelog: > - Add a render target test > --- > > dlls/d3d9/tests/Makefile.in | 1 > dlls/d3d9/tests/rendertarget.c | 156 ++++++++++++++++++++++++++++++++++++++++ Could you please merge the test into one of the existing files, like device.c? We don't want to create new files for every test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winemenubuilder: Write truecolor icons as PNGs
by Francois Gouget Dec. 19, 2006

Dec. 19, 2006

On Wed, 6 Dec 2006, Frank Richter wrote: > When libpng is available, support for writing out 24 and 32bpp icons is > added, which are written out as PNGs. Also changed wineshelllink to > support both xpm and png extensions for icons. > > Some parts based on an older patch by Vitaliy Margolen. The thing that blocked this patch from being applied last time is that, if I remember correctly, Alexandre would like the PNG functionality to be added to the IPicture implementation in dlls/oleaut32/olepicture.c. Then winemenubuilder would use this interface to save the icon into the proper format. It's easy to see where the code should go to extend this interface to support loading PNG files as it already supports loading Gif and Jpeg files. However I'm fuzzy on how one would use this interface to specify the format to use for saving. Maybe by defining Wine-specific PICTYPE_XXX values? But that would not work on Windows... The other semi-related part would be to use ExtractAssociatedIcon() instead of extract_icon32(), though I'm not sure that's compatible with trying to select the 'best' icon size/color depth. I'm pretty sure my memory mangled some of this. Hopefully Alexandre will clarify things. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

2 2

Re: [18/19] WineD3D: Do not change the states if render target locking is disabled
by Stefan Dösinger Dec. 19, 2006

Dec. 19, 2006

Am Dienstag 19 Dezember 2006 23:27 schrieb Stefan Dösinger: > There is no point in messing with the states if we aren't going to draw > anything anyway. This patch will conflict slightly with Henri's multiple render target patch. (device->renderTarget vs device->renderTarget[0]). If it does not apply then its not a crucial problem for the other patches, they should still work fine.

1 0

Re: oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations) (try 2) (RESEND)
by Alexandre Julliard Dec. 19, 2006

Dec. 19, 2006

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > +#define HANDLE_DISPATCH(left, right) \ > + if ((V_VT(param_left) & VT_TYPEMASK) == VT_DISPATCH && \ > + (V_VT(param_right) & VT_TYPEMASK) != VT_NULL) \ > + {\ > + HRESULT hres;\ > + left = &tempLeft;\ > + hres = VARIANT_FetchDispatchValue(param_left, left);\ > + if (!SUCCEEDED(hres)) return hres;\ > + }\ > + if ((V_VT(param_right) & VT_TYPEMASK) == VT_DISPATCH &&\ > + (V_VT(param_left) & VT_TYPEMASK) != VT_NULL)\ > + {\ > + HRESULT hres;\ > + right = &tempRight;\ > + hres = VARIANT_FetchDispatchValue(param_right, right);\ > + if (!SUCCEEDED(hres)) return hres;\ > + } This macro is quite ugly. Also I don't see why you check the other variant against VT_NULL first, aren't there cases where you still need the other value? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Add a test for IDirectDrawSurface_SetColorKey
by Stefan Dösinger Dec. 19, 2006

Dec. 19, 2006

Am Montag 18 Dezember 2006 22:10 schrieb Günther Brammer: > Only tested with wine, unfortunately. Tests for the issue causing Bug 5730. I will run your test on windows, but I'd expect it to work. Can you also test which color key GetSurfaceDesc returns? > > diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c > index 3d70f82..74e4f28 100644 > --- a/dlls/ddraw/tests/dsurface.c > +++ b/dlls/ddraw/tests/dsurface.c > @@ -167,6 +167,7 @@ static void SrcColorKey32BlitTest(void) > LPDIRECTDRAWSURFACE lpDst; > DDSURFACEDESC ddsd; > DDSURFACEDESC ddsd2; > + DDCOLORKEY DDColorKey; > LPDWORD lpData; > HRESULT rc; > > @@ -222,6 +223,21 @@ static void SrcColorKey32BlitTest(void) > "Destination data after blitting is not correct\n"); > rc = IDirectDrawSurface_Unlock(lpDst, NULL); > ok(rc==DD_OK,"Unlock returned: %x\n",rc); > + > + /* Also test SetColorKey */ > + IDirectDrawSurface_GetColorKey(lpSrc, DDCKEY_SRCBLT, &DDColorKey); > + ok(DDColorKey.dwColorSpaceLowValue == 0xFF00FF && > DDColorKey.dwColorSpaceHighValue == 0xFF00FF, + "GetColorKey does not > return the colorkey used at surface creation\n"); + > + DDColorKey.dwColorSpaceLowValue = 0x00FF00; > + DDColorKey.dwColorSpaceHighValue = 0x00FF00; > + IDirectDrawSurface_SetColorKey(lpSrc, DDCKEY_SRCBLT, &DDColorKey); > + > + DDColorKey.dwColorSpaceLowValue = 0; > + DDColorKey.dwColorSpaceHighValue = 0; > + IDirectDrawSurface_GetColorKey(lpSrc, DDCKEY_SRCBLT, &DDColorKey); > + ok(DDColorKey.dwColorSpaceLowValue == 0x00FF00 && > DDColorKey.dwColorSpaceHighValue == 0x00FF00, + "GetColorKey does not > return the colorkey set with SetColorKey\n"); > > IDirectDrawSurface_Release(lpSrc); > IDirectDrawSurface_Release(lpDst);

1 0

Status of wine development
by Remco Dec. 19, 2006

Dec. 19, 2006

I ask it consisely, but maybe the answers could be posted as a news item on WineHQ. It would be great for Wine to get some exposure on tech sites from time to time. That requires some actual news (new minor releases aren't front-page news after all). So, what's the status/news of DX10? DX in general? the Mac-port? Wine 1.0? What's the status of anything else that has been a major thing last year? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

7 7

Conformance tests
by Michal Okresa Dec. 19, 2006

Dec. 19, 2006

Hello, wine developers guide says that conformance tests must pass successfully on all Windows platforms. I tried couple of tests in past weeks to catch wine's style of unit testing, but now I am confused. For example I run crosscompiled olefont test (oleaut32) on the windows machines (XP, 98). The test ended with 15 failures. The same test executed on my linux machine ended with 13 failures (reasons for failures are almost identical with previous runs on windows). Is this expected behaviour of conformance tests on windows platforms? thanks -- Michal Okresa

2 1