September 2009 - Wine-Devel

Re: [ntdll] Add tests for NtQueryInformationFile
by Paul Vriens Sept. 11, 2009

Sept. 11, 2009

On 09/09/2009 02:41 PM, Dan Kegel wrote: > Alexandre said I should break up the big xattr patch, > so here are just the NtQueryInformationFile tests, > improved a bit. Once these are in I'll submit the > NtQueryDirectoryFile tests. > > Passes on both Wine and Vista. > > > ------------------------------------------------------------------------ > > Hi Dan, This patch introduces some issues on NT4 and higher. Attached patch fixes it but I'm not sure if you are already chasing these failures. Weird that it doesn't fail on your Vista box. That remark "whoops, vista doesn't implement this one?\n" should probably be changed. It also looks like Vista/Win7 has either 2 or 4 failures (most likely related to indexing being disabled, if so that could also happen on other platforms). Not sure if we should explicitly check for attributes being 2020, ignore FILE_ATTRIBUTE_NOT_CONTENT_INDEXED or just check as I did. -- Cheers, Paul.

2 4

Mirror Space
by Marty Cannon Sept. 11, 2009

Sept. 11, 2009

Hey guys, Since the wine.budgetdedicated.com server was down all weekend, I thought I'd offer an additional mirror location. I currently mirror several major linux distributions, and would love to contribute to something as valuable to the community as the wine project is. My site currently runs around 3500GB per month, so a few hundred GB worth of transfer shouldn't make much difference. I've never set up an apt mirror, but with some instruction and googling, I bet I can do it. At the very least, I can mirror the package archive just incase the main site goes down. Let me know how I can help. -Marty Cannon amarillolinux.com

6 12

Fixing the user32/dde tests on Win9x/WinMe
by Paul Vriens Sept. 11, 2009

Sept. 11, 2009

Hi, DdeInitializeW is not implemented on the mentioned platforms but it's not just a matter of skipping some tests when that W-function is found to be not implemented. Any idea what the best way would be to fix these tests? -- Cheers, Paul.

1 0

Re: bitblt.c - GdiAlphaBlend : Check for NULL Pointer
by Roderick Colenbrander Sept. 11, 2009

Sept. 11, 2009

Recently Nikolay Sivov wrote some tests for this call. His tests didn't make it in yet but I think those should enter and then based on those results changes should be made. Roderick On Thu, Sep 10, 2009 at 10:56 PM, Markus Stockhausen <markus.stockhausen(a)collogia.de> 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 > > > > >

4 7

Status of LoadLibrary and .so
by Joe Dluzen Sept. 11, 2009

Sept. 11, 2009

Hi all, back a few years ago it didn't: http://www.winehq.org/pipermail/wine-devel/2003-July/018498.html Does anyone know of the status of LoadLibrary and a .so? Can it load directly or is there a workaround that does not involve multiple processes and some sort of IPC? thanks, Joe

3 2

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

Sept. 11, 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