September 2009 - Wine-Devel

Wineconf drumbeat - don't sleep on the streets!
by Jeremy White Sept. 10, 2009

Sept. 10, 2009

Hi Folks, It's now close enough to November that you can't blow this email off <grin>. We've got all the info here: http://wiki.winehq.org/WineConf2009 Our challenge this year is that we're managing the booking, so we need a firm head count ahead of time. Again, if money is an issue, and you haven't already, please contact me privately. So if you're thinking of coming, email Hans. Now. Please. Failure to do so may result in your sleeping on the streets of Enschede *grin*. Cheers, Jeremy

2 2

Re: [2/4] WineD3D: Make context_attach_surface_fbo srgb aware
by Henri Verbeet Sept. 10, 2009

Sept. 10, 2009

2009/9/10 Stefan Dösinger <stefan(a)codeweavers.com>: > @@ -402,7 +433,7 @@ static void context_apply_fbo_entry(struct wined3d_context *context, struct fbo_ > for (i = 0; i < GL_LIMITS(buffers); ++i) > { > IWineD3DSurface *render_target = device->render_targets[i]; > - context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, i, render_target); > + context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, i, render_target, SRGB_ANY); > } > > /* Apply depth targets */ I don't think SRGB_ANY is correct here. context_apply_fbo_entry() very much cares about which texture is attached to the FBO. If rendering to sRGB textures was supported properly this would depend on the sRGB write state, but since it isn't this should aways be SRGB_RGB. > @@ -2041,7 +2072,7 @@ struct wined3d_context *ActivateContext(IWineD3DDeviceImpl *This, IWineD3DSurfac > FIXME("Activating for CTXUSAGE_BLIT for an offscreen target with ORM_FBO. This should be avoided.\n"); > ENTER_GL(); > context_bind_fbo(context, GL_FRAMEBUFFER_EXT, &context->dst_fbo); > - context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, target); > + context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, target, SRGB_ANY); > context_attach_depth_stencil_fbo(context, GL_FRAMEBUFFER_EXT, NULL, FALSE); > LEAVE_GL(); > } else { Similar to above. > @@ -6045,7 +6045,7 @@ static void color_fill_fbo(IWineD3DDevice *iface, IWineD3DSurface *surface, > context = ActivateContext(This, NULL, CTXUSAGE_RESOURCELOAD); > ENTER_GL(); > context_bind_fbo(context, GL_FRAMEBUFFER_EXT, &context->dst_fbo); > - context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, surface); > + context_attach_surface_fbo(context, GL_FRAMEBUFFER_EXT, 0, surface, SRGB_ANY); > context_attach_depth_stencil_fbo(context, GL_FRAMEBUFFER_EXT, NULL, FALSE); > } Afaik color fill colors are specified in RGB space. Unless you have a test that shows otherwise, this should be SRGB_RGB. > @@ -6463,7 +6463,7 @@ void stretch_rect_fbo(IWineD3DDevice *iface, IWineD3DSurface *src_surface, WINED > TRACE("Source surface %p is offscreen\n", src_surface); > ENTER_GL(); > context_bind_fbo(context, GL_READ_FRAMEBUFFER_EXT, &context->src_fbo); > - context_attach_surface_fbo(context, GL_READ_FRAMEBUFFER_EXT, 0, src_surface); > + context_attach_surface_fbo(context, GL_READ_FRAMEBUFFER_EXT, 0, src_surface, SRGB_ANY); > glReadBuffer(GL_COLOR_ATTACHMENT0_EXT); > checkGLcall("glReadBuffer()"); > context_attach_depth_stencil_fbo(context, GL_READ_FRAMEBUFFER_EXT, NULL, FALSE); > @@ -6503,7 +6503,7 @@ void stretch_rect_fbo(IWineD3DDevice *iface, IWineD3DSurface *src_surface, WINED > > ENTER_GL(); > context_bind_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, &context->dst_fbo); > - context_attach_surface_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, 0, dst_surface); > + context_attach_surface_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, 0, dst_surface, SRGB_ANY); > glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT); > checkGLcall("glDrawBuffer()"); > context_attach_depth_stencil_fbo(context, GL_DRAW_FRAMEBUFFER_EXT, NULL, FALSE); This doesn't work either. While it probably doesn't matter if the blit is done in RGB or sRGB space, it still needs to be the same color space for both surfaces (and one of those can be onscreen). On a higher level, I'm not really happy with how sRGB textures currently fit in and how that's starting to spread to everything that has to deal with surfaces.

