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

Re: [PATCH 1/5] ddraw/tests: Test P8 to RGB blits (try 3).

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6624 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2.c:5096: Test failed: Got unexpected refcount 3. ddraw2.c:5115: Test failed: Got unexpected refcount 3. ddraw2.c:5122: Test failed: Got unexpected hr 0. ddraw2.c:5125: Test failed: Got unexpected refcount 3. ddraw2.c:5127: Test failed: Got unexpected refcount 2. ddraw2.c:5133: Test failed: Got unexpected hr 0. ddraw2.c:5136: Test failed: Got unexpected refcount 2. ddraw2.c:5138: Test failed: Got unexpected refcount 1. === w864 (32 bit ddraw1) === ddraw1.c:3991: Test failed: Got unexpected refcount 3. ddraw1.c:4010: Test failed: Got unexpected refcount 3. ddraw1.c:4017: Test failed: Got unexpected hr 0. ddraw1.c:4020: Test failed: Got unexpected refcount 3. ddraw1.c:4022: Test failed: Got unexpected refcount 2. ddraw1.c:4028: Test failed: Got unexpected hr 0. ddraw1.c:4031: Test failed: Got unexpected refcount 2. ddraw1.c:4033: Test failed: Got unexpected refcount 1. === wxppro (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 00247AE8. ddraw7: unhandled exception c0000005 at 0045EB6B === wvista (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 00264A78. ddraw7: unhandled exception c0000005 at 0045EB6B === w2008s64 (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 005CFE60. ddraw7: unhandled exception c0000005 at 0045EB6B === w7u (32 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 00000000, expected 007ABEB8. ddraw7: unhandled exception c0000005 at 0045EB6B === w864 (32 bit ddraw7) === ddraw7.c:5629: Test failed: Got unexpected refcount 3. ddraw7.c:5648: Test failed: Got unexpected refcount 3. ddraw7.c:5655: Test failed: Got unexpected hr 0. ddraw7.c:5658: Test failed: Got unexpected refcount 3. ddraw7.c:5660: Test failed: Got unexpected refcount 2. ddraw7.c:5666: Test failed: Got unexpected hr 0. ddraw7.c:5669: Test failed: Got unexpected refcount 2. ddraw7.c:5673: Test failed: Got unexpected refcount 6. ddraw7.c:5790: Test failed: Failed to set cooperative level, hr 0x8876023b. === w2008s64 (64 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 0000000000000000, expected 0000000000732980. ddraw7: unhandled exception c0000005 at 0000000000454891 === w864 (64 bit ddraw7) === ddraw7.c:5652: Test failed: Got unexpected palette 0000000000000000, expected 00000000006C77A0. ddraw7: unhandled exception c0000005 at 0000000000454891 === w864 (32 bit ddraw4) === ddraw4.c:5756: Test failed: Got unexpected refcount 3. ddraw4.c:5775: Test failed: Got unexpected refcount 3. ddraw4.c:5782: Test failed: Got unexpected hr 0. ddraw4.c:5785: Test failed: Got unexpected refcount 3. ddraw4.c:5787: Test failed: Got unexpected refcount 2. ddraw4.c:5793: Test failed: Got unexpected hr 0. ddraw4.c:5796: Test failed: Got unexpected refcount 2. ddraw4.c:5798: Test failed: Got unexpected refcount 1. ddraw4.c:5800: Test failed: Got unexpected refcount 6. ddraw4.c:5920: Test failed: Failed to set cooperative level, hr 0x8876023b. ddraw4.c:5959: Test failed: Failed to attach surface, hr 0x887600e1. ddraw4.c:5962: Test failed: Got unexpected hr 0. ddraw4.c:5964: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5967: Test failed: Failed to attach surface, hr 0x887601c2. ddraw4.c:5970: Test failed: Got unexpected hr 0x887601c2. ddraw4.c:5972: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5975: Test failed: Failed to attach surface, hr 0x887601c2. ddraw4.c:5977: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:5980: Test failed: Got unexpected hr 0x887600e1. ddraw4.c:5982: Test failed: Got unexpected hr 0x887601c2.

April 28, 2014

Re: mshtml: Renamed nsIDOMHTMLSelectElement::Remove to select_Remove to avoid conflict with nsIDOMElement.

by Jacek Caban

On 04/28/14 14:06, Zhenbo Li wrote: > Thanks, Jacek > This patch should fix that problem, but would it hide the problem in widl? > > I tried midl.exe with VS, and got > #define nsIDOMHTMLSelectElement_Remove(This,index) \ > ( (This)->lpVtbl -> Remove(This,index) ) > > Then why widl can't handle this situation? I tested midl on a simpler case and it will output two different macros for that as well as two entries in vtbl. This will cause a conflict during compilation (in C, it's perfectly fine for C++). widl produces only one macro (see commit 65f418493683d96d4fd625ab019ea400eec4c19a), so that the header is at least valid in such case. There is not much more we can do. Jacek

April 28, 2014

Re: mshtml: Renamed nsIDOMHTMLSelectElement::Remove to select_Remove to avoid conflict with nsIDOMElement.

by Zhenbo Li

Thanks, Jacek This patch should fix that problem, but would it hide the problem in widl? I tried midl.exe with VS, and got #define nsIDOMHTMLSelectElement_Remove(This,index) \ ( (This)->lpVtbl -> Remove(This,index) ) Then why widl can't handle this situation? 2014-04-28 18:17 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > Spotted by Zhenbo Li. > > --- > dlls/mshtml/nsiface.idl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > -- Have a nice day! Zhenbo Li

April 28, 2014

Re: Fixing conflicts between WineD3D and WGL

by Jerome Leclanche

Hi Ken Your patchset causes X11 errors with the Battle.net client. 100% reproducible, and also crashes within explorer.exe with +synchronous. I thought it was something else at first due to a bad revert and filed the details here: https://bugs.winehq.org/show_bug.cgi?id=36141 You can download the Battle.net Client here: https://us.battle.net/account/download/ J. Leclanche On Thu, Apr 24, 2014 at 4:29 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > Hi, > > On Apr 23, 2014, at 4:13 PM, Stefan Dösinger wrote: > >> I tested this a little bit sooner than expected, thanks to a >> regression in Starcraft and Age of Empires 2. (Looks like bugs 35950 >> and 35655). > > Thanks for testing! > >> The good news is that your patches fix the regressions in those games. > > Nice. > >> Am 2014-04-21 17:49, schrieb Ken Thomases: >>> * Full-screen games are actually full-screen, appearing in front >>> of other apps, docks, panels, menus, taskbars, etc. >> Kde 4.11.5 here. The fullscreen apps indeed appear fullscreen. But >> once Starcraft was shifted down and only showing the top ~50 pixels at >> the bottom of the screen. > > Strange. The only positioning of the full-screen windows that the code ever does is moving it to get_primary_rect() converted from Win32 virtual screen coordinates to root coordinates. > >> Inside a virtual desktop Age of Empires 2 seemed to snap into place >> after a resolution change. It first rendered at the bottom of the >> screen and after ~0.5 seconds the rendering was correct. > > Yes, the code watches for root window configuration changes and repositions itself when that happens. It tries to keep itself filling the screen. The delay was probably because the app didn't return to processing events for a bit. I think I can improve that by hooking into X11DRV_resize_desktop(). > > When it's managed (not in a virtual desktop window), it also sets _NET_WM_STATE_FULLSCREEN which should lead the window manager to keep it in position. > > >>> * But you can switch to another app as well/easily as you could >>> without these patches. Full-screen games don't take over your >>> whole display such that you can't escape without drastic measures. >> Alt-Tab does not work. The game loses focus and stops redrawing, but >> my other apps don't show up. Switching to a different virtual desktop >> works. I don't know if this worked in the past with those two games, >> probably not. I'll retest with plain Wine, as far as the regressions >> allow. > > My understanding is that most window managers only keep _NET_WM_STATE_FULLSCREEN windows over everything else as long as they have focus. Did the desktop environment's panels, docks, taskbars, etc. show up when the game lost focus? > > The problem may be that I also set _NET_WM_STATE_ABOVE. That's what happens for a WS_EX_TOPMOST window, which wined3d used to use prior to my patches, so I emulated that. > > >>> * After switching away, you can switch back successfully. >> I have to select the Wine window. If I select the game window, Wine's >> rendering window does not take over. > > I have an additional patch that may fix that. Please try applying <http://www.codeweavers.com/xfer/ken/wgl_wine_surface/wgl_surface_fixes_and_…> on top of the other patches. > > The main thing it does for this issue is set WM_HINTS.window_group to be the device window. That should convince KDE to allow it to "steal" focus from the device window. (I think what you were encountering is KDE's focus stealing prevention feature.) > > I've also reordered setting focus vs. raising the window. And I'm trying a _NET_ACTIVATE_WINDOW request on top of all that. > > It also adds a bunch of additional logging for diagnosing other issues. > > -Ken > > >

April 28, 2014

Re: [draft patch] atl100/tests: Added more tests for AtlAxWin{, Lic} procedure.

by Qian Hong

Hello, Please ignore this, there is one bug in the code. I've had more tests recent days, I'll update my new result later. Now I found even more incompatible between atl80 and atl100.. The ATL_PROPMAP_ENTRY struct is different between atl80 and atl100, but it is undocumented... What a crazy fun black box testing to figure out this! :)

April 28, 2014

Re: mshtml: Added IHTMLTable::width property implementation. (try 5)

by Jacek Caban

Hi Zhenbo, This looks better, but there are two more things I didn't catch earlier. On 04/27/14 15:08, Zhenbo Li wrote: > + nsres = nsIDOMHTMLTableElement_GetWidth(This->nstable, &val); > + if (NS_FAILED(nsres)){ > + ERR("Get Width(%s) failed!\n", debugstr_variant(p)); You can't access output argument (p) here. This will be undefined. > + nsAString_Finish(&val); > + return E_FAIL; > + } > + > + hres = nsstr_to_truncated_bstr(&val, &bstr); > + > + V_VT(p) = VT_BSTR; > + V_BSTR(p) = bstr; > + return hres; You leak val here. Jacek

April 28, 2014

Re: [RFC 1/11] Linux FF: Joystick control panel program

by Elias Vanderstuyft

Hi, I've got an additional question about EnumEffects(): Why does the JoystickWImpl_EnumEffects() variant add the additional code (in contrast with the 'A' function variant)? : int xfd = This->joyfd; -- snip -- /* return to unacquired state if that's where it was */ if (xfd == -1) IDirectInputDevice8_Unacquire(iface); Elias

April 27, 2014

Re: winex11.drv: merge the clipboard and drag-and-drop import functions

by André Hentschel

Am 27.04.2014 11:20, schrieb Damjan Jovanovic: > * Merges the X selection import functions used by the clipboard and > drag-and-drop, now allowing files to be copied-and-pasted from X11 > apps into Wine apps, and new types (eg. images) to be > dragged-and-dropped from X11 apps into Wine apps (instead of just > files and text like before). Also has the benefit of now allowing > drag-and-drop to use INCR for large data transfers. > * Fixes several memory leaks in xdnd.c > * Uses GlobalAlloc() instead of HeapAlloc() for STGMEDIUM's hGlobal. > * De-duplicates considerable shared code. Cool work, but this sounds like "needs splitting"...

April 27, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Christopher Thielen

Do you know of a method to watch texture load like this? I am able to find the spot in the executable where the cursor resource is loaded into a heap (and the address of that heap in the running process), but I am unable to link it to any particular texture create call. Perhaps there's a debugger which watches for memory access at certain locations? On 4/23/2014 1:59 AM, Stefan Dösinger wrote: > > Am 23.04.2014 um 09:15 schrieb Christopher Thielen <christopher(a)thielen.co>: >> Once the cursor data is loaded from bitmap16.flx to a heap, I never see a reference to that memory again, at least in an API trace. After various initializations, there are a lot of CreateTexture calls followed by LockRect ... UnlockRect. From reading around online, my guess is the game uploads textures using memcpy() while the rect is locked. Can anyone who knows a bit more about D3D confirm that's a probable method of uploading textures? > Correct. This is a common way to load textures. There are others, but they all involve LockRect and UnlockRect at some point. >

April 27, 2014

Re: mshtml: Added IHTMLTable::width property implementation. (try 4)

by Jacek Caban

On 04/26/14 16:38, Zhenbo Li wrote: > Hi Jacek, > > 2014-04-26 21:33 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: >> On 04/26/14 15:20, Zhenbo Li wrote: >>> 2014-04-26 20:44 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: >>>> Hi Zhenbo, >>>> >>>> This is better, but: >>>> >>>> On 04/26/14 05:12, Zhenbo Li wrote: >>>> >>>> + hres = var2str(&v, &val); >>>> + >>>> + if (hres != S_OK){ >>>> + ERR("Set Width(%s) failed when initializing a nsAString!\n", >>>> + debugstr_variant(&v)); >>>> + nsAString_Finish(&val); >>>> >>>> >>>> Again, this is not initialized in the error case. >>> As I've added >>>> + default: >>>> + nsAString_Init(nsstr, NULL); >>>> + FIXME("unsupported arg %s\n", debugstr_variant(p)); >>>> + return E_NOTIMPL; >>>> + } >>> Isn't it enough? >> I missed that change, but I think it's wrong. There are other error >> cases as well. nsAString_Init failure also leaves the string >> uninitialized (and it's on my TODO list to make sure that we may make >> nsAString_Init infailable, but that's a different story). It's also >> generally sane to expect that if a function fails, it's output parameter >> is not initialized. Please remove this new nsAString_Init call and >> nsAString_Finish in error case. >> > Thank you for your explanation. > How about this solution: > > + return nsAString_Init(nsstr, V_BSTR(p))? > + S_OK : E_OUTOFMEMORY; > + case VT_R8: > + hres = VarBstrFromR8(V_R8(p), 0, 0, &str); > + break; > + case VT_R4: > + hres = VarBstrFromR4(V_R4(p), 0, 0, &str); > + break; > + case VT_I4: > + hres = VarBstrFromI4(V_I4(p), 0, 0, &str); > + break; > + default: > + FIXME("unsupported arg %s\n", debugstr_variant(p)); > + hres = E_NOTIMPL; > + break; > + } > + if (FAILED(hres)) > + return hres; > + > + ret = nsAString_Init(nsstr, str); > + SysFreeString(str); > + return ret ? S_OK : E_OUTOFMEMORY; > +} This looks good. >>> Or you mean here? >>>> + ret = nsAString_Init(nsstr, str); >>>> + SysFreeString(str); >>>> + return ret ? S_OK : E_OUTOFMEMORY; >>> Should I free a string which failed when initializing due to out-of-memory? >> Which one? The way it's done currently is right. >> >>>> + >>>> + hres = nsstr_to_truncated_bstr(&val, &bstr); >>>> + if (FAILED(hres)) { >>>> + SysFreeString(bstr); >>>> >>>> >>>> And bstr is not initialized in error case. >>> The error case comes from >>>> + ret = end ? SysAllocStringLen(str, end-str) : SysAllocString(str); >>>> + if(!ret) >>>> + return E_OUTOFMEMORY; >>> I have the same question. >> Please read the code again. bstr is not initialized in this case, so you >> can't free it. > Sorry, I made a mistake. > When SysAllocString failes, should we mark bstr as NULL? > Like this: > > static HRESULT nsstr_to_truncated_bstr(const nsAString *nsstr, BSTR *ret_ptr) > { > //.... > ret = end ? SysAllocStringLen(str, end-str) : SysAllocString(str); > > *ret_ptr = ret; > return ret ? S_OK : E_OUTOFMEMORY; > } You don't need this... > static HRESULT WINAPI HTMLTable_get_width(IHTMLTable *iface, VARIANT *p) > { > //.... > hres = nsstr_to_truncated_bstr(&val, &bstr); > if (FAILED(hres)) > return hres; > //... > } ...once you change this. Jacek

April 26, 2014