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

Re: [PATCH 3/5] ddraw/tests: Handle a backbuffer palette misbehavior on Windows 8.
by Henri Verbeet April 29, 2014

April 29, 2014

On 28 April 2014 15:21, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * reference crashes. The primary has an extra reference after creation call, making > + * it tricky to destroy. Creating the primary adds 5 references to the ddraw interface, This is because of the 8 bpp display mode, I have a patch.

1 0

Re: [PATCH 2/5] ddraw: Implement D3DOP_STATERENDER on top of IDirect3DDevice3_SetRenderState().
by Stefan Dösinger April 29, 2014

April 29, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-04-29 10:41, schrieb Henri Verbeet: > + if (FAILED(IDirect3DDevice3_SetRenderState(&device->IDirect3DDevice2_iface, Is the use of IDirect3DDevice2_iface intentional? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTX3qrAAoJEN0/YqbEcdMwtacP/jW2hvsXFttAPKuQPjK1nLqI /EOKHK2V7p8kf9WrjvJfcy3WosiNVR3Z6WW0yF/EuF5rrqLw1zSGG0Go4WBTw5h3 DA7xDfnCZhIR9eNOnaxF9OWYaUzDI18/iEMlAVdxrVdpIJJBcrG5x/tWkklFzP9n gIS/LO3msAlTq3xeV96rXty+BYVt+iET2h49Iauw8NKJp9XGfn1a1DtSnY/LCBLV xzgTaKy1nym0Y8zI7xswzmqBsB2F0Mo8Rm7KlzHQz83lltFXS6Q1n/OyX/aVUg6R y8iM3H3gDpaeuykob+HuoEGU96JlYskPZFs94SYpdI0g5O2khM2znQ+qakJiI3ar KSa1DnudgN3eK8a735MUylas4P1IrwMRyMa8BXj5U7qN99WPkHyL0WeF+8JGD5JA A0d1Z/Ox+nA0V+4jFW6aSPeyIFI5BXSROltsDAztF4tjO16QPzMl9/tWOS8NeK23 9VEn/xqbg06oyHrTc5KKhi3u5NhUcoB5wXiTWUfmUftWEd91sUmwnvA/OHYPnAz3 xU1Fy/5E73LR1x5BJNRqZMmtKQxbRnmdMB7mf8wBJNqzt4oxzsqtVkVj1k5QOG/L WFUUmN6bL2iecLunNLo4jH8oPRujjUDW5kZHm4UCBPwtB+GecUMtP8rsSLVj++bu znfeqwAijofsnfpAL9Fa =Egcb -----END PGP SIGNATURE-----

2 1

Re: wtsapi32: Partial implementation of WTSEnumerateProcessesW (try 4)
by Stefan Leichter April 28, 2014

April 28, 2014

Hello, after this patch has left http://source.winehq.org/patches/ without any comment, i like to know what needs to be change to get this patch commited. Regards Stefan --- dlls/wtsapi32/tests/wtsapi.c | 1 - dlls/wtsapi32/wtsapi32.c | 65 ++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 63 insertions(+), 3 deletions(-)

1 0

Re: [PATCH 5/5] ddraw/tests: Test mipmap GetDC behavior.
by Marvin April 28, 2014

April 28, 2014

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=6629 Your paranoid android. === w2008s64 (64 bit ddraw7) === ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. === w864 (64 bit ddraw7) === ddraw7.c:6115: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. ddraw7.c:6428: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6493: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6558: Test failed: Failed to create surface, hr 0x80004002.

1 0

Fixing conflicts between WineD3D and WGL
by Ken Thomases April 28, 2014

April 28, 2014

Hi, This email brings together several threads of conversation that have been spread across different bug reports. Sorry for the length. The problem: WineD3D is based on WGL (a.k.a. opengl32). As a consequence, it conflicts with application use of WGL in a number of ways. It's also limited by WGL, which doesn't allow for all of the behaviors of DirectDraw and Direct3D. https://bugs.winehq.org/show_bug.cgi?id=28869 WineD3D needs to make its own GL context current temporarily and then restore the previous GL context, but WGL requires a DC to restore it and the DC may no longer be valid. https://bugs.winehq.org/show_bug.cgi?id=29301 WineD3D changes the window style of the device window when it should not. It needs to do that in order to render to the full screen where WGL only allows full-featured rendering to a window. https://bugs.winehq.org/show_bug.cgi?id=2082 Again, WineD3D is rendering to a window when it wants to render full-screen. In this case, the affected apps create an owned window that sits in front of the device window, obscuring it. http://bugs.winehq.org/show_bug.cgi?id=29934 WineD3D sets a pixel format on the application window. This conflicts with a later attempt by the app to set a different pixel format on the window via WGL. I think the solution to these problems is for WineD3D to have an alternative path to set up its GL context. Henri and I have been discussing using Wine-specific extensions to WGL to do this. There's already the extension WGL_WINE_pixel_format_passthrough which provides the wglSetPixelFormatWINE() function which is just like GDI's SetPixelFormat() and WGL's wglSetPixelFormat() except it allows for changing the pixel format after it's been set once. WineD3D needs to change it even though WGL doesn't allow that. In some of the bug reports listed above, I've suggested adding new extensions or modifying WGL_WINE_pixel_format_passthrough. We probably need a more comprehensive approach. WGL exposes various pieces of state to the application. Ideally, WineD3D would not alter any of that state since such alterations are visible to the app and Direct3D doesn't do that on Windows. I'm not sure that's achievable but we should at least minimize such visible state changes to the extent we can. WGL state: * The DC pixel format. For window DCs (which I believe are the only ones of real interest), this is actually a property of the window, not the DC. Changed by SetPixelFormat(), wglSetPixelFormat(); exposed by GetPixelFormat(), wglGetPixelFormat(). * The current GL context for the thread. Changed by wglMakeCurrent(), wglMakeContextCurrentARB(); exposed by wglGetCurrentContext(). * The DC for the current GL context. Changed by wglMakeCurrent(), wglMakeContextCurrentARB(); exposed by wglGetCurrentDC(), wglGetCurrentReadDCARB(). The most important things to achieve are a) to not "consume" the only opportunity the app has to set the window's pixel format, and b) to restore the app's current GL context (and implicitly its DC) when returning control to it. I don't think it's necessary to avoid WineD3D ever changing WGL's notion of the current context. Certainly, while a WineD3D GL context is current, GL functions like glClear() will operate on WineD3D's context. If the app thinks its context is current and calls GL functions, its context better really be current. So, WineD3D really needs to restore the app's context before returning control (and it generally does, I think). If it's going to do that, then wglGetCurrentContext() will take care of itself. Same for wglGetCurrentDC(). Here's my proposal: Extension WGL_WINE_surface: HANDLE wglCreateSurfaceWINE(HDC hdc, int pixel_format); // if hdc is GetDC(<some normal window>), a window surface is created // if hdc is GetDC(0), GetDC(GetDesktopWindow()), or CreateDC("display", …), a full-screen surface is created. // once the surface is created, it no longer refers to hdc void wglDestroySurfaceWINE(HANDLE surface); HDC wglGetSurfaceDCWINE(HANDLE surface); // Returns a DC created for the surface. This is not the DC passed in to wglCreateSurfaceWINE(). void wglReleaseSurfaceDCWINE(HANDLE surface, HDC hdc); This is somewhat modeled on WGL_ARB_pbuffer. <http://www.opengl.org/registry/specs/ARB/wgl_pbuffer.txt> A surface represents a "place" where GL can render, a potential target for a context. It can correspond to a Win32 window or it can be a full-screen surface. A full-screen surface will likely be a platform window (X11 or Mac) managed by the graphics driver but won't be a Win32 window. It should not interfere with mouse events or focus. A surface has a pixel format, similar to a window. Even if the surface was created from a window DC, its pixel format is independent of the window's. Since a surface is created with a pixel format, it shouldn't be necessary to set one with SetPixelFormat() on a surface DC. If it helps keep WineD3D's code simpler, we could allow it. I'm not sure if it will be necessary to support changing the pixel format after it's been set, using wglSetPixelFormatWINE(), or if the surface should just be destroyed and recreated as necessary. Doing the latter may eventually allow the removal of wglSetPixelFormatWINE(). The lifetime of a surface controls whatever resources the graphics driver has to manage for it. For a normal window, this may include a drawable. For a full-screen surface, this would include any full-screen platform window it might have created. WineD3D would obtain a DC from a surface using wglGetSurfaceDCWINE() just as it now obtains one for a window using GetDC(). There can be multiple DCs for a given surface. In particular, a DC can only be used on a single thread, so multiple threads would each have to get their own DC. The different lifetimes of surfaces vs. surface DCs is why this proposal differs from my approach in bug 2082, where I proposed an extension which just added full-screen DCs without a corresponding full-screen surface object. Destroying a surface while it still has extant surface DCs results in undefined behavior. Once WineD3D has a surface DC, it should be able to work with it as it currently does with window DCs. wglMakeCurrent() with a surface DC will associate the context with the surface drawable. For a surface created from a window, this would work as it does now in the graphics drivers with the exception of how the drawable is looked up from the DC. For a full-screen surface, this would target whatever full-screen drawable the graphics driver provides (possibly a platform window). There's a wrinkle having to do with the pixel format. User32 and the wineserver use the fact that a window has a pixel format to compute the "surface region" for the top-level window. This is a different "surface" than the concept central to this proposal. This "surface" is used for client-side GDI rendering using the DIB engine. Maintaining a surface region is necessary to prevent the contents of the window surface buffer from being blitted on top of any 3D rendering done to the window. To keep that functioning, the graphics drivers will still have to inform user32 that 3D rendering is being done to the window. It can do that using the existing mechanism, but that's not currently reversible because it's tied to the pixel format and that's a permanent property of a window. We'd like it to be reversible, since WineD3D can stop targeting a window. I'm thinking of using a count in user32. Extension WGL_WINE_make_current: BOOL wglMakeContextCurrentWINE(HGLRC hglrc); The standard WGL function wglMakeCurrent() combines two operations. It sets the a GL context's drawable to the provided DC and it makes the GL context current for the thread. This new function, wglMakeContextCurrentWINE(), would only do the latter. It would make a GL context current for the thread without changing which DC it's associated with. Both the X11 and Mac drivers already maintain the necessary state to do that. They don't need to have the DC passed in again. (If a GL context is associated with separate draw and read DCs using wglMakeContextCurrentARB(), then this function will leave it associated with both DCs.) This allows WineD3D to faithfully restore the app's previously-current WGL context. This addresses bug 28869. I considered some other designs but I don't think they work well. I looked for a way to do without special DCs. We could directly specify a pixel format when creating a context rather than getting it from the window or surface via the DC. We could make a context current directly on a surface rather than a surface DC. Unfortunately, too much of WGL depends on having a DC. For example, ChoosePixelFormat() and wglSwapBuffers(). What do folks think? Any feedback would be appreciated. -Ken

7 21

Re: [PATCH 4/5] ddraw/tests: Add a test for getdc palette handling.
by Marvin April 28, 2014

April 28, 2014

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=6628 Your paranoid android. === w2008s64 (64 bit ddraw7) === ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. === w864 (64 bit ddraw7) === ddraw7.c:6115: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. ddraw7.c:6428: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6493: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6553: Test failed: Failed to create surface, hr 0x80004002.

1 0

Re: [PATCH 3/5] ddraw/tests: Handle a backbuffer palette misbehavior on Windows 8.
by Marvin April 28, 2014

April 28, 2014

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=6626 Your paranoid android. === w2008s64 (64 bit ddraw7) === ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. === w864 (64 bit ddraw7) === ddraw7.c:6115: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6376: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6376: Test failed: Test 6: Got unexpected pitch 252, expected 256. ddraw7.c:6428: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6493: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6553: Test failed: Failed to create surface, hr 0x80004002.

1 0

Re: [PATCH 2/5] ddraw/tests: Skip the ddraw7 primary palette test if 8 bpp mode doesn't work.
by Marvin April 28, 2014

April 28, 2014

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=6625 Your paranoid android. === w864 (32 bit ddraw7) === ddraw7.c:5635: Test failed: Got unexpected refcount 3. ddraw7.c:5654: Test failed: Got unexpected refcount 3. ddraw7.c:5661: Test failed: Got unexpected hr 0. ddraw7.c:5664: Test failed: Got unexpected refcount 3. ddraw7.c:5666: Test failed: Got unexpected refcount 2. ddraw7.c:5672: Test failed: Got unexpected hr 0. ddraw7.c:5675: Test failed: Got unexpected refcount 2. ddraw7.c:5679: Test failed: Got unexpected refcount 6. ddraw7.c:5796: Test failed: Failed to set cooperative level, hr 0x8876023b. === w2008s64 (64 bit ddraw7) === ddraw7.c:6352: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 6: Got unexpected pitch 252, expected 256. === w864 (64 bit ddraw7) === ddraw7.c:6091: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6352: Test failed: Test 4: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 5: Got unexpected pitch 252, expected 256. ddraw7.c:6352: Test failed: Test 6: Got unexpected pitch 252, expected 256. ddraw7.c:6404: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6469: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:6529: Test failed: Failed to create surface, hr 0x80004002.

1 0

Re: [PATCH 1/5] ddraw/tests: Test P8 to RGB blits (try 3).
by Marvin April 28, 2014

April 28, 2014

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.

1 0

Re: mshtml: Renamed nsIDOMHTMLSelectElement::Remove to select_Remove to avoid conflict with nsIDOMElement.
by Zhenbo Li April 28, 2014

April 28, 2014

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

2 1

Fwd: [draft patch] atl100/tests: Added more tests for AtlAxWin{, Lic} procedure.
by Qian Hong April 28, 2014

April 28, 2014

Hi, A lot of thanks to Nikolay and Jacek for many comments and suggestions :) While working on tests, I found some differences between atl80 and atl100: --- snip --- + ok(wndproc[0] == wndproc[1], "expected same proc!\n"); --- snip --- - On atl80, wndprocs are different for class AtlAxWin80 and class AtlAxWinLic80, however, wndprocs are the same for class AtlAxWin100 and class AtlAxWinLic100. --- snip --- + hwnd = CreateWindowW(cls_names[i], NULL, 0, 100, 100, 100, 100, NULL, N ULL, NULL, NULL); + ok(hwnd != NULL, "CreateWindow failed!\n"); + control = (IUnknown *)0xdeadbeef; + res = AtlAxGetControl(hwnd, &control); + todo_wine ok(res == E_FAIL, "AtlAxGetControl failed with res %08x\n", res); --- snip --- - On atl80, CreateWindow with NULL window name or empty name, then call AtlAxGetControl, result is S_OK. On atl100, the same test show that result is E_FAIL. control is NULL in both situation. We've already shared source between different atl version, so it would be annoying to change the code to match different edge case on different version of atl. As far as now, I can't find any real world app depends on any of the above different edge result, so I guess we'd better follow what atl100 does even in atl80 code, would we? Thanks for any comments. --- dlls/atl100/tests/atl.c | 159 ++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 147 insertions(+), 12 deletions(-)

1 1

Re: mshtml: Added IHTMLTable::width property implementation. (try 5)
by Jacek Caban April 28, 2014

April 28, 2014

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

1 0

[RFC 1/11] Linux FF: Joystick control panel program
by Elias Vanderstuyft April 27, 2014

April 27, 2014

a) When unloading conditional effects in joy.cpl, the program crashes: When unloading the conditional effect array entries, Wine tries to access an invalid (high) address because dieffect.lpvTypeSpecificParams was not set at the time the effect was created. So declare a valid 'standard' (maxed out) conditional effect. For other unknown effects: - The same can happen when CustomForce effects are available, but because Wine's FF dinput->linux translation does not support this yet, we simply print a FIXME to indicate a possible cause if a crash would happen. - The same for other (unsupported) effects (this is probably not safe?), but then we print a WARN. => This is probably not safe, but these effects won't be unloaded, because they will never be allowed to be created: I tested this by using a dummy FF device that advertised to support CustomForce, but because JoystickAImpl_EnumEffects() does not handle CustomForce, no CustomForce entry was generated in the joy.cpl application, and there was no crash at exit. Solution: After the code of joy.cpl/main.c:766 : else if (IsEqualGUID(&pdei->guid, &GUID_Sine) || IsEqualGUID(&pdei->guid, &GUID_Square) || IsEqualGUID(&pdei->guid, &GUID_Triangle) || IsEqualGUID(&pdei->guid, &GUID_SawtoothUp) || IsEqualGUID(&pdei->guid, &GUID_SawtoothDown)) { DIPERIODIC pforce; pforce.dwMagnitude = DI_FFNOMINALMAX; pforce.lOffset = 0; pforce.dwPhase = 0; pforce.dwPeriod = FF_PERIOD_TIME; dieffect.cbTypeSpecificParams = sizeof(pforce); dieffect.lpvTypeSpecificParams = &pforce; dieffect.dwFlags |= DIEP_TYPESPECIFICPARAMS; } add the following code : else if (IsEqualGUID(&pdei->guid, &GUID_Spring) || IsEqualGUID(&pdei->guid, &GUID_Damper) || IsEqualGUID(&pdei->guid, &GUID_Inertia) || IsEqualGUID(&pdei->guid, &GUID_Friction)) { DICONDITION cxyforce[2]; int i; for (i = 0; i < 2; ++i) { cxyforce[i].lOffset = 0; cxyforce[i].lPositiveCoefficient = DI_FFNOMINALMAX; cxyforce[i].lNegativeCoefficient = DI_FFNOMINALMAX; cxyforce[i].dwPositiveSaturation = DI_FFNOMINALMAX; cxyforce[i].dwNegativeSaturation = DI_FFNOMINALMAX; cxyforce[i].lDeadBand = 0; } dieffect.cbTypeSpecificParams = sizeof(cxyforce); dieffect.lpvTypeSpecificParams = cxyforce; dieffect.dwFlags |= DIEP_TYPESPECIFICPARAMS; } else if (IsEqualGUID(&pdei->guid, &GUID_CustomForce)) { FIXME("Unhandled type specific parameters of CustomForce effect, this may lead to memory errors later on.\n"); } else WARN("Possibly unhandled type specific parameters of effect with guid %x.\n", pdei->guid); b) Weirdly, I had to add these commands that evaluates the DIEFFECT pointers at the end of each if-case, otherwise the pointers seemed to point to other address or data on that address was getting overwritten: TRACE("&rforce=0x%x\n", &rforce); TRACE("&cforce=0x%x\n", &cforce); TRACE("&pforce=0x%x\n", &pforce); TRACE("&cxyforce[0]=0x%x; &cxyforce[1]=0x%x\n", &(cxyforce[0]), &(cxyforce[1])); Elias