2 1

Re: [3/4] WineD3D: Perform the srgb copy with fbo_blit if possible
by Henri Verbeet Sept. 10, 2009

Sept. 10, 2009

2009/9/10 Stefan Dösinger <stefan(a)codeweavers.com>: > + if (context->current_fbo) { > + context_bind_fbo(context, GL_FRAMEBUFFER_EXT, &context->current_fbo->id); > + } else { > + context_bind_fbo(context, GL_FRAMEBUFFER_EXT, NULL); > + } This shouldn't be needed. > + /* Need FBOs obviously */ > + if(wined3d_settings.offscreen_rendering_mode != ORM_FBO) return FALSE; > + /* Need framebuffer blit */ > + if(!GL_SUPPORT(EXT_FRAMEBUFFER_BLIT)) return FALSE; > + /* Need to be able to attach both RGB and sRGB copy */ > + if((fmt_flags & attach_flags) != attach_flags) return FALSE; > + /* Need to be able to blit from and to my format */ > + if(!surface_can_stretch_rect(This, This)) return FALSE; > + /* Need either RGB or sRGB copy up to date */ > + if((This->Flags & (SFLAG_INSRGBTEX | SFLAG_INTEXTURE)) == 0) return FALSE;That's redundant, Some of those are redundant. A format is never FBO attachable if FBOs are disabled, surface_can_stretch_rect() will already check for regular attachment.

1 0

Re: bitblt.c - GdiAlphaBlend : Check for NULL Pointer
by Paul Vriens Sept. 10, 2009

Sept. 10, 2009

On 09/10/2009 10:56 PM, Markus Stockhausen wrote: > Hi, > > http://bugs.winehq.org/show_bug.cgi?id=18041 reveals a bug where > GdiAlphaBlend will crash in Teamviewer application when a NULL pointer > is handed over. The attached check fixes that behaviour. > > Tanks in advance. > > Markus > > > > ------------------------------------------------------------------------ > > No comments on the validity of the patch but you should add a test for this to the conformance tests. If you are bailing out when dcSrc == NULL then the other checks in that function for dcSrc are not necessary anymore. -- Cheers, Paul.

1 0

Re: winehq: Fix some HTML markup
by Jeremy Newman Sept. 10, 2009

Sept. 10, 2009

The reason I left the XHTML markup in was eventually the goal was to convert the entire website to XHTML. The only issue with leaving them in while still in HTML4/Transitional is that the pages do not pass W3C validation. I am still willing to live with non-valid working HTML to save some work down the road. -N André Hentschel wrote: > --- > templates/de/about.template | 2 +- > templates/de/contributing.template | 8 +++--- > templates/de/download.template | 10 +++--- > templates/de/help.template | 16 ++++++------ > templates/en/about.template | 2 +- > templates/en/contributing.template | 8 +++--- > templates/en/documentation.template | 48 +++++++++++++++++----------------- > templates/en/download.template | 10 +++--- > templates/en/help.template | 16 ++++++------ > templates/fr/about.template | 2 +- > templates/pl/about.template | 2 +- > templates/pl/download.template | 10 +++--- > templates/pl/help.template | 16 ++++++------ > templates/pt/about.template | 2 +- > templates/pt/contributing.template | 8 +++--- > 15 files changed, 80 insertions(+), 80 deletions(-) > > > > > > ------------------------------------------------------------------------ > >

3 3

Asynchronus serial port
by Fenixk19 Sept. 10, 2009

Sept. 10, 2009

Hello! I've already post the bug(http://bugs.winehq.org/show_bug.cgi?id=19713) on this subject, but i need more help. So I've decided to write here. There is a problem in wine. When I use asynchronous serial port read, data never comes. Event, caused by select comes. But operation status stays pending, and i can't do anything to this serial port anymore. In windows it never get pending, and port can be accessed just after data arrival. Seems to be wineserver problem, but i don't know, where to look at. What code respond for asynchronous serial port in wineserver? Alexander. P.S. Test program attached.

4 4

Re: [PATCH 12/12] openal32: fixed ctx null ptr debug (Coverity)
by Chris Robinson Sept. 10, 2009

Sept. 10, 2009

