April 2011 - Wine-Devel - list.winehq.org

Re: [2/4] wined3d: Track when the FBO is dirty.

by Adam Martinson

On 03/27/2011 06:45 AM, Henri Verbeet wrote: > On 21 March 2011 21:57, Adam Martinson<amartinson(a)codeweavers.com> wrote: >> @@ -2102,6 +2121,7 @@ BOOL context_apply_clear_state(struct wined3d_context *context, IWineD3DDeviceIm >> if (rt_count< context->gl_info->limits.buffers) >> memset(context->blit_targets + rt_count, 0, (context->gl_info->limits.buffers - rt_count) * sizeof(*rts)); >> context_apply_fbo_state(context, GL_FRAMEBUFFER, rt_count, context->blit_targets, depth_stencil, SFLAG_INTEXTURE); >> + context->device_fbo = context->current_fbo; > You can't do that. > >> @@ -4801,6 +4801,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_Clear(IWineD3DDevice *iface, DWORD rect >> } >> >> device_get_draw_rect(device,&draw_rect); >> + IWineD3DDeviceImpl_MarkFBODirty(device); > What is this for? > >> +static inline void IWineD3DDeviceImpl_MarkFBODirty(IWineD3DDeviceImpl *This) > This doesn't need to be in wined3d_private.h, it's only used from device.c. > >> + int i; >> + for (i = 0; i< This->numContexts; ++i) > numContexts is unsigned. > > What would happen when the current draw fbo entry would get evicted > from the cache? Also, while the patch avoids redundant lookups for > draws, it doesn't do a lot for clears. Is that intentional because > it's not worth it, or is there a different reason for that? I think I've addressed all of these... attached try #2.

April 7, 2011

__CxxFrameHandler unsupported on wine64?

by Peter Urbanec

I have an application that requires MFC80.DLL. When I install only the MFC80.DLL file from the vcredist package, I end up with the following errors: wine: Call from 0x7fd606a3148b to unimplemented function MSVCR80.dll.__CxxFrameHandler, aborting So, I had a quick look at the wine source and found a comment in dlls/msvcrt/cppexcept.c that says: /* CxxFrameHandler is not supported on non-i386 */ I don't think that this is quite right, given that Microsoft's MFC80.DLL attempts to call __CxxFrameHandler. Is it more likely that wine only provides an i386 implementation? If so, is there any chance that someone may be able to provide x86_64 implementation in the near future? It's way over my head :-( Best regards, Peter Urbanec

April 7, 2011

Re: [PATCH 2/6] winmm: DriverCallback ignores a 0 CALLBACK_WINDOW.

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > - I thought about merging patches 2+3+5 into one or two. After all, > they all change the one tiny DriverCallback function. > E.g. patch 2 fixes the corner case where Wine delivers a spurious > message to the thread message queue, while patch 5 generalizes > the behaviour that MS mentions (and I tested), i.e. ignore any 0 dwCallback. > OTOH, split is split. They have to be merged somehow, it doesn't make sense to add code that gets removed again in the next patch. -- Alexandre Julliard julliard(a)winehq.org

April 7, 2011

[PATCH 2/6] winmm: DriverCallback ignores a 0 CALLBACK_WINDOW.

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, any feedback on winmm:DriverCallback patches 2-6? - Although I superseded patch 1/6, the others are unchanged, hence I did not resend them. - I thought about merging patches 2+3+5 into one or two. After all, they all change the one tiny DriverCallback function. E.g. patch 2 fixes the corner case where Wine delivers a spurious message to the thread message queue, while patch 5 generalizes the behaviour that MS mentions (and I tested), i.e. ignore any 0 dwCallback. OTOH, split is split. - It may seem weird to go to some effort to make DriverCallback return the exact same values as native *and* then change all drivers to ignore that value, so the patches may be considered superfluous. Yet we strive to be bug-compatible. Regards, Jörg Höhle

April 7, 2011

Re: [PATCH 1/2] ntdll: Restore stack guard and prevent stack from shrinking

by Alexandre Julliard

Piotr Caban <piotr.caban(a)gmail.com> writes: > It happens when native _resetstkoflw is called when there's little > memory left on the stack. I don't know if there's any real application > that is calling it in that case. I thought that it's incorrect to grow > the stack size above stack limit anyway. No, the stack limit indicates the limit of the current growth. If the stack grows the limit is updated. -- Alexandre Julliard julliard(a)winehq.org

April 7, 2011

Re: [PATCH 1/2] ntdll: Restore stack guard and prevent stack from shrinking

by Piotr Caban

On 04/07/11 11:22, Alexandre Julliard wrote: > Piotr Caban<piotr.caban(a)gmail.com> writes: > >> Without this patch there's following condition for stack growing: >> if ((char *)page + page_size == NtCurrentTeb()->Tib.StackLimit) >> NtCurrentTeb()->Tib.StackLimit = page; >> If after growing the stack application protects the memory between >> StackLimit and StackLimit-page_size, StackLimit will be changed again. > > StackLimit is supposed to be the last address that is unprotected, so > changing it in that case would be correct. The last page should really > to remain protected though, which application is modifying it? > It happens when native _resetstkoflw is called when there's little memory left on the stack. I don't know if there's any real application that is calling it in that case. I thought that it's incorrect to grow the stack size above stack limit anyway.

April 7, 2011

Re: [PATCH 1/2] ntdll: Restore stack guard and prevent stack from shrinking

by Alexandre Julliard

Piotr Caban <piotr.caban(a)gmail.com> writes: > Without this patch there's following condition for stack growing: > if ((char *)page + page_size == NtCurrentTeb()->Tib.StackLimit) > NtCurrentTeb()->Tib.StackLimit = page; > If after growing the stack application protects the memory between > StackLimit and StackLimit-page_size, StackLimit will be changed again. StackLimit is supposed to be the last address that is unprotected, so changing it in that case would be correct. The last page should really to remain protected though, which application is modifying it? -- Alexandre Julliard julliard(a)winehq.org

April 7, 2011

Re: [PATCH 1/2] ntdll: Restore stack guard and prevent stack from shrinking

by Piotr Caban

On 04/07/11 11:00, Alexandre Julliard wrote: > Piotr Caban<piotr.caban(a)gmail.com> writes: > >> It's not needed (I thought it may be not valid for whole stack). I'll >> send fixed version. >> >> There also should be "growing" instead of "shrinking" in commit >> message. It was meant to point that it's possible to change StackLimit >> more then once without this patch. > > I'm not sure what you mean, making it grow is the reason for that > function. > Without this patch there's following condition for stack growing: if ((char *)page + page_size == NtCurrentTeb()->Tib.StackLimit) NtCurrentTeb()->Tib.StackLimit = page; If after growing the stack application protects the memory between StackLimit and StackLimit-page_size, StackLimit will be changed again.

April 7, 2011

Re: [PATCH 1/2] ntdll: Restore stack guard and prevent stack from shrinking

by Alexandre Julliard

Piotr Caban <piotr.caban(a)gmail.com> writes: > It's not needed (I thought it may be not valid for whole stack). I'll > send fixed version. > > There also should be "growing" instead of "shrinking" in commit > message. It was meant to point that it's possible to change StackLimit > more then once without this patch. I'm not sure what you mean, making it grow is the reason for that function. -- Alexandre Julliard julliard(a)winehq.org

April 7, 2011

Re: [PATCH 1/2] ntdll: Restore stack guard and prevent stack from shrinking

by Piotr Caban

On 04/07/11 10:24, Alexandre Julliard wrote: > Piotr Caban<piotr(a)codeweavers.com> writes: > >> @@ -1617,9 +1617,18 @@ BOOL virtual_handle_stack_fault( void *addr ) >> BYTE vprot = view->prot[((const char *)page - (const char *)view->base)>> page_shift]; >> if (vprot& VPROT_GUARD) >> { >> + struct _TEB *teb = NtCurrentTeb(); >> VIRTUAL_SetProt( view, page, page_size, vprot& ~VPROT_GUARD ); >> - if ((char *)page + page_size == NtCurrentTeb()->Tib.StackLimit) >> - NtCurrentTeb()->Tib.StackLimit = page; >> + if ((char *)page - page_size == teb->DeallocationStack) >> + teb->Tib.StackLimit = page; >> + else if ((char*)addr> (char*)teb->Tib.StackLimit + page_size&& >> + teb->Tib.StackLimit == (char*)teb->DeallocationStack + page_size&& >> + (view = VIRTUAL_FindView( (char*)teb->Tib.StackLimit, 0))) >> + { >> + vprot = view->prot[((char*)teb->Tib.StackLimit - (char*)view->base)>> page_shift]; >> + VIRTUAL_SetProt( view, teb->Tib.StackLimit, page_size, vprot | VPROT_GUARD); >> + teb->Tib.StackLimit = (char*)teb->Tib.StackLimit + page_size; >> + } > > Why do you want to lookup the view again? It's not needed (I thought it may be not valid for whole stack). I'll send fixed version. There also should be "growing" instead of "shrinking" in commit message. It was meant to point that it's possible to change StackLimit more then once without this patch.

April 7, 2011