2 5

Re: winex11.drv: merge the clipboard and drag-and-drop import functions
by André Hentschel April 27, 2014

April 27, 2014

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"...

1 0

Advice fixing #13683 (DirectX mouse overlay?)
by Christopher Thielen April 27, 2014

April 27, 2014

Hi wine-devel, I'm attempting to fix http://bugs.winehq.org/show_bug.cgi?id=13683 but need some advice as to where to start. I'm not too familiar with hacking on Wine. I'd like to test Stefan Dösinger's theory outlined in the comments for #13683 that the missing second mouse cursor is perhaps being implemented using DirectX overlays and that Wine's lack of overlay compatibility flags is to blame. Would the proper action to test this theory be to fake a certain set of flags in dlls/d3d8/device.c's static HRESULT WINAPI d3d8_device_GetDeviceCaps(IDirect3DDevice8 *iface, D3DCAPS8 *caps) ? If that proves to be the issue, I'd then need to write proper code to report the correct set of flags presumably. Is there any easy way to see which DLLs Wine loads when running an application? I appreciate any advice, I'm new but want to help, Christopher Thielen

4 25

Re: mshtml: Added IHTMLTable::width property implementation. (try 4)
by Jacek Caban April 26, 2014

April 26, 2014

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. > + return hres; > + } > + > + nsres = nsIDOMHTMLTableElement_SetWidth(This->nstable, &val); > + nsAString_Finish(&val); > + > + if (NS_FAILED(nsres)){ > + ERR("Set Width(%s) failed!\n", debugstr_variant(&v)); > + return E_FAIL; > + } > + > + return S_OK; > } > > static HRESULT WINAPI HTMLTable_get_width(IHTMLTable *iface, VARIANT *p) > { > HTMLTable *This = impl_from_IHTMLTable(iface); > - FIXME("(%p)->(%p)\n", This, p); > - return E_NOTIMPL; > + nsAString val; > + BSTR bstr; > + nsresult nsres; > + HRESULT hres; > + > + TRACE("(%p)->(%p)\n", This, p); > + nsAString_Init(&val, NULL); > + nsres = nsIDOMHTMLTableElement_GetWidth(This->nstable, &val); > + if (NS_FAILED(nsres)){ > + ERR("Get Width(%s) failed!\n", debugstr_variant(p)); > + nsAString_Finish(&val); > + return E_FAIL; > + } > + > + hres = nsstr_to_truncated_bstr(&val, &bstr); > + if (FAILED(hres)) { > + SysFreeString(bstr); And bstr is not initialized in error case. Also, as Dmitry pointed, you don't check for some errors in var2str. Jacek

2 4

Microsoft make MS-DOS codes avalable to public
by Akira Nakagawa April 26, 2014

April 26, 2014

http://www.computerhistory.org/atchm/microsoft-ms-dos-early-source-code/ I think it does not something for wine☺

2 1

Re: mshtml: Added IHTMLTable::width property implementation. (try 4)
by Dmitry Timoshkov April 26, 2014

April 26, 2014

Zhenbo Li <litimetal(a)gmail.com> wrote: > + case VT_R8: > + VarBstrFromR8(V_R8(p), 0, 0, &str); > + break; > + case VT_R4: > + VarBstrFromR4(V_R4(p), 0, 0, &str); > + break; > + case VT_I4: > + VarBstrFromI4(V_I4(p), 0, 0, &str); > + break; All these APIs can fail and return appropriate error code. -- Dmitry.

1 0

Re: [PATCH 3/3] ddraw/tests: Test P8 to RGB blits (try 2).
by Henri Verbeet April 25, 2014

April 25, 2014

On 24 April 2014 14:36, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + hr = IDirectDraw2_CreateSurface(ddraw, &surface_desc, &dst, NULL); > + You should probably check the results of this call, like in the other versions.

1 0

Re: [PATCH] gdiplus: Simplify GdipResetImageAttributes(), fix remap table leak (Valgrind)
by Vincent Povirk April 25, 2014

April 25, 2014

Looks good to me, thanks.

1 0

Some visual testing of my latest ForceFeedback patched Wine in combination with the new Linux ff-memless-next kernel driver
by Elias Vanderstuyft April 25, 2014

April 25, 2014

Hi guys, Here is a video of some real-time Force-Feedback testing of the game NeedForSpeed Carbon using my latest patched Wine on Linux: http://www.youtube.com/watch?v=mV-yh72GO30 All periodic force magnitudes are displayed in real-time by gnuplot. Enjoy watching, Elias

2 1

Re: mshtml: Added IHTMLTable::width property implementation. (try 3)
by Jacek Caban April 25, 2014

April 25, 2014

On 04/22/14 17:30, Zhenbo Li wrote: > diff --git a/dlls/mshtml/htmltable.c b/dlls/mshtml/htmltable.c > index d711ed7..e16aee2 100644 > --- a/dlls/mshtml/htmltable.c > +++ b/dlls/mshtml/htmltable.c > @@ -57,6 +57,33 @@ static inline HTMLTable *impl_from_IHTMLTable3(IHTMLTable3 *iface) > return CONTAINING_RECORD(iface, HTMLTable, IHTMLTable3_iface); > } > > +static HRESULT var2str(nsAString *nsstr, const VARIANT *p) > +{ Nit: please swap arguments order. > + BSTR str; > + BOOL ret; > + > + switch(V_VT(p)) { > + case VT_BSTR: > + return nsAString_Init(nsstr, V_BSTR(p))? > + S_OK : E_FAIL; E_OUTOFMEMORY would be more appropriate here. > + case VT_R8: > + VarBstrFromR8(V_R8(p), 0, 0, &str); > + break; > + case VT_R4: > + VarBstrFromR4(V_R4(p), 0, 0, &str); > + break; > + case VT_I4: > + VarBstrFromI4(V_I4(p), 0, 0, &str); > + break; > + default: > + FIXME("unsupported arg %s\n", debugstr_variant(p)); > + return E_NOTIMPL; > + } > + ret = nsAString_Init(nsstr, str); > + SysFreeString(str); > + return ret ? S_OK : E_FAIL; > +} Same here. > + > static HRESULT WINAPI HTMLTable_QueryInterface(IHTMLTable *iface, > REFIID riid, void **ppv) > { > @@ -395,15 +422,79 @@ static HRESULT WINAPI HTMLTable_get_rows(IHTMLTable *iface, IHTMLElementCollecti > static HRESULT WINAPI HTMLTable_put_width(IHTMLTable *iface, VARIANT v) > { > HTMLTable *This = impl_from_IHTMLTable(iface); > - FIXME("(%p)->(%s)\n", This, debugstr_variant(&v)); > - return E_NOTIMPL; > + nsAString val; > + HRESULT hres; > + nsresult nsres; > + > + TRACE("(%p)->(%s)\n", This, debugstr_variant(&v)); > + hres = var2str(&val, &v); > + > + if (hres != S_OK){ > + ERR("Set Width(%s) failed when initializing a nsAString!\n", > + debugstr_variant(&v)); > + nsAString_Finish(&val); val is not initialized here, you can't call nsAString_Finish on it. > + return hres; > + } > + > + nsres = nsIDOMHTMLTableElement_SetWidth(This->nstable, &val); > + nsAString_Finish(&val); > + > + if (NS_FAILED(nsres)){ > + ERR("Set Width(%s) failed!\n", debugstr_variant(&v)); > + return E_FAIL; > + } > + > + return S_OK; > } > > static HRESULT WINAPI HTMLTable_get_width(IHTMLTable *iface, VARIANT *p) > { > HTMLTable *This = impl_from_IHTMLTable(iface); > - FIXME("(%p)->(%p)\n", This, p); > - return E_NOTIMPL; > + nsAString val; > + const PRUnichar *str; > + BSTR bstr; > + DOUBLE width; > + nsresult nsres; > + HRESULT hres; > + > + TRACE("(%p)->(%p)\n", This, p); > + nsAString_Init(&val, NULL); > + nsres = nsIDOMHTMLTableElement_GetWidth(This->nstable, &val); > + if (NS_FAILED(nsres)){ > + ERR("Get Width(%s) failed!\n", debugstr_variant(p)); > + nsAString_Finish(&val); > + return E_FAIL; > + } > + > + nsAString_GetData(&val, &str); > + hres = VarR8FromStr(str, 0, 0, &width); > + > + /* WinAPI would return VT_BSTR, not VT_I4 */ > + switch(hres) { > + case S_OK: /* Truncate that number */ > + hres = VarBstrFromI4((LONG)width, 0, 0, &bstr); There may be overflow here. > + if (hres != S_OK) { > + ERR("VarBstrFromI4 failed, err = %d\n", hres); > + return E_FAIL; > + } > + V_VT(p) = VT_BSTR; > + V_BSTR(p) = bstr; > + break; > + case DISP_E_TYPEMISMATCH: /* Has symbols */ > + V_VT(p) = VT_BSTR; > + V_BSTR(p) = SysAllocString(str); > + if (!V_BSTR(p)) { > + ERR("SysAllocString(%s) failed!\n", debugstr_w(str)); > + return E_FAIL; > + } > + break; > + default: > + ERR("VarR8FromStr(%s) failed, err = %d\n", debugstr_w(str), hres); > + return E_FAIL; I find it more complicated than it needs to be. You don't really need full conversion here, just a simple string parsing. How about using such helper: static HRESULT nsstr_to_rounded_bstr(const nsAString *nsstr, BSTR *ret_ptr) { const PRUnichar *str, *ptr, *end = NULL; BSTR ret; nsAString_GetData(nsstr, &str); for(ptr = str; isdigitW(*ptr); ptr++); if(*ptr == '.') { for(end = ptr++; isdigitW(*ptr); ptr++); if(*ptr) end = NULL; } ret = end ? SysAllocStringLen(str, end-str) : SysAllocString(str); if(!ret) return E_OUTOFMEMORY; *ret_ptr = ret; return S_OK; } Cheers, Jacek

2 2

Re: [PATCH 3/4] oleacc: Add ObjectFromLresult implementation
by Qian Hong April 25, 2014

April 25, 2014

Hi Piotr, thanks for your work, I'm really exciting with the oleacc works because Selenium IE Driver depends on oleacc and with oleacc implemented we can run Selenium IE test case on Wine builtin / native IE to make a more compatible IE! + atom = result; + if(atom != result) + return E_FAIL; I can't understand these few lines, are they typo or did I miss anything? Also I cc'ed you on http://bugs.winehq.org/show_bug.cgi?id=30353 which is related to Selenium IE Driver and oleacc, hopefully you don't mind have a look :) Thank you again!

4 7

Re: msvcp90: Added complex_float_pow impletation and tests
by YongHao Hu April 25, 2014

April 25, 2014

1 reply to应该没有问题吧？我也是设置成wine-devel，你是说发到wine-zh要相应换成wine-zh？ 2补丁我昨晚是不是用thunderbird发的，所以是gmail的名称。现在看看如何？ On Saturday, April 12, 2014 03:59 PM, YongHaoWu wrote: > --- > dlls/msvcp70/msvcp70.spec | 12 ++++----- > dlls/msvcp71/msvcp71.spec | 12 ++++----- > dlls/msvcp80/msvcp80.spec | 12 ++++----- > dlls/msvcp90/math.c | 18 ++++++++++++++ > dlls/msvcp90/msvcp90.spec | 12 ++++----- > dlls/msvcp90/tests/misc.c | 60 +++++++++++++++++++++++++++++++++++++++++++++ > 6 files changed, 102 insertions(+), 24 deletions(-) >

2 1

Re: [PATCH] advapi32/tests: Fix some leaks in tests (Valgrind)
by Marvin April 25, 2014

April 25, 2014

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=6551 Your paranoid android. === w7u (32 bit service) === service.c:1412: Test failed: Active services mismatch 1 service.c:1413: Test failed: Inactive services mismatch 4294967295 The test timed out

1 0