February 2010 - Wine-Devel - list.winehq.org

Re: [1/3] d3dx9: Partial implementation of D3DXAssembleShader function.

by Henri Verbeet

On 2 February 2010 18:11, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > +void wpp_write_message_var(const char *fmt, ...) This is probably not strictly required, but if you add the gcc format attribute to the function, gcc will check if the parameters types match the ones in the format string. You can look at the PRINTF_ATTR macro in dlls/wined3d/wined3d_private and similar macros in other places for examples. > + if(current_include == NULL) > + { > + ERR("current_include == NULL, desc == %p, buffer = %s\n", > + desc, desc->buffer); > + HeapFree(GetProcessHeap(), 0, desc); > + return; > + } > + ID3DXInclude_Close(current_include, desc->buffer); > + HeapFree(GetProcessHeap(), 0, desc); > + return; Something like the following is probably nicer: + if (current_include) + ID3DXInclude_Close(current_include, desc->buffer); + else + ERR("current_include == NULL, desc == %p, buffer = %s\n", desc, desc->buffer); + + HeapFree(GetProcessHeap(), 0, desc); + return; > + struct wpp_callbacks wpp_callbacks = { > + wpp_lookup_mem, > + wpp_open_mem, > + wpp_close_mem, > + wpp_read_mem, > + wpp_write_mem, > + wpp_error, > + wpp_warning, > + }; This should be static const. > + TRACE("Shader source:\n"); > + for(i=0;i<data_len;i++) > + { > + TRACE("%c", data[i]); > + } > + TRACE("\n"); This doesn't look right. You should be using debugstr_an(), since this is external data you're tracing.

Feb. 3, 2010

Re: [PATCH 2/2] d3drm: Improve IDirect3DRMMeshBuilderImpl_Load and corresponding test

by Christian Costa

This url does not work for me. > Message du 03/02/10 11:08 > De : "Paul Vriens" > A : "Christian Costa" > Copie à : wine-devel(a)winehq.org > Objet : Re: [PATCH 2/2] d3drm: Improve IDirect3DRMMeshBuilderImpl_Load and corresponding test > > > On 02/03/2010 08:38 AM, Christian Costa wrote: > > > > --- > > > > dlls/d3drm/meshbuilder.c | 46 +++++++++++++++++++++++++++++++++++++++++++++- > > dlls/d3drm/tests/d3drm.c | 32 ++++++++++++++++++++++++-------- > > 2 files changed, 69 insertions(+), 9 deletions(-) > > > > > > > > > Hi Christian, > > I ran your tests on winetestbot and it shows some failures on several > platforms: > > https://winetestbot.geldorp.nl/JobDetails.pl?Key=562 > > -- > Cheers, > > Paul. > >

Feb. 3, 2010

Re: libpng dependency issue

by Luca Bennati

