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

Re: [PATCH 4/5] wined3d: Merge the IWineD3DSwapChain::Destroy() implementations.
by Alexandre Julliard 08 Apr '11

08 Apr '11

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > They're mostly the same, except for the GL version also destroying its > contexts, and being a bit more careful about the order in which backbuffers > are destroyed. > --- > dlls/wined3d/swapchain.c | 175 ++++++++++++++++----------------------------- > 1 files changed, 62 insertions(+), 113 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so ddrawmodes.c && touch ddrawmodes.ok wine: Unhandled page fault on read access to 0x00000f2c at address 0x687550fa (thread 0021), starting debugger... Unhandled exception: page fault on read access to 0x00000f2c in 32-bit code (0x687550fa). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:687550fa ESP:0032f910 EBP:0032f948 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000021 EBX:6884b244 ECX:00110064 EDX:00000000 ESI:00000000 EDI:00000001 Stack dump: 0x0032f910: 00001302 00131ef0 00000000 00000000 0x0032f920: 00000000 00000000 00000000 00110014 0x0032f930: 0000ff00 000000ff 687550db 6884b244 0x0032f940: 00131848 00000001 0032f9a8 6880052b 0x0032f950: 00134d58 00000000 00131ef0 7bc73cfc 0x0032f960: 00000002 00129f28 00000000 000004b0 Backtrace: =>0 0x687550fa context_destroy+0x2a(This=0x134d58, context=(nil)) [/home/julliard/wine/wine/dlls/wined3d/context.c:1615] in wined3d (0x0032f948) 1 0x6880052b IWineD3DBaseSwapChainImpl_Destroy+0x18a(iface=0x131848) [/home/julliard/wine/wine/dlls/wined3d/swapchain.c:65] in wined3d (0x0032f9a8) 2 0x688006a1 IWineD3DBaseSwapChainImpl_Release+0x40(iface=0x131848) [/home/julliard/wine/wine/dlls/wined3d/swapchain.c:125] in wined3d (0x0032f9e8) 3 0x686d25b9 D3D7CB_DestroySwapChain+0x58(swapchain=0x131848) [/home/julliard/wine/wine/dlls/ddraw/ddraw.c:2621] in ddraw (0x0032fa18) 4 0x6875d317 IWineD3DDeviceImpl_UninitGDI+0x66(iface=0x134d58, D3DCB_DestroySwapChain=0x686d2560) [/home/julliard/wine/wine/dlls/wined3d/device.c:2300] in wined3d (0x0032fa78) 5 0x686f8f6e ddraw_surface7_Release+0x1cd(iface=0x129f28) [/home/julliard/wine/wine/dlls/ddraw/surface.c:396] in ddraw (0x0032fad8) 6 0x68689c21 func_ddrawmodes+0x2720() [/home/julliard/wine/wine/dlls/ddraw/tests/ddrawmodes.c:583] in ddraw_test (0x0032fd38) 7 0x686adc9e run_test+0x14d(name="ddrawmodes.c") [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:556] in ddraw_test (0x0032fd88) 8 0x686ae767 main+0x156(argc=0xffffffff, argv=(nil)) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:624] in ddraw_test (0x0032fe48) 9 0x686ae93c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ddraw_test (0x0032fe90) 10 0x7b859a6c call_process_entry+0xb() in kernel32 (0x0032fea8) 11 0x7b85a69f start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1086] in kernel32 (0x0032fee8) 12 0x7bc74c78 call_thread_func+0xb() in ntdll (0x0032fef8) 13 0x7bc776b0 call_thread_entry_point+0x6f(entry=0x7b85a640, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffc8) 14 0x7bc4d27a start_process+0x29(kernel_start=0x7b85a640) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2606] in ntdll (0x0032ffe8) 15 0x6802996d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 0x687550fa context_destroy+0x2a [/home/julliard/wine/wine/dlls/wined3d/context.c:1615] in wined3d: cmpl %eax,0xf2c(%esi) 1615 if (context->tid == GetCurrentThreadId() || !context->current) -- Alexandre Julliard julliard(a)winehq.org

2 1

ntdll: Remove more path trailing chars.
by Joerg-Cyril.Hoehle＠t-systems.com 08 Apr '11

08 Apr '11

