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

Re: oleacc: Add WindowFromAccessibleObject implementation
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=7084 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 6/7] oleacc: Add IOleWindow::GetWindow implementation in default client accessible object
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=7082 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: [PATCH 4/7] oleacc: Add IOleWindow interface stub to default client accessible object
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=7081 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

Re: [PATCH 5/5] includes: Fix an in/out annotation in shobjidl.idl.
by Nikolay Sivov May 15, 2014

May 15, 2014

On 5/15/2014 16:33, Stefan Dösinger wrote: > --- > include/shobjidl.idl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/shobjidl.idl b/include/shobjidl.idl > index c9297a8..ae42c2e 100644 > --- a/include/shobjidl.idl > +++ b/include/shobjidl.idl > @@ -3350,7 +3350,7 @@ interface ITransferAdviseSink : IUnknown > HRESULT FileFailure([in] IShellItem *item, > [in, unique, string] LPCWSTR itemname, > [in] HRESULT hr, > - [out, unique, size_is(crename)] LPWSTR rename, > + [in, out, unique, size_is(crename)] LPWSTR rename, > [in] ULONG crename); > HRESULT SubStreamFailure([in] IShellItem *item, > [in, string] LPCWSTR stream, According to PSDK existing attributes are correct. Where did you find additional [in] ?

3 3

Re: [PATCH 3/7] oleacc: Disable tests on old oleacc
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=7080 Your paranoid android. === wxppro (32 bit main) === main.c:104: Test failed: GetRoleTextA returned not zero-length buffer : (t)

1 0

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

RFC: "once" FIXME capability
by Erich E. Hoover May 14, 2014

May 14, 2014

While at LinuxTag Sebastian Lackner, Michael Müller, and I were chatting with Michael Stefaniuc and Anastasius Focht about the way we currently implement "one-time FIXME". It was discussed that a more global approach to this was desired, but that it should have the following characteristics: 1) It should work with ANSI C compilers (the variadic macro problem) 2) It should be something that we can disable with a debug channel (something AF would really appreciate that our current ad-hoc approach does not support) 3) It should be expandable to handling a "once per flag" capability Toward that end the three of us have put together several proposed "once" implementations. All three patch-sets are based on variations of the following trick to allow defining in-place static variables without any special compiler requirements: if(1) { \ static int __wine_debug_once = 0; \ int __wine_debug_once_temp = __wine_debug_once; \ if(!__wine_debug_once) __wine_debug_once = 1; \ if(__wine_debug_once_temp == 0) \ goto __WINE_LIMIT_LABEL(__LINE__); \ } else __WINE_LIMIT_LABEL(__LINE__): Here are the various approaches: 1) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_1.tgz This implementation is a macro (LIMIT_ONCE, LIMIT_FLAG_ONCE) that you would use to prefix a FIXME/WARN/etc. The feature can be disabled by enabling the "+nolimit" WINEDEBUG option (patch 3). 2) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_2.tgz This implementation builds onto the existing FIXME to add a FIXME_ONCE (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the "+nolimit" WINEDEBUG option (patch 4). 3) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_3.tgz This implementation builds onto the existing FIXME to add a FIXME_ONCE (and FIXME_FLAG_ONCE). The feature can be disabled by enabling the "nolimit+<channel>" WINEDEBUG option (patch 4). This version benefits from the ability to turn off limiting on a per-channel basis, which should make it easier to track down problems when an unrelated debug channel is also spamming the console. We'd love to hear which approach everyone likes the most or any feedback you might have. Best, Erich

2 1

Re: [PATCH 4/5] d2d1: Add the ID2D1Bitmap interface.
by Nikolay Sivov May 14, 2014

May 14, 2014

On 5/14/2014 09:56, Henri Verbeet wrote: > +[ > + local, > + object, > + uuid(a2296057-ea42-4099-983b-539fb6505426) > +] > +interface ID2D1Bitmap : ID2D1Image > +{ > + D2D1_SIZE_F GetSize(); > + D2D1_SIZE_U GetPixelSize(); > + D2D1_PIXEL_FORMAT GetPixelFormat(); > + void GetDpi( > + [out] float *dpi_x, > + [out] float *dpi_y > + ); > + HRESULT CopyFromBitmap( > + [in, optional] const D2D1_POINT_2U *dst_point, > + [in] ID2D1Bitmap *bitmap, > + [in, optional] const D2D1_RECT_U *src_rect > + ); > + HRESULT CopyFromRenderTarget( > + [in, optional] const D2D1_POINT_2U *dst_point, > + [in] ID2D1RenderTarget *render_target, > + [in, optional] const D2D1_RECT_U *src_rect > + ); > + HRESULT CopyFromMemory( > + [in, optional] const D2D1_RECT_U *dst_rect, > + [in] const void *src_data, > + [in] UINT32 pitch > + ); > +} > + > I don't think it makes sense to match msdn here regarding [optional] attribute, and that's why: - 'optional' without 'defaultvalue' has no effect on headers, as far as I can see; - you can't mix 'optional' with required arguments like that, midl will refuse to process such idl, optional arguments should be at the end of arguments list only; - msdn says that it only applies to VARIANT and VARIANT* types, not sure about that, probably it's meant to talk about typelib generation only. And we don't need a typelib for d2d1 anyway. It makes sense imo to eventually make widl more midl-compliant adding similar consistency checks, like 'optional' position, also duplicated guids in typelibs come to mind. It's up to you to keep it as it is, just pointing out potential problems.