I have a different patch that will fix this, that also fixes a problem with error states.

1 0

Re: server: Use kernel support for thread affinity when available
by Chris Robinson Sept. 10, 2009

Sept. 10, 2009

On Thursday 10 September 2009 9:43:02 am Juan Lang wrote: > +/* Define to 1 if you have the `sched_getaffinity' function. */ > +#undef HAVE_SCHED_GETAFFINITY > + ... > +#ifdef HAVE_SCHED_GET_AFFINITY > +#define __USE_GNU > +#include <sched.h> > +#endif Looks like a typo there.

1 0

Re: winex11: Make X11DRV_PALETTE_ComputeColorShifts() static.
by Roderick Colenbrander Sept. 10, 2009

Sept. 10, 2009

In a next patch ComputeChannelShift will be called from outside palette.c and for this reason I made it non-static. Roderick On Thu, Sep 10, 2009 at 5:58 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > dlls/winex11.drv/palette.c | 115 ++++++++++++++++++++++---------------------- > dlls/winex11.drv/x11drv.h | 1 - > 2 files changed, 57 insertions(+), 59 deletions(-) > > diff --git a/dlls/winex11.drv/palette.c b/dlls/winex11.drv/palette.c > index 81bb73b..cdbfb21 100644 > --- a/dlls/winex11.drv/palette.c > +++ b/dlls/winex11.drv/palette.c > @@ -131,6 +131,63 @@ static void palette_set_mapping( HPALETTE hpal, int *mapping ) > wine_tsx11_unlock(); > } > > +/*********************************************************************** > + * X11DRV_PALETTE_ComputeChannelShift > + * > + * Calculate conversion parameters for a given color mask > + */ > +static void X11DRV_PALETTE_ComputeChannelShift(unsigned long maskbits, ChannelShift *physical, ChannelShift *to_logical) > +{ > + int i; > + > + if (maskbits==0) > + { > + physical->shift=0; > + physical->scale=0; > + physical->max=0; > + to_logical->shift=0; > + to_logical->scale=0; > + to_logical->max=0; > + return; > + } > + > + for(i=0;!(maskbits&1);i++) > + maskbits >>= 1; > + > + physical->shift = i; > + physical->max = maskbits; > + > + for(i=0;maskbits!=0;i++) > + maskbits >>= 1; > + physical->scale = i; > + > + if (physical->scale>8) > + { > + /* On FreeBSD, VNC's default 32bpp mode is bgrabb (ffc00000,3ff800,7ff)! > + * So we adjust the shifts to also normalize the color fields to > + * the Win32 standard of 8 bits per color. > + */ > + to_logical->shift=physical->shift+(physical->scale-8); > + to_logical->scale=8; > + to_logical->max=0xff; > + } else { > + to_logical->shift=physical->shift; > + to_logical->scale=physical->scale; > + to_logical->max=physical->max; > + } > +} > + > +/*********************************************************************** > + * X11DRV_PALETTE_ComputeColorShifts > + * > + * Calculate conversion parameters for a given color > + */ > +static void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask) > +{ > + X11DRV_PALETTE_ComputeChannelShift(redMask, &shifts->physicalRed, &shifts->logicalRed); > + X11DRV_PALETTE_ComputeChannelShift(greenMask, &shifts->physicalGreen, &shifts->logicalGreen); > + X11DRV_PALETTE_ComputeChannelShift(blueMask, &shifts->physicalBlue, &shifts->logicalBlue); > +} > > /*********************************************************************** > * COLOR_Init > @@ -278,64 +335,6 @@ void X11DRV_PALETTE_Cleanup(void) > } > > /*********************************************************************** > - * X11DRV_PALETTE_ComputeChannelShift > - * > - * Calculate conversion parameters for a given color mask > - */ > -static void X11DRV_PALETTE_ComputeChannelShift(unsigned long maskbits, ChannelShift *physical, ChannelShift *to_logical) > -{ > - int i; > - > - if (maskbits==0) > - { > - physical->shift=0; > - physical->scale=0; > - physical->max=0; > - to_logical->shift=0; > - to_logical->scale=0; > - to_logical->max=0; > - return; > - } > - > - for(i=0;!(maskbits&1);i++) > - maskbits >>= 1; > - > - physical->shift = i; > - physical->max = maskbits; > - > - for(i=0;maskbits!=0;i++) > - maskbits >>= 1; > - physical->scale = i; > - > - if (physical->scale>8) > - { > - /* On FreeBSD, VNC's default 32bpp mode is bgrabb (ffc00000,3ff800,7ff)! > - * So we adjust the shifts to also normalize the color fields to > - * the Win32 standard of 8 bits per color. > - */ > - to_logical->shift=physical->shift+(physical->scale-8); > - to_logical->scale=8; > - to_logical->max=0xff; > - } else { > - to_logical->shift=physical->shift; > - to_logical->scale=physical->scale; > - to_logical->max=physical->max; > - } > -} > - > -/*********************************************************************** > - * X11DRV_PALETTE_ComputeColorShifts > - * > - * Calculate conversion parameters for a given color > - */ > -void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask) > -{ > - X11DRV_PALETTE_ComputeChannelShift(redMask, &shifts->physicalRed, &shifts->logicalRed); > - X11DRV_PALETTE_ComputeChannelShift(greenMask, &shifts->physicalGreen, &shifts->logicalGreen); > - X11DRV_PALETTE_ComputeChannelShift(blueMask, &shifts->physicalBlue, &shifts->logicalBlue); > -} > - > -/*********************************************************************** > * X11DRV_PALETTE_BuildPrivateMap > * > * Allocate colorcells and initialize mapping tables. > diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h > index 62b0d63..844af31 100644 > --- a/dlls/winex11.drv/x11drv.h > +++ b/dlls/winex11.drv/x11drv.h > @@ -494,7 +494,6 @@ extern BOOL X11DRV_IsSolidColor(COLORREF color); > extern COLORREF X11DRV_PALETTE_ToLogical(X11DRV_PDEVICE *physDev, int pixel); > extern int X11DRV_PALETTE_ToPhysical(X11DRV_PDEVICE *physDev, COLORREF color); > extern int X11DRV_PALETTE_LookupPixel(COLORREF color); > -extern void X11DRV_PALETTE_ComputeColorShifts(ColorShifts *shifts, unsigned long redMask, unsigned long greenMask, unsigned long blueMask); > > extern unsigned int depth_to_bpp( unsigned int depth ); > > -- > 1.6.3.3 > > >

1 0

Re: mshtml: Add support for Reference BSTR when setting styles.
by Paul Vriens Sept. 10, 2009

Sept. 10, 2009

On 09/10/2009 12:00 PM, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > mshtml: Add support for Reference BSTR when setting styles. > > Best Regards > Alistair Leslie-Hughes > > > ------------------------------------------------------------------------ > > Hi Alistair, Now VT_BSTR is used in two case-statements. -- Cheers, Paul.

1 1

Re: msi: Ignore CoInitialize failure in ACTION_CreateShortcuts.
by Hans Leidekker Sept. 10, 2009

Sept. 10, 2009

> Fixes http://bugs.winehq.org/show_bug.cgi?id=19636 Or it doesn't: err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded err:shell:ShellLink_QueryInterface -- Interface: E_NOINTERFACE Because IShellLink is apartment-threaded only? -Hans

1 0

Performance tag for Bugzilla?
by Scott Ritchie Sept. 9, 2009

Sept. 9, 2009

We have a wiki page functioning as sort of a wannabe performance tag here: http://wiki.winehq.org/Performance-related_bugs Is this a reasonable tag to have? Thanks, Scott Ritchie

1 0

http://bugs.winehq.org/show_bug.cgi?id=18337
by Frank Gruman Sept. 9, 2009

Sept. 9, 2009

I have been using wine for various tools and utilities at work and home for some time now. Recently I tried to use wine to run the VMware Infrastructure Client and ran into bug 18337 (http://bugs.winehq.org/show_bug.cgi?id=18337) I am pasting my comments on that bug here to avoid repetition (http://bugs.winehq.org/show_bug.cgi?id=18337#c4) <paste> So - I looked through the code (current git @1.1.29) and compared to the 1.0 release (because of comment 1) and did not see that CERT_CHAIN_POLICY_SSL was ever implemented. Looking at chain.c, line 1886-1902 I can see the switch-case statement where this would have been handled. The problem I ran into while trying to keep up with the code was figuring out what the verify_* methods are trying to do. I'd really like to see this work and may have some spare cycles to help out. The problem is that I don't understand everything happening in these methods - can I get some pointers to what is happening or what should happen in the yet to be created verify_ssl_policy() method? </paste> Regards, Frank

2 3

ddraw: Added support for WINED3DFMT_X8L8V8U8, WINED3DFMT_R8G8B8A8_SNORM and WINED3DFMT_R16G16_SNORM to PixelFormat_WineD3DtoDD
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 9, 2009

Sept. 9, 2009

Stephan, All the patches proposed to bug #16559 forget one thing: it cannot be right to patch only PixelFormat_WineD3DtoDD without patching its converse function in the same file, PixelFormat_DD2WineD3D. There's no gain in silencing a fixme by introducing internal inconsistency in the source code. I had my own patch which changed both but for X8L8V8U8 only, but never published it because I observed no visual difference in the one app I tested, and had no time for 3 other ones I own, nor the other formats. I'm left wondering which of the pixelformats actually produces a visual difference as e.g. in comment #27. BTW, I suggest you submit individual patches, one per format. Regards, Jörg Höhle

2 1

Re: CPPCheck for Sept 8th
by chris ahrendt Sept. 9, 2009

Sept. 9, 2009

Nicolas Le Cam wrote: > 2009/9/9 Alexandre Julliard <julliard(a)winehq.org>: >> chris ahrendt <celticht32(a)yahoo.com> writes: >> >>> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd >> This is the only one that looks a real bug, all the rest are false >> positives. Please filter them out from future reports. >> >> -- >> Alexandre Julliard >> julliard(a)winehq.org >> >> >> > > Not necessary false positives. Errors in dlls/msvcrt/tests/file.c, for > example, are real but expected errors, as it's the purpose of the test > to see how it behaves on Windows in such situation. > So continue to send everything then? Since I have been running them the size has not really been that large... just let me know what you want me to send and I will send it in... Chris

2 1

CPPCheck for Sept 8th
by chris ahrendt Sept. 9, 2009

Sept. 9, 2009

[/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:146]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:208]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:387]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/makedep.c:953]: (error) Resource leak: file [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/msmangle.c:164]: (error) Memory leak: function_name [/home/cahrendt/wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map This is using thursdays git tree of CPPCheck.. please let me know if there are FP's so I can report them. Chris p.s. Thanks stephan for pointing out I sent it to the wrong list =D

3 2

Re: CPPCheck for Sept 8th
by chris ahrendt Sept. 9, 2009

Sept. 9, 2009

Alexandre Julliard wrote: > chris ahrendt <celticht32(a)yahoo.com> writes: > >> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd > > This is the only one that looks a real bug, all the rest are false > positives. Please filter them out from future reports. > Is there any others? So ignore the tests findings and the tools findings? Are These the ones that may be a bug then : [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:146]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:208]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 These Ignore correct? [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:387]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/makedep.c:953]: (error) Resource leak: file [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/msmangle.c:164]: (error) Memory leak: function_name [/home/cahrendt/wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map Chris

1 0

Re: CPPCheck for Sept 8th
by chris ahrendt Sept. 9, 2009

Sept. 9, 2009

Alexandre Julliard wrote: > chris ahrendt <celticht32(a)yahoo.com> writes: > >> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd > > This is the only one that looks a real bug, all the rest are false > positives. Please filter them out from future reports. > Alexandre, I will filter them as best I can going forward... Chris

1 0

Re: CPP Run for Sept 8
by Stefan Dösinger Sept. 9, 2009

Sept. 9, 2009

hi, I think its better to send these reports to wine-devel instead of wine-patches

1 0

Re: gdi32/tests: Some GdiAlphaBlend tests
by Roderick Colenbrander Sept. 9, 2009

Sept. 9, 2009

Regarding the zero source DC, what happens visually? On Wed, Sep 9, 2009 at 1:30 PM, Nikolay Sivov<bunglehead(a)gmail.com> wrote: > Bug http://bugs.winehq.org/show_bug.cgi?id=18041 shows this commented crash. > I'm not sure how to fix it, but I think this call can't do anything > without source context. > > Another question is where to place such check - in gdi32 or winex11...any > advices are welcome. > > Changelog: > - Some GdiAlphaBlend tests > > >From a59cadcf03edeefff95c340230a47c9c3c60727f Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Wed, 9 Sep 2009 15:20:34 +0400 > Subject: Some GdiAlphaBlend tests > > --- > dlls/gdi32/tests/bitmap.c | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdi32/tests/bitmap.c b/dlls/gdi32/tests/bitmap.c > index 8666da2..38acd09 100644 > --- a/dlls/gdi32/tests/bitmap.c > +++ b/dlls/gdi32/tests/bitmap.c > @@ -2376,6 +2376,25 @@ static void test_GdiAlphaBlend(void) > blend.SourceConstantAlpha = 128; > blend.AlphaFormat = 0; > > + /* zero dimensions */ > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 0, 0, hdcSrc, 0, 0, 20, 20, blend), TRUE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, 0, 0, 0, 0, blend), TRUE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > + > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 0, 0, hdcSrc, 0, 0, 0, 0, blend), TRUE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > + > +#if 0 > + /* zero source HDC - crashes on wine, works on native */ > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, NULL, 0, 0, 20, 20, blend), FALSE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > +#endif > + > expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, 0, 0, 20, 20, blend), TRUE, BOOL, "%d"); > SetLastError(0xdeadbeef); > expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, -1, 0, 10, 10, blend), FALSE, BOOL, "%d"); > -- > 1.5.6.5 > > > > >

