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

Re: [PATCH 2/7] oleacc: Don't return partial data in GetRoleTextA if buffer is too small
by Marvin May 15, 2014

May 15, 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=7079 Your paranoid android. === wxppro (32 bit main) === main.c:96: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: [PATCH 4/4] xmllite/writer: Implement Flush() method
by Marvin May 15, 2014

May 15, 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=7075 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>ncoding="UT

1 0

Re: [PATCH 3/4] xmllite/writer: Initial support for starting a document
by Marvin May 15, 2014

May 15, 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=7074 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:229: Test failed: got <?xml version="1.0"?>ncoding="UT

1 0

Re: [PATCH 2/4] xmllite/writer: Initial support of output buffer creation
by Marvin May 15, 2014

May 15, 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=7073 Your paranoid android. === wvistau64 (32 bit writer) === writer.c:219: Test failed: got <?xml version="1.0"?>?> === w2008s64 (64 bit writer) === writer.c:219: Test failed: got <?xml version="1.0"?>ncoding="UT

1 0

Re: [PATCH 1/5] wined3d: Move get_dc palette updates to ddraw (v2).
by Henri Verbeet May 15, 2014

May 15, 2014

On 15 May 2014 14:33, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +void __cdecl wined3d_palette_apply_to_dc(const struct wined3d_palette *palette, HDC hdc); Can we avoid "Hungarian" in wined3d, please?

1 0

Re: dpnet: Stub interface IDirectPlay8LobbyClient (try 2)
by Stefan Dösinger May 15, 2014

May 15, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-14 06:46, schrieb Alistair Leslie-Hughes: > +#define COBJMACROS > +#include "windef.h" > +#include "winbase.h" > +#include "wingdi.h" > +#include "winuser.h" > +#include "objbase.h" > +#include "wine/debug.h" Another thing I did not notice before: Do you need them all? At least wingdi.h seems suspicious, I guess winuser.h shouldn't be needed either - unless dpnet pops up dialogs. > +static HRESULT WINAPI lobbyclient_QueryInterface(IDirectPlay8LobbyClient *iface, REFIID riid, void **ppobj) > ... > + IUnknown_AddRef(iface); > + *ppobj = This; IMO this should be *ppobj = &This->IDirectPlay8LobbyClient_iface. That way it doesn't break if someone uses > +static HRESULT WINAPI lobbyclient_EnumLocalPrograms(IDirectPlay8LobbyClient *iface, GUID* pGuidApplication, BYTE* pEnumData, DWORD* pdwEnumData, DWORD* pdwItems, DWORD flags) You de-hungarified flags, but not the others (pSomePointer, pdwSomePointerToADWord). There are many more cases in the other functions. > +static HRESULT WINAPI lobbyclient_ConnectApplication(IDirectPlay8LobbyClient *iface, DPL_CONNECT_INFO* pdplConnectionInfo, PVOID pvConnectionContext, DPNHANDLE* hApplication, DWORD dwTimeOut, DWORD flags) > +{ > + IDirectPlay8LobbyClientImpl *This = impl_from_IDirectPlay8LobbyClient(iface); > + > + FIXME("(%p)->(%p %p %p %d %x)\n", This, pdplConnectionInfo, pvConnectionContext, hApplication, dwTimeOut, flags); a DWORD is an unsigned value, it should use %u. This applies to dwTimeOut here, but there are other cases in other functions. > +static HRESULT WINAPI lobbyclient_SetConnectionSettings(IDirectPlay8LobbyClient *iface, DPNHANDLE hConnection, const DPL_CONNECTION_SETTINGS* pdplSessionInfo, DWORD flags) > +{ > + IDirectPlay8LobbyClientImpl *This = impl_from_IDirectPlay8LobbyClient(iface); > + > + FIXME("(%p)->(%d %p %x)\n", This, hConnection, pdplSessionInfo, flags); > + > + return E_NOTIMPL; > +} You might want a helper function that prints DPL_CONNECTION_SETTINGS at some point. I'm ok with adding this in a later patch. Don't forget to check for NULL before you print though. > + > + > +static const IDirectPlay8LobbyClientVtbl DirectPlay8LobbiedClient_Vtbl = > +{ Really minor nitpick: There's an extra newline. > +HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory *iface, IUnknown *outer, REFIID riid, void **obj) > +{ > + IDirectPlay8LobbyClientImpl *app; Why is it called "app"? > + HRESULT ret; > + > + TRACE("(%p, %s, %p)\n", outer, debugstr_guid(riid), obj); You forgot to print iface here. Is that intentional? > diff --git a/dlls/dpnet/tests/Makefile.in b/dlls/dpnet/tests/Makefile.in > index f6e45ea..5b97aa1 100644 > +#define WIN32_LEAN_AND_MEAN > +#include <stdio.h> Is this needed? I don't see a function call, but maybe I'm missing something +static HRESULT WINAPI DirectPlayLobbyMessageHandler(PVOID context, DWORD message_id, PVOID buffer) PJUNK There are more PJUNKs in this file. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTdIsTAAoJEN0/YqbEcdMwxkkQAJVt/Y/QT5MIj7VKXsOHwZLJ 2prBQIrzBCPZHxS8EyzEEI008kZ+M2hquPD5Eeinj5L69D4wV5sv6VIFBk2Gz40P SpJaCdE/Srjto+2MQAgRjJ1JMhNCKCWMGg/w+OBRtBs8JM63gHwQNk+ZUQpdl58B OdNpGPbj7Ynlqt+fENUOOxMrbHwToMU1BvgfBogVdWD1P2AnvlFuoRZxSoZuF9Kn 3kloiFs/hv266ZCof1ngrxVuc2uojHWdlev4t2bWYSNoXewIVVRzvtJEvJpveQjq bWzGFe6ZmIhmSJ+2nCnAhXpZjNAv2+o2bdUK1q7EAkUHHv8cb/rTJ+8yX7HiG0UD NxmAtM4EMwLOBRl2yOATR52Q47r195JFv/YOJUHPRW+wL8rIkE/FC6kk4h6zB9/r 5rwLNpWoqagdD9bSJ6LZneRoQzsJ+SMy+8FInnEfDpFZaHRPue4UPFoUNWHQd3f/ ruuIWcWwQwQ7msI8Nr2JgNstGNCO7d6XQfjvJDwqZUZwLihrxEiOa8fVfCRA54Lu hS3esozn+0oQWmSKPm9fw5OA4RIZGY2zLGf3mkFX9BLuBWmKCfxQ5t+1c0nv6Q/f ZSHjUSjem6aLtwq6+48gilS5MsbqsqDQXRE+rEBzFNzcJbQByyd+0yMiYckBajAp H7j+HVl6L6VSGTY9LrMu =S78r -----END PGP SIGNATURE-----