3 6

Re: [user32] add a dde test for OEM CP
by Marvin May 13, 2014

May 13, 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=7029 Your paranoid android. === w2000pro (32 bit dde) === dde.c:1797: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 6 dde.c:1820: Test failed: DdeQueryStringA returned wrong string String dde.c:1831: Test failed: DdeQueryStringA returned wrong length 6 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wxppro (32 bit dde) === dde.c:1797: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 513 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1820: Test failed: DdeQueryStringA returned wrong string ?" dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wvistau64 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w2008s64 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w7u (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w8 (32 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === wvistau64 (64 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom === w2008s64 (64 bit dde) === dde.c:1790: Test failed: DdeCreateStringHandleW failed with error 00004006 dde.c:1797: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1807: Test failed: DdeQueryStringW returned wrong length 1 dde.c:1808: Test failed: DdeQueryStringW returned wrong string dde.c:1819: Test failed: DdeQueryStringA returned wrong length 1 dde.c:1820: Test failed: DdeQueryStringA returned wrong string dde.c:1831: Test failed: DdeQueryStringA returned wrong length 2 dde.c:1832: Test failed: DdeQueryStringW returned wrong string dde.c:1849: Test failed: Expected a valid atom

1 0

Re: oleacc: Add GetStateText implementation (try3)
by Alexandre Julliard May 13, 2014

May 13, 2014

Piotr Caban <piotr(a)codeweavers.com> writes: > +UINT WINAPI GetStateTextW(DWORD state_bit, WCHAR *state_str, UINT state_str_len) > +{ > + DWORD state_id; > + > + TRACE("%x %p %u\n", state_bit, state_str, state_str_len); > + > + state_id = IDS_STATE_MIN; > + while(state_bit) { > + state_id++; > + state_bit /= 2; > + } > + > + if(state_id>=IDS_STATE_MIN && state_id<=IDS_STATE_MAX) { > + UINT ret; > + > + if(state_str) { > + ret = LoadStringW(oleacc_handle, state_id, state_str, state_str_len); > + }else { > + WCHAR tmp; > + ret = LoadStringW(oleacc_handle, state_id, &tmp, 0); > + } > + > + if(!ret && state_str && state_str_len) > + state_str[0] = 0; > + return ret; > + } The id range check doesn't seem very useful. Also it would be worth testing that a 0 length is supposed to return the string pointer the way LoadString does. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] ntdll: Pad the FILE_*_DIRECTORY_INFORMATION with zero bytes
by Alexandre Julliard May 13, 2014

May 13, 2014

Martin Storsjo <martin(a)martin.st> writes: > Instead of memcpying in whatever uninitialized data there was at > the end of long_nameW, memset the tail of the struct to zero > instead. > > This fixes running cl.exe from MSVC 2013 with native > msvcr120/msvcp120, fixing bug 35335. > > MSVC 2013 (or msvcr120?) seems to use NtQueryDirectoryFile to > iterate through the headers in directories in the include path, > and prior to this change, the file names found during iteration > could get a suffix consisting of an uninitialized WCHAR. That doesn't make much sense, given that there may not be space for a final null, and that your patch doesn't clear the right location anyway. It looks like more investigation is needed. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 3/5] wined3d: Always store the palette index in the alpha component.
by Henri Verbeet May 13, 2014

May 13, 2014