2 1

Re: mfc42: Stub implementation with the message where to get it from
by Alexandre Julliard Sept. 9, 2009

Sept. 9, 2009

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > This is more of the testing waters type of patch. If this approach is > fine then we can do the same for all other dlls that are shipped with > Windows but not really a part of an O/S. I don't think you can put up a message box on attach, that could potentially become very annoying since it will trigger also for version checks etc. That sort of thing should be done at the loader level. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: gdi32: Handle OEM_CHARSET
by Dmitry Timoshkov Sept. 9, 2009

Sept. 9, 2009

"Vladimir Pankratov" <scriptkid(a)mail.ru> wrote: > --- a/dlls/gdi32/freetype.c 2009-08-08 13:27:23.000000000 +0500 > +++ b/dlls/gdi32/freetype.c 2009-09-07 19:58:58.000000000 +0500 > @@ -3576,6 +3576,7 @@ > if(!TranslateCharsetInfo((DWORD*)(INT_PTR)lf.lfCharSet, &csi, TCI_SRCCHARSET)) { > switch(lf.lfCharSet) { > case DEFAULT_CHARSET: > + case OEM_CHARSET: > csi.fs.fsCsb[0] = 0; > break; > default: How is this different from the default case? -- Dmitry.

2 1

Re: [PATCH 02/10] d3d10: Implement annotation parsing.
by Henri Verbeet Sept. 9, 2009

Sept. 9, 2009

2009/9/9 Rico Schüller <kgbricola(a)web.de>: > -static void parse_fx10_annotation(const char **ptr) > +static HRESULT parse_fx10_annotation(struct d3d10_effect_variable *a, const char **ptr, const char *data) > { > - skip_dword_unknown(ptr, 3); > + DWORD offset; > + > + read_dword(ptr, &offset); > + TRACE("Annotation name at offset %#x.\n", offset); > + > + a->name = copy_name(data + offset); > + if (!a->name) > + { > + ERR("Failed to copy name.\n"); > + return E_OUTOFMEMORY; > + } > + TRACE("Annotation name: %s.\n", a->name); > + > + read_dword(ptr, &offset); > + TRACE("Annotation type info at offset %#x.\n", offset); > + > + a->type = get_fx10_type(a->effect, data, offset); > + if (!a->type) > + { > + ERR("Failed to get variable type.\n"); > + return E_FAIL; > + } > + > + skip_dword_unknown(ptr, 1); > + > + return S_OK; > } It seems to me that this is just the same code for parsing variables (that has implications for 1/10 as well).

2 1

Re: msxml3: Add IDispatchEx support to IXMLDOMElement (resend 2)
by Alexandre Julliard Sept. 9, 2009

Sept. 9, 2009

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi, > Feedback if something is wrong would be great. domdoc.c:601: warning: ISO C90 forbids mixed declarations and code -- Alexandre Julliard julliard(a)winehq.org

1 0

Google Summer of Code mentor summit Oct 24th-25th
by Kai Blin Sept. 9, 2009

Sept. 9, 2009

Hi folks, Wine gets to send two delegates to the Google Summer of Code mentor summit in Mountain View, CA, this October. Is anybody who mentored interested in going? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0