1 0

Support for DirectX 11
by Dyweni - Wine-Devel May 14, 2014

May 14, 2014

Hi, I'd like to know if anyone has an idea on when DirectX 11 would be completed, at least to a point of being able to play DirectX 11 only games? Thanks, Dyweni

1 0

Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 4)
by Henri Verbeet May 14, 2014

May 14, 2014

On 14 May 2014 16:12, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/d3d9/tests/device.c | 133 ++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 107 insertions(+), 26 deletions(-) > Unfortunately this still fails for me on Windows. The returned counts change between runs, which could perhaps be related to the backbuffer size being larger than the window size. It does seem to reliably pass when either running the test in fullscreen mode, or changing the backbuffer size to e.g. 640x480. The former is probably the easier fix. > + ok(data.word[0] == (WORD)expected || broken(!data.word[0]), > + "Occlusion query returned an unexpected result (0x%.8x).\n", data.dword[0]); > + if (!data.word[0]) > + { > + skip("Occlusion query result looks broken, ignoring returned count.\n"); > + broken_occlusion = TRUE; > + } At 1024x768 for example, "expected" is going to be 0xc0000. Is this for drivers that always return 0 for occlusion queries, or is this for the testbot, which IIRC runs at the resolution? If it's really broken, I think this should also check for "(WORD)expected" being 0, and then use win_skip() instead of skip().

2 1

Re: oleaut32: Added debugstr_variant helper for better debug traces.
by Michael Stefaniuc May 14, 2014

May 14, 2014

Hello Jacek, On 05/14/2014 04:55 PM, Jacek Caban wrote: > > 0001-oleaut32-Added-debugstr_variant-helper-for-better-deb.diff wouldn't it be better to make debugstr_variant aka add it to include/wine/debug.h? VARIANTs are used in a lot more places then just oleaut32. > > > diff --git a/dlls/oleaut32/varformat.c b/dlls/oleaut32/varformat.c > index e72a170..0e1c370 100644 > --- a/dlls/oleaut32/varformat.c > +++ b/dlls/oleaut32/varformat.c > @@ -1201,9 +1201,8 @@ static HRESULT VARIANT_FormatNumber(LPVARIANT pVarIn, LPOLESTR lpszFormat, > const BYTE* pToken = NULL; > HRESULT hRes = S_OK; > > - TRACE("(%p->(%s%s),%s,%p,0x%08x,%p,0x%08x)\n", pVarIn, debugstr_VT(pVarIn), > - debugstr_VF(pVarIn), debugstr_w(lpszFormat), rgbTok, dwFlags, pbstrOut, > - lcid); > + TRACE("(%s,%s,%p,0x%08x,%p,0x%08x)\n", debugstr_variant(pVarIn), debugstr_w(lpszFormat), > + rgbTok, dwFlags, pbstrOut, lcid); bye michael

2 1

Re: [PATCH 3/3] oleacc: Add GetStateText implementation
by Nikolay Sivov May 14, 2014

May 14, 2014

> + ret = GetStateTextW(0, (WCHAR*)&ptr, 0); Why not use id symbols, instead of magic numbers?

2 1