Hi, Juan Lang wrote: >Vincent Pelletier wrote: >> Those tests are boolean, so I doubt an "ok(pass || fail /* NT4 */)" makes any >> sense. >> I saw that it is discouraged (forbidden ?) to depend on OS version in tests, >> so I will avoid that path unless asked to follow it. >You'd want to use "ok(pass || broken(fail /* NT4 */)". No! Juan, while you generally give excellent advice, please think again about that one suggestion. It means tests never fail on native, which renders the test useless. What I've been doing several times is to write a detector and have the tests expect the specific NT/non-NT value. static BOOL TrueButNT = TRUE; Don't query OS version! Instead, the first test that sees the difference in behaviour does this: ok(rc == DO || broken(rc == DONT /* NT */), "bla\n"); TrueButNT = (rc==DONT) ? FALSE : TRUE; All later tests use ok(rc == TrueButNT, "bla2\n"); It even works with todo_wine. Any other means to detect NT *that is relevant for your test* is fine, i.e. don't query the DLL version or use some function outside of your test domain. Typical detectors are different GetLastError() values. I call this "coherence testing". Regards, Jörg Höhle

2 1

Re: wine.inf: Add shell handler for .url files.
by Jacek Caban 08 Apr '11

08 Apr '11

Hi Hans, On 4/8/11 9:22 AM, Hans Leidekker wrote: > diff --git a/tools/wine.inf.in b/tools/wine.inf.in > index d4a457b..048b5bb 100644 > --- a/tools/wine.inf.in > +++ b/tools/wine.inf.in > @@ -161,6 +161,7 @@ HKCR,.lnk,,2,"lnkfile" > HKCR,.msi,,2,"Msi.Package" > HKCR,.msp,,2,"Msi.Patch" > HKCR,.rtf,,2,"rtffile" > +HKCR,.url,,2,"InternetShortcut" > HKCR,.wri,,2,"wrifile" I'm not sure about other changes, but this should go to shdocvw. I have a patch in my queue for that. Jacek

1 0

Re: wine.inf: Add shell handler for .url files.
by Damjan Jovanovic 08 Apr '11

08 Apr '11

On Fri, Apr 8, 2011 at 9:22 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > See http://bugs.winehq.org/show_bug.cgi?id=26673 > --- > tools/wine.inf.in | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/tools/wine.inf.in b/tools/wine.inf.in > index d4a457b..048b5bb 100644 > --- a/tools/wine.inf.in > +++ b/tools/wine.inf.in > @@ -161,6 +161,7 @@ HKCR,.lnk,,2,"lnkfile" > HKCR,.msi,,2,"Msi.Package" > HKCR,.msp,,2,"Msi.Patch" > HKCR,.rtf,,2,"rtffile" > +HKCR,.url,,2,"InternetShortcut" > HKCR,.wri,,2,"wrifile" > HKCR,chm.file,,2,"Compiled HTML Help File" > HKCR,chm.file\shell\open\command,,2,"%10%\hh.exe %1" > @@ -215,21 +216,25 @@ HKCR,xmlfile\shell\open\ddeexec,,2,"""%1"",,-1,0,,,," > HKCR,xmlfile\shell\open\ddeexec,"NoActivateHandler",2,"" > HKCR,xmlfile\shell\open\ddeexec\Application,,2,"IExplore" > HKCR,xmlfile\shell\open\ddeexec\Topic,,2,"WWW_OpenURL" > +HKCR,ftp,"URL Protocol",2,"" > HKCR,ftp\shell\open\command,,2,"%11%\winebrowser.exe -nohome" > HKCR,ftp\shell\open\ddeexec,,2,"""%1"",,-1,0,,,," > HKCR,ftp\shell\open\ddeexec,"NoActivateHandler",2,"" > HKCR,ftp\shell\open\ddeexec\Application,,2,"IExplore" > HKCR,ftp\shell\open\ddeexec\Topic,,2,"WWW_OpenURL" > +HKCR,http,"URL Protocol",2,"" > HKCR,http\shell\open\command,,2,"%11%\winebrowser.exe -nohome" > HKCR,http\shell\open\ddeexec,,2,"""%1"",,-1,0,,,," > HKCR,http\shell\open\ddeexec,"NoActivateHandler",2,"" > HKCR,http\shell\open\ddeexec\Application,,2,"IExplore" > HKCR,http\shell\open\ddeexec\Topic,,2,"WWW_OpenURL" > +HKCR,https,"URL Protocol",2,"" > HKCR,https\shell\open\command,,2,"%11%\winebrowser.exe -nohome" > HKCR,https\shell\open\ddeexec,,2,"""%1"",,-1,0,,,," > HKCR,https\shell\open\ddeexec,"NoActivateHandler",2,"" > HKCR,https\shell\open\ddeexec\Application,,2,"IExplore" > HKCR,https\shell\open\ddeexec\Topic,,2,"WWW_OpenURL" > +HKCR,mailto,"URL Protocol",2,"" > HKCR,mailto\shell\open\command,,2,"%11%\winebrowser %1" > ; FIXME: the following should be done by the dll registration > HKCR,TypeLib\{00020430-0000-0000-C000-000000000046}\1.0\0\win16,,,"stdole.tlb" > -- Aren't most Internet-related file associations created by dlls/mshtml/mshtml.inf instead of tools/wine.inf.in, and should we maybe change that or move your patch there? Damjan