2010/2/3 Vincent Povirk <madewokherd+8cd9(a)gmail.com<madewokherd%2B8cd9(a)gmail.com> > > We use png_set_gray_1_2_4_to_8 to expand grayscale PNG's to an RGB format. > > It'd be nice to have libpng do this (if there's a non-deprecated way > to do it), but it's a trivial operation that we could do without if > necessary. > The error is: ccache gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -o pngformat.o pngformat.c pngformat.c:62: error: ‘png_set_gray_1_2_4_to_8’ undeclared here (not in a function) pngformat.c:62: warning: type defaults to ‘int’ in declaration of ‘ppng_set_gray_1_2_4_to_8’ pngformat.c: In function ‘PngDecoder_Initialize’: pngformat.c:285: error: called object ‘ppng_set_gray_1_2_4_to_8’ is not a function The distro i'm using is ArchLinux i686, that just shipped the new libraries with massive rebuilds. I already resolved the problem, as the only thing to do was search all "png_set_gray_1_2_4_to_8" and change them to "png_set_expand_gray_1_2_4_to_8" i already wrote a patch for this that make compilation works again, but now as appeared another problem: LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -D__WINESRC__ -foversion.res version.rc ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -shared ./windowscodecs.spec bmpdecode.o bmpencode.o clsfactory.o converter.o gifformat.o icoformat.o imgfactory.o info.o jpegformat.o main.o palette.o pngformat.o propertybag.o regsvr.o stream.o ungif.o version.res -o windowscodecs.dll.so -luuid -lole32 -ladvapi32 -lkernel32 ../../libs/port/libwine_port.a pngformat.o: In function `PngFrameEncode_Commit': /home/luca/wine-git/dlls/windowscodecs/pngformat.c:987: undefined reference to `png_set_longjmp_fn' pngformat.o: In function `PngEncoder_Initialize': /home/luca/wine-git/dlls/windowscodecs/pngformat.c:1119: undefined reference to `png_set_longjmp_fn' pngformat.o: In function `PngFrameEncode_WritePixels': /home/luca/wine-git/dlls/windowscodecs/pngformat.c:861: undefined reference to `png_set_longjmp_fn' pngformat.o: In function `PngDecoder_Initialize': /home/luca/wine-git/dlls/windowscodecs/pngformat.c:252: undefined reference to `png_set_longjmp_fn' collect2: ld returned 1 exit status I will now investigate this new one BTW i confirmed that the libjpeg 7 -> 8 bump doesn't bring problem :)

Feb. 3, 2010

Re: [PATCH 2/2] d3drm: Improve IDirect3DRMMeshBuilderImpl_Load and corresponding test

by Paul Vriens

On 02/03/2010 08:38 AM, Christian Costa wrote: > > --- > > dlls/d3drm/meshbuilder.c | 46 +++++++++++++++++++++++++++++++++++++++++++++- > dlls/d3drm/tests/d3drm.c | 32 ++++++++++++++++++++++++-------- > 2 files changed, 69 insertions(+), 9 deletions(-) > > > > Hi Christian, I ran your tests on winetestbot and it shows some failures on several platforms: https://winetestbot.geldorp.nl/JobDetails.pl?Key=562 -- Cheers, Paul.

Feb. 3, 2010

Re: [PATCH 1/5] qedit: Mostly stubbed out implementation of SampleGrabber filter

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > +/* Macro to get the SampleGrabber This pointer from interface pointer */ > +#define GET_THIS(ptr,iface) ((SG_Impl *)((char *)(ptr) - FIELD_OFFSET(SG_Impl,iface ## _Vtbl))) Please define an inline function for that sort of thing. Look at shelllink.c for examples. -- Alexandre Julliard julliard(a)winehq.org

Feb. 3, 2010

Re: [PATCH 4/5] d3drm: Add some tests

by Christian Costa

This is very weird indeed. I avoided using dx file without version header which should help. This should not happen and is not worth testing unless an app rely on this behaviour. If there are still problems I will see with the d3drm.dll from NT4. document.write (BT_SUBMIT); > Message du 03/02/10 08:59 > De : "Paul Vriens" > A : "Christian Costa" > Copie à : wine-devel(a)winehq.org > Objet : Re: [PATCH 4/5] d3drm: Add some tests > > > On 02/03/2010 08:50 AM, Christian Costa wrote: > >> > >> While you are at it. This patch introduces a test failure on NT4: > >> > >> http://test.winehq.org/data/tests/d3drm:d3drm.html > >> > >> Could you have a look? > >> > > Just submitted patches should help with this problem. > > Thanks for looking into this. Isn't it strange that only NT4 is affected? > > -- > Cheers, > > Paul. >

Feb. 3, 2010

Re: [PATCH 4/5] d3drm: Add some tests

by Paul Vriens

On 02/03/2010 08:50 AM, Christian Costa wrote: >> >> While you are at it. This patch introduces a test failure on NT4: >> >> http://test.winehq.org/data/tests/d3drm:d3drm.html >> >> Could you have a look? >> > Just submitted patches should help with this problem. Thanks for looking into this. Isn't it strange that only NT4 is affected? -- Cheers, Paul.

Feb. 3, 2010

Re: [PATCH 4/5] d3drm: Add some tests

by Christian Costa

Paul Vriens a écrit : > > On 02/01/2010 10:10 PM, Christian Costa wrote: >> Paul Vriens a écrit : >>> >>> On 02/01/2010 08:56 AM, Stefan Dösinger wrote: >>>> On Monday 01 February 2010 08:18:42 Christian Costa wrote: >>>>> +void Test(void) >>>>> +{ >>>>> ... >>>>> Test(); >>>> I think the function name Test() won't be too helpful once more tests >>>> are >>>> added. You can also make it static, unless you plan to call it from >>>> another .c >>>> file. >>>> >>>> >>> >>> +#define D3DRM_GET_PROC(func) \ >>> + p ## func = (void*)GetProcAddress(d3drm_handle, #func); \ >>> + if(!p ## func) { \ >>> + trace("GetProcAddress(%s) failed\n", #func); \ >>> >>> A win_skip() would probably be better here. >>> >>> + FreeLibrary(d3drm_handle); \ >>> + return FALSE; \ >>> + } >>> + >>> +static BOOL InitFunctionPtrs(void) >>> +{ >>> + d3drm_handle = LoadLibraryA("d3drm.dll"); >>> + >>> + if(!d3drm_handle) >>> + { >>> + skip("Could not load d3drm.dll\n"); >>> >>> And here as well. >>> >> Well. It comes from vector.c. I never use win_skip so far but I can take >> a look at it. Thanks. >> >> > > While you are at it. This patch introduces a test failure on NT4: > > http://test.winehq.org/data/tests/d3drm:d3drm.html > > Could you have a look? > Just submitted patches should help with this problem. Christian

Feb. 3, 2010

Re: [1/2] msxml3/doc: Implement IXMLDOMDocument::get_url() with some tests

by Nikolay Sivov

Please disregard this and next [2/2] patches. I'll try another way.

Feb. 3, 2010

Re: [1/2] msxml3/doc: Implement IXMLDOMDocument::get_url() with some tests

by Nikolay Sivov

On 2/3/2010 02:58, Jacek Caban wrote: > Hi Nikolay, > > On 2/2/10 11:23 PM, Nikolay Sivov wrote: >> Implement IXMLDOMDocument::get_url() with some tests > > You probably should use GetDisplayName result of moniker used to load > the document to obtain its URL. I'll try with it, thanks. > > Thanks, > Jacek > > >

Feb. 3, 2010