On 12 May 2014 15:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -1458,8 +1457,7 @@ static void surface_download_data(struct wined3d_surface *surface, const struct > int src_pitch = 0; > int dst_pitch = 0; > > - /* In case of P8 the index is stored in the alpha component if the primary render target uses P8. */ > - if (format->id == WINED3DFMT_P8_UINT && swapchain_is_p8(surface->resource.device->swapchains[0])) > + if (format->id == WINED3DFMT_P8_UINT) > { > gl_format = GL_ALPHA; > gl_type = GL_UNSIGNED_BYTE; This branch is pretty pointless, the format / type for WINED3DFMT_P8_UINT is always GL_ALPHA / GL_UNSIGNED_BYTE. (If ARB_fragment_program is supported, and the format is supported at all anyway.) > @@ -3256,53 +3252,19 @@ static void read_from_framebuffer(struct wined3d_surface *surface, DWORD dst_loc > switch (surface->resource.format->id) > { > case WINED3DFMT_P8_UINT: > - { > - if (swapchain_is_p8(context->swapchain)) > - { > - /* In case of P8 render targets the index is stored in the alpha component */ > - fmt = GL_ALPHA; > - type = GL_UNSIGNED_BYTE; > - mem = data.addr; > - bpp = surface->resource.format->byte_count; > - } > - else > - { > - /* GL can't return palettized data, so read ARGB pixels into a > - * separate block of memory and convert them into palettized format > - * in software. Slow, but if the app means to use palettized render > - * targets and locks it... > - * > - * Use GL_RGB, GL_UNSIGNED_BYTE to read the surface for performance reasons > - * Don't use GL_BGR as in the WINED3DFMT_R8G8B8 case, instead watch out > - * for the color channels when palettizing the colors. > - */ > - fmt = GL_RGB; > - type = GL_UNSIGNED_BYTE; > - pitch *= 3; > - mem = HeapAlloc(GetProcessHeap(), 0, surface->resource.size * 3); > - if (!mem) > - { > - ERR("Out of memory\n"); > - return; > - } > - bpp = surface->resource.format->byte_count * 3; > - } > - } > - break; > + fmt = GL_ALPHA; > + type = GL_UNSIGNED_BYTE; > + break; > > default: > - mem = data.addr; > fmt = surface->resource.format->glFormat; > type = surface->resource.format->glType; > - bpp = surface->resource.format->byte_count; > } Like above. > if (!srcIsUpsideDown) > { > - UINT len; > /* glReadPixels returns the image upside down, and there is no way to prevent this. > - Flip the lines in software */ > - len = surface->resource.width * bpp; > + * Flip the lines in software. > + * TODO: Consider flipping the image in an FBO. */ Possibly, but that would be a decision for surface_load_sysmem(), not read_from_framebuffer(). Note that reading the front buffer isn't particularly fast on Windows either though. > + row = HeapAlloc(GetProcessHeap(), 0, pitch); > + goto error; This looks unintentional. > @@ -3088,38 +3088,7 @@ DWORD wined3d_format_convert_from_float(const struct wined3d_surface *surface, c > } > > if (format->id == WINED3DFMT_P8_UINT) > - { > - const RGBQUAD *e; > - BYTE r, g, b, a; > - > - if (!surface->palette) > - { > - WARN("Surface doesn't have a palette, returning 0.\n"); > - return 0; > - } > - > - r = (BYTE)((color->r * 255.0f) + 0.5f); > - g = (BYTE)((color->g * 255.0f) + 0.5f); > - b = (BYTE)((color->b * 255.0f) + 0.5f); > - a = (BYTE)((color->a * 255.0f) + 0.5f); > - > - e = &surface->palette->colors[a]; > - if (e->rgbRed == r && e->rgbGreen == g && e->rgbBlue == b) > - return a; > - > - WARN("Alpha didn't match index, searching full palette.\n"); > - > - for (i = 0; i < 256; ++i) > - { > - e = &surface->palette->colors[i]; > - if (e->rgbRed == r && e->rgbGreen == g && e->rgbBlue == b) > - return i; > - } > - > - FIXME("Unable to convert color to palette index.\n"); > - > - return 0; > - } > + return (BYTE)((color->a * 255.0f) + 0.5f); So this could just use the table now, right?

2 3

Re: dpnet: Stub interface IDirectPlay8LobbyClient
by Stefan Dösinger May 13, 2014

May 13, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-13 02:04, schrieb Alistair Leslie-Hughes: > @@ -127,6 +127,7 @@ extern HRESULT DPNET_CreateDirectPlay8Peer(LPCLASSFACTORY iface, LPUNKNOWN punkO > extern HRESULT DPNET_CreateDirectPlay8Address(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > extern HRESULT DPNET_CreateDirectPlay8LobbiedApp(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > extern HRESULT DPNET_CreateDirectPlay8ThreadPool(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; > +extern HRESULT DPNET_CreateDirectPlay8LobbyClient(IClassFactory *iface, IUnknown *pUnkOuter, REFIID riid, LPVOID *ppobj) DECLSPEC_HIDDEN; If you don't use LPJUNK for the iface and UnkOuter (yay :-) ), you might also do it for LPVOID. > +static HRESULT WINAPI lobbyclient_Initialize(IDirectPlay8LobbyClient *iface, PVOID pvUserContext, PFNDPNMESSAGEHANDLER pfn, DWORD dwFlags) No Hungarian notation please (dwFlags, pThisIsAPointer). Also, (L)PJUNK again. > + app = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectPlay8LobbyClientImpl)); > + if (NULL == app) { > + *ppobj = NULL; > + return E_OUTOFMEMORY; > + } Style inconsistency with the rest of the patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTcddPAAoJEN0/YqbEcdMwu2oP/iKSBrRhn/4PoGRTAE6hHQsd 4qwWb7WNS+mczHW+ucVfBogFvPkecpUauHWMpEyND3mYp8kli/2BDqtQrovcvabK h5QRqrP3ToRyIm6VMgaijMx4WlrjsZKHKKzW7/k8TxBTAs25OOaBAUC8ihK1A65s lQVywsqPPHuq4u8LzFjr4xE8s5UyZy5tCPYyDFym0otbiRX9+MQJjztFtC3wd8si Fznv681ZTrpR5m3qvcrMn1Eo2mKFvM1Wbi7W58uO2QTEH6BRiMlfd3A/fqVbhCdZ jiYdcDgUSWugOxIoWtaJNzU/mh3oChyPe+WWFXNoPy5W0/wrJHXUbssAW/s5bX1p wRO6rqmbf27rGCFp57oimJMxb/QJT0o+sU2ZdYHv2hjAX7U1csGU6Z3bUQ/KYLlG AztBJBVkTbe9aoIKhsZx/ISHIQ5GYJyY8KntqBOadrziu/I0kzX0ONtDfTdFzkne RhBSXUFjlKxxm17hXyOEftMsD1tkMn74fChJzFOJUo6v3thkH1IcbMhqwNLvj6++ Om2bO4M5Lw77u/9jR84WpFWUh4wUUqgs+v1/VPpt07QTIhwAERU3CiMt1wlkZFvB cyiWm+a3q/GekR1gyyku31bbkqInDRZENDkRl3FXWS/t1Om38j2JgB45mCMEFKCq HoNMnRF44iY4XWaXwd5M =3BFT -----END PGP SIGNATURE-----

1 0

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

May 12, 2014

On 12 May 2014 17:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/d3d9/tests/device.c | 119 ++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 96 insertions(+), 23 deletions(-) > This fails here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so device && touch device.ok ... device.c:4609: Test failed: Occlusion query returned an unexpected result (0x00060300). device.c:4621: Test failed: Occlusion query returned an unexpected result (0x00060300). device.c:4628: Test failed: Occlusion query returned an unexpected result (0x00060300). And on Windows: device.c:4609: Test failed: Occlusion query returned an unexpected result (0xffff052a). device.c:4621: Test failed: Occlusion query returned an unexpected result (0x0008052a). device.c:4628: Test failed: Occlusion query returned an unexpected result (0x0008052a).

2 1

Re: testbot/log2revtimes: Add a script to extract the VM revert times from the WineTestBot log and prepare them for analysis.
by Francois Gouget May 12, 2014

May 12, 2014

On Mon, 12 May 2014, Francois Gouget wrote: > --- > > I'm using this script to parse the Engine log and generate a CSV files I > can import in a spreadsheet to generate a graph of the VM revert times. > But having it only on my machine feels wrong. So I propose to put it in > the scripts directory (which feels like a sort of contrib directory) so > it can be used by others. And here is the spreadsheet I import the 'CVS' file into: http://fgouget.free.fr/wtb/vm1-revtime.xls.bz2 And the corresponding graphs: * Since the beginning of times This graph shows all the revert times since the new TestBot was put online. The Y axis is logarithmic so the high revert times don't cause all the low ones to be crunched together. Note that the stratification is caused by the 1 second ganularity of the mesurements. I guess it needs an annotation with the different events. http://fgouget.free.fr/wtb/vm1-revtimes-all.png * Since last April This shows the revert times a bit before the VM1 host crashed and went through reconstruction. This confirms my suspicions: the revert times are not very good :-( http://fgouget.free.fr/wtb/vm1-revtimes-recent.png -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH 5/5] wined3d: Move get_dc palette updates to ddraw.
by Henri Verbeet May 12, 2014

May 12, 2014

On 12 May 2014 15:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Note that d3d9 does not support get_dc on D3DFMT_P8. d3d8 and d3d10+ do > not support get_dc at all. That's not strictly true, with d3d10+ you can still get GetDC() / ReleaseDC() through IDXGISurface1. It doesn't give you P8 though. > + if (palette) > + { > + const RGBQUAD *color_table = wined3d_palette_get_rgbquads(palette->wineD3DPalette); > + SetDIBColorTable(*hdc, 0, 256, color_table); > + } ... > +const RGBQUAD * CDECL wined3d_palette_get_rgbquads(const struct wined3d_palette *palette) > +{ > + return palette->colors; > +} That's a pretty terrible interface, it shouldn't be very hard to come up with something better.

1 0