2 1

Re: riched20: Remove the unneeded DEFINE_STDCALL_WRAPPER.
by Dylan Smith 08 Apr '11

08 Apr '11

On Thu, Apr 7, 2011 at 5:30 AM, Michael Stefaniuc <mstefani(a)redhat.de>wrote: > The COM methods are already __stdcall. > --- > dlls/riched20/txthost.c | 128 > ++++++++++++++-------------------------------- > 1 files changed, 39 insertions(+), 89 deletions(-) > > COM methods are supposed to use the stdcall calling convention, but the native riched20 and the native headers just defines ITextHost and ITextServices to be a c++ class (i.e. using the thiscall calling convention). Just look at the native TextServ.h header.

4 6

Google Summer of Code project
by Michał Ziętek 07 Apr '11

07 Apr '11

Hello, My name is Michal Zietek, I am studying Computer Science at Wroclaw University of Technology. I would like to take part at Google Summer of Code. Lately I saw Jacek Caban presenting Wine at the university and he said there could be a possibility to start in Google Summer of Code and work on Wine. I talked to Jacek about project related to WScript. I am interested in working on this project but I can't find it on the Google Summer of Code website. The only place I found any information is http://www.winehq.org/pipermail/wine-devel/2011-February/088839.html Do you consider putting this project into Google Summer of Code? Best regards, Michal Zietek.

4 3

Re: [2/4] wined3d: Track when the FBO is dirty.
by Henri Verbeet 07 Apr '11

07 Apr '11

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?

2 4

[PATCH 2/6] winmm: DriverCallback ignores a 0 CALLBACK_WINDOW.
by Joerg-Cyril.Hoehle＠t-systems.com 07 Apr '11

07 Apr '11

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

2 1

Re: [PATCH 1/2] ntdll: Restore stack guard and prevent stack from shrinking
by Alexandre Julliard 07 Apr '11

07 Apr '11

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? -- Alexandre Julliard julliard(a)winehq.org

2 6

Re: gsoc theming
by Reece Dunn 07 Apr '11

07 Apr '11

On 4 April 2011 13:08, Andrew Green <greeniekin(a)gmail.com> wrote: > Hi, > I hate to message you on this email. I have messaged the mailing > lists. Though I became more confused than anything. Can you please keep the discussions on the mailing list? Thanks. > I would like to propose a project where comctl32 is implement > correctly in windows for google summer of code. > As far as i know windows uses SxS to load version 6 of comctl allowing > theming. This is correct -- an application needs to add a manifest file to tell it to load version 6 of the comctl32 DLL in order to get theming support on Windows. > It also uses windows class redirection to hijack controls > from user32 to be themed(I don't know if it somehow uses subclassing). This is how it is implemented in wine. > The confusing thing on the mailing list i was told not to make a > separate version of comctl32. Which is understandable from a code > maintenance point of view. Though contradicts what the gsoc ideas page > says > "control is overridden by a themed drawing version by subclassing. > This is not the way it is implemented on Windows and this causes > drawing issues and other nasty issues." > As someone who is to be a mentor of this section. What is the goal? > and if subclassing is the option, how is this meant to work? There isn't a contradition. AFAICS, the subclassing works -- the subclassed window procedure gets called correctly. The drawing issues can be seen clearly on the button controls -- if the button changes state (enabled <-> disabled, pressed, etc.) then it gets drawn without theming. This is because the button control in Wine does not call WM_PAINT to do the drawing, which the themed button overrides. Therefore, you will need to either: 1/ convince Alexandre through tests that these tests do call WM_PAINT [*] and update the non-themed control accordingly; or 2/ implement the state tracking/logic in the themed button and have it call WM_PAINT [*]. [*] or the correct custom drawing messages. HTH, - Reece

3 2