- wine-devel - winehq.org

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v3)
by Bruno Jesus 05 Jul '16

05 Jul '16

On Tue, Jul 5, 2016 at 10:33 AM, Matthieu Nottale <matthieu.nottale(a)infinit.io> wrote: > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. It still looks like there is a formatting problem with the patch, please attach it in a new attempt or use git send-email, also see the comments below. > Signed-off-by: Matthieu Nottale <matthieu.nottale(a)infinit.io> > --- > dlls/ws2_32/socket.c | 22 ++++++++------------- > dlls/ws2_32/tests/sock.c | 51 > ++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 59 insertions(+), 14 deletions(-) > > + enabled = 2; > + len = sizeof(enabled); > + ret = getsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, &len); > + if (ret) { > + ok(!ret, "Failed to check IPV6_V6ONLY ((LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } If the ok() is supposed to always fail use ok(0, ...). But according to msdn this option is not present in 2003/XP, so you would end up with an error. Better to use win_skip then to avoid this problem. The testbot will test against many different Windows versions so we need to ensure it works everywhere, before resending it would be useful to do a manual run at https://testbot.winehq.org/ to check the patch. > + ok(enabled == 1, "IPV6_V6ONLY is not enabled by default.\n"); > + ret = setsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, len); > + if (ret) { > + ok(!ret, "Failed to disable IPV6_V6ONLY (LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } This should never fail as the previous test already took care of checking for IPV6_V6ONLY support, so drop the if and goto. > + enabled = 2; > + len = sizeof(enabled); > + ret = getsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, &len); > + if (ret) { > + ok(!ret, "Failed to check IPV6_V6ONLY (LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } Again I think getsockopt must always work at this point. > + ok(!enabled, "IPV6_V6ONLY is enabled after bind.\n"); > + v4 = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); > + if (v4 == INVALID_SOCKET) { > + skip("Could not create IPv4 socket (LastError: %d).\n", > + WSAGetLastError()); > + goto end; > + } > + WSASetLastError(0xdeadbeef); > + ret = bind(v4, (struct sockaddr*)&sin4, sizeof(sin4)); Please also test ok(ret,...); Best wishes, Bruno

1 0

Re: [PATCH v2 3/5] shell32/tests: Add tests for FolderItems.
by Nikolay Sivov 05 Jul '16

05 Jul '16

On 05.07.2016 8:47, Alex Henrie wrote: > + if (0) /* crashes on all versions of Windows */ > + { > + r = FolderItems_get_Count(items, NULL); > +todo_wine > + ok(r == E_INVALIDARG, "expected E_INVALIDARG, got %08x\n", r); > + } Why do you want to handle this case if it crashes consistently on Windows? And todo_wine is not going to do anything in commented block obviously.

2 6

Re: [PATCH 6/7] d3drm: Implement IDirect3DRMViewport*::Init. (v3)
by Henri Verbeet 05 Jul '16

05 Jul '16

On 27 June 2016 at 23:54, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > static HRESULT WINAPI d3drm_viewport1_Init(IDirect3DRMViewport *iface, IDirect3DRMDevice *device, > IDirect3DRMFrame *camera, DWORD x, DWORD y, DWORD width, DWORD height) > { > - FIXME("iface %p, device %p, camera %p, x %u, y %u, width %u, height %u stub!\n", > - iface, device, camera, x, y, width, height); > + struct d3drm_viewport *viewport = impl_from_IDirect3DRMViewport(iface); > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame(camera); Using impl_from_IDirect3DRMFrame() here is unusual. > + if (!device || !camera) > + return D3DRMERR_BADOBJECT; And note that this only works because of the d3drm_frame structure layout. You'll want to use unsafe_impl_from_IDirect3DRMFrame() if "camera" can be NULL.

1 0

Re: ntdll: Add RtlRestoreContext implementation
by Sebastian Lackner 05 Jul '16

05 Jul '16

On 04.07.2016 10:55, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/kernel32/kernel32.spec | 2 +- > dlls/ntdll/ntdll.spec | 1 + > dlls/ntdll/signal_x86_64.c | 73 +++++++++++++++++++++++++-------------------- > 3 files changed, 42 insertions(+), 34 deletions(-) > Your patch also changes unwinding behavior in case of MSVCRT_JUMP_BUFFER. Previously the instruction pointer stored in the jump buffer was ignored, now it will overwrite the value passed as target_ip. Is that intentional?

2 1

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v3)
by Marvin 05 Jul '16

05 Jul '16

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=23992 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: krnl386.exe16: Fix a typo in comment.
by Huw Davies 05 Jul '16

05 Jul '16

On Tue, Jul 05, 2016 at 03:36:30PM +0300, Andrey Gusev wrote: > diff --git a/dlls/krnl386.exe16/file.c b/dlls/krnl386.exe16/file.c > index 4e7f7c4..44b1e75 100644 > --- a/dlls/krnl386.exe16/file.c > +++ b/dlls/krnl386.exe16/file.c > @@ -549,7 +549,7 @@ INT16 WINAPI GetPrivateProfileString16( LPCSTR section, LPCSTR entry, > if (!entry) > { > /* We have to return the list of keys in the section but without the values > - * so we need to massage the results of GetPrivateProfileSectionA. > + * so we need to message the results of GetPrivateProfileSectionA. > */ > UINT ret, oldlen = len, size = min( len, 1024 ); > LPSTR data, src; No, again the original is correct. Huw.

1 0

Re: gdi32/dibdrv: Fix a typo in comment.
by Huw Davies 05 Jul '16

05 Jul '16

On Tue, Jul 05, 2016 at 03:33:39PM +0300, Andrey Gusev wrote: > diff --git a/dlls/gdi32/dibdrv/graphics.c b/dlls/gdi32/dibdrv/graphics.c > index bfb3451..ca357b2 100644 > --- a/dlls/gdi32/dibdrv/graphics.c > +++ b/dlls/gdi32/dibdrv/graphics.c > @@ -1567,7 +1567,7 @@ COLORREF dibdrv_SetPixel( PHYSDEV dev, INT x, INT y, COLORREF color ) > rect.bottom = rect.top + 1; > add_clipped_bounds( pdev, &rect, pdev->clip ); > > - /* SetPixel doesn't do the 1bpp massaging like other fg colors */ > + /* SetPixel doesn't do the 1bpp messaging like other fg colors */ > pixel = get_pixel_color( dev->hdc, &pdev->dib, color, FALSE ); > color = pdev->dib.funcs->pixel_to_colorref( &pdev->dib, pixel ); No, the original is correct. Huw.

1 0

Re: [PATCH 2/5] shell32: Stub out FolderItems.
by Sebastian Lackner 05 Jul '16

05 Jul '16

On 04.07.2016 07:25, Alex Henrie wrote: > Cc: Christian Costa <titan.costa(a)gmail.com> > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Wine Staging has included a similar patch since 1.7.51, however this > patch is not based on theirs. Actually the patch looks very similar, but this is probably caused by the fact that you both wrote it based on existing code. > > FolderItems2 worked in Windows 2000, but it was removed when > FolderItems3 was introduced in Windows XP. However, it doesn't hurt us > to provide this interface anyway for any old applications that might > want it. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shell32_main.h | 1 + > dlls/shell32/shelldispatch.c | 207 ++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 206 insertions(+), 2 deletions(-) > Some of the variable names (for example ppTInfo, rgszNames, rgDispId) sound a bit odd. Usually variable names without ugly prefix are preferred for new code (except we want to keep it for compatibility with old code here?). > +static HRESULT WINAPI FolderItemsImpl_Item(FolderItems3 *iface, VARIANT index, FolderItem **ppid) > +{ > + FIXME("(%p,%p)\n", iface, ppid); You forgot to trace the index parameter here. > + > + return E_NOTIMPL; > +} [...] > @@ -1093,8 +1297,7 @@ static HRESULT WINAPI FolderImpl_Items(Folder3 *iface, FolderItems **ppid) > { > FIXME("(%p,%p)\n", iface, ppid); You forgot to change the FIXME to a TRACE. > > - *ppid = NULL; > - return E_NOTIMPL; > + return FolderItems_Constructor(ppid); > } > > static HRESULT WINAPI FolderImpl_ParseName(Folder3 *iface, BSTR name, FolderItem **item) >

3 3

Re: [PATCH v2 2/5] shell32: Stub out FolderItems.
by Nikolay Sivov 05 Jul '16

05 Jul '16

On 05.07.2016 8:47, Alex Henrie wrote: > Cc: Christian Costa <titan.costa(a)gmail.com> > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Wine Staging has included a similar patch since 1.7.51, however this > patch is not based on theirs. > > FolderItems2 worked in Windows 2000, but it was removed when > FolderItems3 was introduced in Windows XP. However, it doesn't hurt us > to provide this interface anyway for any old applications that might > want it. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/shell32/shell32_main.h | 1 + > dlls/shell32/shelldispatch.c | 207 ++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 206 insertions(+), 2 deletions(-) > > diff --git a/dlls/shell32/shell32_main.h b/dlls/shell32/shell32_main.h > index 492f79f..64a26bb 100644 > --- a/dlls/shell32/shell32_main.h > +++ b/dlls/shell32/shell32_main.h > @@ -234,6 +234,7 @@ enum tid_t { > IShellDispatch6_tid, > IShellFolderViewDual3_tid, > Folder3_tid, > + FolderItems3_tid, > FolderItem2_tid, > FolderItemVerb_tid, > FolderItemVerbs_tid, That's not going to work, you have to update tid_ids[] too. Also please keep it sorted. > diff --git a/dlls/shell32/shelldispatch.c b/dlls/shell32/shelldispatch.c > index 6dece6d..3661430 100644 > --- a/dlls/shell32/shelldispatch.c > +++ b/dlls/shell32/shelldispatch.c > @@ -65,6 +65,11 @@ typedef struct { > } FolderImpl; > > typedef struct { > + FolderItems3 FolderItems3_iface; > + LONG ref; > +} FolderItemsImpl; > + > +typedef struct { > FolderItem2 FolderItem2_iface; > LONG ref; > VARIANT dir; > @@ -97,6 +102,11 @@ static inline FolderImpl *impl_from_Folder(Folder3 *iface) > return CONTAINING_RECORD(iface, FolderImpl, Folder3_iface); > } > > +static inline FolderItemsImpl *impl_from_FolderItems(FolderItems3 *iface) > +{ > + return CONTAINING_RECORD(iface, FolderItemsImpl, FolderItems3_iface); > +} > + > static inline FolderItemImpl *impl_from_FolderItem(FolderItem2 *iface) > { > return CONTAINING_RECORD(iface, FolderItemImpl, FolderItem2_iface); > @@ -939,6 +949,200 @@ static HRESULT FolderItem_Constructor(VARIANT *dir, FolderItem **ppfi) > return ret; > } > > +static HRESULT WINAPI FolderItemsImpl_QueryInterface(FolderItems3 *iface, > + REFIID riid, LPVOID *ppv) > +{ > + FolderItemsImpl *This = impl_from_FolderItems(iface); > + > + TRACE("(%p,%p,%p)\n", iface, riid, ppv); Usually we trace riid. > + > + if (!ppv) return E_INVALIDARG; This is unusual, do we have a test for that?

1 0

Re: PATCH] ws2_32: Allow user to enable IP dual stack.
by Bruno Jesus 04 Jul '16

04 Jul '16

On Mon, Jul 4, 2016 at 6:35 AM, Matthieu Nottale <matthieu.nottale(a)infinit.io> wrote: > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. Hi, thanks for the updated version. I believe the patch failed to apply because you added text after it and also an attachment which is inlined while the email is being parsed. The result you can see at [1]. The subject should show how many attempts the patch was sent to, so next subject should be: [PATCH] ws2_32: Allow user to enable IP dual stack (v3) Please see some nitpicks below. [1] http://source.winehq.org/patches/data/123921 > Signed-off-by: Matthieu Nottale <matthieu.nottale(a)infinit.io> > --- > dlls/ws2_32/socket.c | 22 ++++++++-------------- > dlls/ws2_32/tests/sock.c | 40 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 48 insertions(+), 14 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index b0af3d7..c29bd2b 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -3240,20 +3240,6 @@ int WINAPI WS_bind(SOCKET s, const struct > WS_sockaddr* name, int namelen) > } > else > { > -#ifdef IPV6_V6ONLY > - const struct sockaddr_in6 *in6 = (const struct > sockaddr_in6*) &uaddr; > - if (name->sa_family == WS_AF_INET6 && > - !memcmp(&in6->sin6_addr, &in6addr_any, sizeof(struct > in6_addr))) > - { > - int enable = 1; > - if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &enable, > sizeof(enable)) == -1) > - { > - release_sock_fd( s, fd ); > - SetLastError(WSAEAFNOSUPPORT); > - return SOCKET_ERROR; > - } > - } > -#endif > if (name->sa_family == WS_AF_INET) > { > struct sockaddr_in *in4 = (struct sockaddr_in*) &uaddr; > @@ -7163,6 +7149,14 @@ SOCKET WINAPI WSASocketW(int af, int type, int > protocol, > TRACE("\tcreated %04lx\n", ret ); > if (ipxptype > 0) > set_ipx_packettype(ret, ipxptype); > +#ifdef IPV6_V6ONLY > + if (unixaf == AF_INET6) > + { > + /* Winsock documentation stipulates that IPV6_V6ONLY is enabled > by default*/ The documentation is not always useful (and sometimes wrong) and now we should have a test to back this up, I believe a better comment to be: /* AF_INET6 sockets have IPV6_V6ONLY enabled by default. */ Watch out for missing space between the last comment word and the */ > + int enable = 1; > + WS_setsockopt(ret, WS_IPPROTO_IPV6, WS_IPV6_V6ONLY, &enable, > sizeof(enable)); > + } > +#endif > return ret; > } > > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 6853279..7c8d834 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -6114,6 +6114,46 @@ static void test_ipv6only(void) > ok(!ret, "Could not bind IPv4 address (LastError: %d; %d expected if > IPv6 binds to IPv4 as well).\n", > WSAGetLastError(), WSAEADDRINUSE); > > + if (v4 != INVALID_SOCKET) > + closesocket(v4); > + if (v6 != INVALID_SOCKET) > + closesocket(v6); > + > + /* Test again, this time disabling V6ONLY*/ > + v6 = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP); > + if (v6 == INVALID_SOCKET) { > + skip("Could not create IPv6 socket (LastError: %d; %d expected if > IPv6 not available).\n", > + WSAGetLastError(), WSAEAFNOSUPPORT); > + goto end; > + } Do a getsockopt at this point to check what is the default enabled value. Set enabled to the opposite of what you expected before the call and test its value after. > + DWORD enabled = 0; > + int len = sizeof(enabled); You cannot declare variables like this in C89 (?) so do it in the function beginning. > + ret = setsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, len); > + if (ret) { > + ok(!ret, "Failed to disable IPV6_V6ONLY (LastError: %d).\n", > WSAGetLastError()); > + goto end; > + } I understand that you are trying to skip when IPV6_V6ONLY is not present. It will be better if you catch the explicit error case and bail out, something like: WSASetLastError(0xdeadbeef); ret = setsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, &enabled, len); error = WSAGetLastError(); if (ret) { ok(error == EXPECTED_ERROR, "Failed to disable IPV6_V6ONLY (LastError %d, %d expected).\n", error, EXPECTED_ERROR); goto end; } > ... Best wishes, Bruno

1 0

Re: [PATCH v2 05/11] d3d11/tests: Add test for creating unordered access views.
by Henri Verbeet 04 Jul '16

04 Jul '16

On 4 July 2016 at 12:26, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static void test_create_unordered_access_view(void) > +{ > + static const D3D_FEATURE_LEVEL feature_level = D3D_FEATURE_LEVEL_11_0; > + D3D11_UNORDERED_ACCESS_VIEW_DESC uav_desc; > + D3D11_TEXTURE3D_DESC texture3d_desc; > + D3D11_TEXTURE2D_DESC texture2d_desc; > + ULONG refcount, expected_refcount; > + D3D11_SUBRESOURCE_DATA data = {0}; > + ID3D11UnorderedAccessView *uav; > + struct device_desc device_desc; > + D3D11_BUFFER_DESC buffer_desc; > + ID3D11Device *device, *tmp; > + ID3D11Texture3D *texture3d; > + ID3D11Texture2D *texture2d; > + ID3D11Resource *texture; > + ID3D11Buffer *buffer; > + IUnknown *iface; This is unused.

1 0

Re: PATCH] ws2_32: Allow user to enable IP dual stack.
by Marvin 04 Jul '16

04 Jul '16

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=23959 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/2] msvcr120: Add fegetenv implementation
by Marvin 04 Jul '16

04 Jul '16

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=23946 Your paranoid android. === w2008s64 (32 bit msvcr120) === msvcr120.c:706: Test failed: env.status = 0 === w2008s64 (64 bit msvcr120) === msvcr120.c:706: Test failed: env.status = 10

1 0

Re: [PATCH] advapi32: Add some tests for StartTrace(). (v2)
by Marvin 04 Jul '16

04 Jul '16

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=23944 Your paranoid android. === wxppro (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w2003std (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === wvistau64 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w2008s64 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w7u (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w7pro64 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w8 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w864 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161 === w1064 (32 bit eventlog) === eventlog.c:1224: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1235: Test failed: Expected ERROR_INVALID_PARAMETER, got 161 eventlog.c:1264: Test failed: Expected success eventlog.c:1272: Test failed: Expected ERROR_ALREADY_EXISTS, got 161

1 0

Re: [PATCH] advapi32: Add some tests for StartTrace(). (v2)
by Austin English 04 Jul '16

04 Jul '16

On Jul 4, 2016 1:25 AM, "Zebediah Figura" <z.figura12(a)gmail.com> wrote: > > --- > dlls/advapi32/tests/eventlog.c | 139 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 139 insertions(+) > > diff --git a/dlls/advapi32/tests/eventlog.c b/dlls/advapi32/tests/eventlog.c > index 3ca59c3..5163537 100644 > --- a/dlls/advapi32/tests/eventlog.c > +++ b/dlls/advapi32/tests/eventlog.c > @@ -20,12 +20,15 @@ > > #include <stdarg.h> > > +#include "initguid.h" > #include "windef.h" > #include "winbase.h" > #include "winerror.h" > #include "winnt.h" > #include "winreg.h" > #include "sddl.h" > +#include "wmistr.h" > +#include "evntrace.h" > > #include "wine/test.h" > > @@ -1142,6 +1145,141 @@ static void cleanup_eventlog(void) > ok(bret, "Expected MoveFileEx to succeed: %d\n", GetLastError()); > } > > +static void test_trace(void) > +{ > + const char sessionname[] = "Wine"; > + const char filepath[] = "wine.etl"; > + const LONG lnoffset = ((sizeof(EVENT_TRACE_PROPERTIES) >> 3) + 1) << 3; //pad to 8 bytes > + const LONG lfnoffset = (((lnoffset + sizeof(sessionname)) >> 3) + 1) << 3; //pad to 8 bytes Please avoid C++ style comments, use /* this instead */

1 0

Re: [PATCH signed-off] secur32 : add and fix some algids
by Jacek Caban 03 Jul '16

03 Jul '16

Hi Max, On 27.06.2016 05:29, Max Qian wrote: > Signed-off-by: Max Qian <public(a)maxqia.com> > --- > dlls/secur32/schannel_gnutls.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/dlls/secur32/schannel_gnutls.c b/dlls/secur32/schannel_gnutls.c > index bcadd47..9d6af60 100644 > --- a/dlls/secur32/schannel_gnutls.c > +++ b/dlls/secur32/schannel_gnutls.c > @@ -316,10 +316,11 @@ static ALG_ID schannel_get_mac_algid(gnutls_mac_algorithm_t mac) > case GNUTLS_MAC_UNKNOWN: > case GNUTLS_MAC_NULL: return 0; > case GNUTLS_MAC_MD5: return CALG_MD5; > - case GNUTLS_MAC_SHA1: > - case GNUTLS_MAC_SHA256: > - case GNUTLS_MAC_SHA384: > - case GNUTLS_MAC_SHA512: return CALG_SHA; > + case GNUTLS_MAC_SHA1: return CALG_SHA1; > + case GNUTLS_MAC_MD2: return CALG_MD2; > + case GNUTLS_MAC_SHA256: return CALG_SHA_256; > + case GNUTLS_MAC_SHA384: return CALG_SHA_384; > + case GNUTLS_MAC_SHA512: return CALG_SHA_512; > default: > FIXME("unknown algorithm %d\n", mac); > return 0; > @@ -331,8 +332,12 @@ static ALG_ID schannel_get_kx_algid(gnutls_kx_algorithm_t kx) > switch (kx) > { > case GNUTLS_KX_RSA: return CALG_RSA_KEYX; > + case GNUTLS_KX_DHE_PSK: > case GNUTLS_KX_DHE_DSS: > case GNUTLS_KX_DHE_RSA: return CALG_DH_EPHEM; > + case GNUTLS_KX_ECDHE_RSA: > + case GNUTLS_KX_ECDHE_PSK: return CALG_ECDH; MSDN mentions CALG_ECDH_EPHEM, which would fit better, but it seems to be missing in headers. Returning CALG_ECDH is fine with me, but please add a comment about CALG_ECDH_EPHEM. > + case GNUTLS_KX_ECDHE_ECDSA: return CALG_ECDSA; You're mixing tabs and spaces. Please avoid using tabs. Thanks, Jacek

3 2

Re: [PATCH] wined3d/resource: Performance improvement
by Patrick Rudolph 03 Jul '16

03 Jul '16

On 2016-07-03 11:55 AM, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2016-07-03 um 10:04 schrieb Henri Verbeet: >> Finally, there the possibility that Windows filters invalid flag >> combinations like Wine currently does, and picking either DISCARD >> or NOOVERWRITE will break an application that depends on that. > When I originally added support for dynamic buffers in 2010 or so I > just forwarded the flags to the driver. That did break some > applications. I'll try to find out which one it was, I believe I put > some details in the patch description. > > It's also possible that there are some differences between textures > and buffers. In d3d <= 9, D3DLOCK_NOOVERWRITE is not supported on > textures. So it might be filtered out, and DISCARD prevails. But my > understanding is that Unigine uses the questionable combination on > buffers, not textures. > It uses both flags on buffers in d3d9 mode. I'm going to add tests for it. Regards, Patrick > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJXeOEWAAoJEN0/YqbEcdMwBRQP/jsjUZXuKbUeoh3iaorwY02B > qZXhtc2IbQlZt2989jAGIjuZoCtE2sP8oRkmtbGI3nfIthOxFKrwcPKnqYiz40aF > JqCqYiwMNSpcqDKEhC92w8ad4F8AMBIG/4IUVBtU/uL0W2fBKNJ0rKE4v2sNefo1 > OTa0ZCtUSCbvErO9xgen43KparIRNK1juxlkE7CVHkWwK3oBl8GO+IzJ6ZKSN54A > ftz48C7if3y0ul2Xs/HVC/J3UqnksgL1sRnxUeDrFC6MRsNQZaf0D3Gn9vUdqukt > t+hxArnt6DEgMiPlbh3Zhoso4lNzoJJxPpldmWYAgEiU5l6BqVnvSuDUzZZGjLqz > 8dg0QEzjDbta5rLwMi6NnZxTYinx8F61YMOUSfMIkKofz4Xc7v2TnEsgMRI9XuoV > f9KZVssvpYoBuQHI0qEpK4eEBqlU/ZtFh39O+j13980Z6wNtnCQVYUtMcY8hU8Nv > kf5iN/eOuMVrMV6EKqZswJe1CHfAfhVhLfD9kOMRREb5MjrAVyreigbHR/RXG3BH > K9bWwCnnaVfQDtJzUw9ab+e+uSbkkiymjrkWY8JKI3E0d8YBnupxS8GcwJTT0y0t > x5K/Fzp/a2U+x4FV8MZewIhT4azA+DEsgHi/6dviRi6/8ct6J4TTZZqCRKtgWFBy > O8waYy1TvNoBQETnhMaC > =7Pmz > -----END PGP SIGNATURE-----

1 0

Re: Re: [PATCH] wined3d/resource: Performance improvement
by Patrick Rudolph 03 Jul '16

03 Jul '16

> It makes logical sense to me that mapping a buffer with both DISCARD and > NOOVERWRITE would effectively ignore NOOVERWRITE. I've noticed that at > least some engines will map a part of a buffer with NOOVERWRITE and draw > with that part, map the next part of the buffer with NOOVERWRITE and > draw with that part, etc, then after the last part of the buffer it maps > with DISCARD to get new memory and keep going while the previous buffer > memory is handled asynchronously by the driver or card. > > I notice that wined3d has some parts where it ignores/removes DISCARD, > so it may not be a good idea to leave both DISCARD and NOOVERWRITE set. > In such a case, the driver will get NOOVERWRITE for a part of the buffer > that's still in use. It would probably be better to remove NOOVERWRITE > when both DISCARD and NOOVERWRITE are set. Both flags are independent of each other and provide useful information to the OpenGL driver. The driver knows best how to map the resource. By passing NOOVERWRITE and DISCARD it's likely going to use NOOVERWRITE, as it's even less overhead than DISCARD. I don't think that WINE should drop flags, except there's a driver bug that can't be fixed (in the near future). Regards, Patrick

3 2

Re: [PATCH 3/3] kernel32/tests/thread: Add tests for fiber-local storage.
by Marvin 02 Jul '16

02 Jul '16

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=23919 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

1 0

Re: [PATCH 2/3] kernel32/tests/loader: Add tests for fiber-local storage.
by Marvin 02 Jul '16

02 Jul '16

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=23918 Your paranoid android. === w2003std (32 bit loader) === loader.c:1772: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1545: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1550: Test failed: wrong FLS callback count 1, expected 2 loader.c:1774: Test failed: FlsGetValue failed with error 87 loader.c:1774: Test failed: FlsGetValue failed with error 87 loader.c:1545: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1550: Test failed: wrong FLS callback count 0, expected 1 loader.c:1774: Test failed: FlsGetValue failed with error 87 loader.c:1774: Test failed: FlsGetValue failed with error 87 loader.c:1772: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1772: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1545: Test failed: FlsGetValue returned 00031415, expected NULL loader.c:1550: Test failed: wrong FLS callback count 2, expected 3 loader.c:1774: Test failed: FlsGetValue failed with error 87 loader.c:1774: Test failed: FlsGetValue failed with error 87 === w864 (32 bit loader) === loader.c:1917: Test failed: expected STILL_ACTIVE, got 195 loader.c:1952: Test failed: expected STILL_ACTIVE, got 195 === w1064 (32 bit loader) === loader.c:2830: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2830: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2830: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2838: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2839: Test failed: Test 3: Wrong callback count: 0 loader.c:2838: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2839: Test failed: Test 4: Wrong callback count: 0 loader.c:1917: Test failed: expected STILL_ACTIVE, got 195 loader.c:1952: Test failed: expected STILL_ACTIVE, got 195 === w1064 (64 bit loader) === loader.c:2830: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 0: expected 00007FFC76DA5510, got 0000000000000000 loader.c:2830: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 1: expected 00007FFC6EFE1B00, got 0000000000000000 loader.c:2830: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2831: Test failed: Test 2: expected 00007FFC76DA2390, got 0000000000000000 loader.c:2838: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 0000000000000000 loader.c:2839: Test failed: Test 3: Wrong callback count: 0 loader.c:2838: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 0000000000000000 loader.c:2839: Test failed: Test 4: Wrong callback count: 0 loader.c:1917: Test failed: expected STILL_ACTIVE, got 195 loader.c:1952: Test failed: expected STILL_ACTIVE, got 195

1 0

Re: [PATCH 1/3] kernel32/tests/fiber: Add tests for fiber-local storage.
by Marvin 02 Jul '16

02 Jul '16

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=23917 Your paranoid android. === w2003std (32 bit fiber) === fiber: unhandled exception c0000005 at 77E61897

1 0

Re: mmdevapi/tests: Fix typos in a few ok() messages.
by Marvin 02 Jul '16

02 Jul '16

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=23913 Your paranoid android. === w8 (32 bit capture) === capture.c:181: Test failed: Position 1015 expected 0 capture.c:231: Test failed: Position 2167 expected 1463 capture.c:263: Test failed: Position 2167 expected 1463 capture.c:325: Test failed: Position 3255 gap 1344 capture.c:349: Test failed: Position 4343 expected 3703 capture.c:374: Test failed: Position 4791 expected 4151 === w864 (32 bit capture) === capture.c:181: Test failed: Position 1015 expected 0 capture.c:231: Test failed: Position 2167 expected 1463 capture.c:263: Test failed: Position 2167 expected 1463 capture.c:325: Test failed: Position 3255 gap 1344 capture.c:329: Test failed: GCP 13888 vs. BufferSize 21996 capture.c:349: Test failed: Position 4343 expected 3703 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 4791 expected 4151 === w1064 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:263: Test failed: Position 2167 expected 1527 capture.c:325: Test failed: Position 4151 gap 2176 capture.c:329: Test failed: GCP 11648 vs. BufferSize 21996 capture.c:349: Test failed: Position 5239 expected 4599 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 5687 expected 5047 === w864 (64 bit capture) === capture.c:181: Test failed: Position 119 expected 0 capture.c:231: Test failed: Position 2167 expected 567 capture.c:263: Test failed: Position 2167 expected 567 capture.c:325: Test failed: Position 3191 gap 2176 === w1064 (64 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:263: Test failed: Position 2167 expected 1527 capture.c:325: Test failed: Position 4151 gap 2176 capture.c:329: Test failed: GCP 12992 vs. BufferSize 21996 capture.c:349: Test failed: Position 5303 expected 4599 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 5751 expected 5047

1 0

Re: [PATCH] winspool.drv: Support cups 2.2 header update
by Bruno Jesus 01 Jul '16

01 Jul '16

On Fri, Jul 1, 2016 at 6:32 PM, Michael Cronenworth <mike(a)cchtml.com> wrote: > Signed-off-by: Michael Cronenworth <mike(a)cchtml.com> > --- > dlls/winspool.drv/info.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/winspool.drv/info.c b/dlls/winspool.drv/info.c > index 3ba94cd..5468066 100644 > --- a/dlls/winspool.drv/info.c > +++ b/dlls/winspool.drv/info.c > @@ -43,6 +43,9 @@ > #include <signal.h> > #ifdef HAVE_CUPS_CUPS_H > # include <cups/cups.h> > +# if CUPS_VERSION_MAJOR > 2 || (CUPS_VERSION_MAJOR == 2 && CUPS_VERSION_MINOR > 1) > +# include <cups/ppd.h> > +# endif > #endif Hi, AFAICS this other patch from Ken Thomases in the queue will do the same: http://source.winehq.org/patches/data/123755 Best wishes, Bruno

1 0

Re: [PATCH] ws2_32: Allow user to enable IP dual stack.
by Bruno Jesus 01 Jul '16

01 Jul '16

On Thu, Jun 30, 2016 at 5:57 AM, Matthieu Nottale <matthieu.nottale(a)infinit.io> wrote: > > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. Hi, can you explain more about what is the problem? Is there any application affected? > @@ -7163,6 +7149,14 @@ SOCKET WINAPI WSASocketW(int af, int type, int protocol, > TRACE("\tcreated %04lx\n", ret ); > if (ipxptype > 0) > set_ipx_packettype(ret, ipxptype); > +#ifdef IPV6_V6ONLY > + if (af == WS_AF_INET6) > + { > + // dual stack (v4+v6) should be disabled by default > + int enable = 1; > + WS_setsockopt(ret, WS_IPPROTO_IPV6, WS_IPV6_V6ONLY, &enable, sizeof(enable)); > + } > +#endif > return ret; > } // comments are not allowed, use /* */. Please use unixaf == AF_INET6 as the code uses that as the af var was already parsed by this point in the code. And please write tests to prove this behavior, create the AF_INET6 socket and getsockopt(IPV6_V6ONLY) in order to determine the default on Windows and then bind and read again to prove it does not change automagically (like Wine is doind). Since in Wine the operation is only done when binding to anyaddr it should be useful to also try a specific address bind and check too. Best wishes, Bruno

1 0

Re: [PATCH] xaudio2: Always set current OpenAL context before making AL calls
by Chris Robinson 30 Jun '16

30 Jun '16

On 06/30/2016 12:07 PM, Andrew Eikum wrote: > if(!alcIsExtensionPresent(NULL, "ALC_SOFT_loopback") || > !(palcLoopbackOpenDeviceSOFT = alcGetProcAddress(NULL, "alcLoopbackOpenDeviceSOFT")) || > - !(palcRenderSamplesSOFT = alcGetProcAddress(NULL, "alcRenderSamplesSOFT"))){ > + !(palcRenderSamplesSOFT = alcGetProcAddress(NULL, "alcRenderSamplesSOFT")) || > + !(palcSetThreadContext = alcGetProcAddress(NULL, "alcSetThreadContext"))){ > ERR("XAudio2 requires the ALC_SOFT_loopback extension (OpenAL-Soft >= 1.14)\n"); > return FALSE; > } alcSetThreadContext isn't part of the ALC_SOFT_loopback extension, you should check for ALC_EXT_thread_local_context instead. > +static void context_lock(ALCcontext *ctx) > +{ > + EnterCriticalSection(&al_lock); > + alcMakeContextCurrent(ctx); > +} > + > +static void context_unlock(void) > +{ > + LeaveCriticalSection(&al_lock); > +} Since you're relying on ALC_EXT_thread_local_context anyway, it would probably be better to use alcSetThreadContext in context_lock, which would allow you to get rid of the global lock for normal calls (another thread can't change the current thread context on you, and unlike OpenGL, the same context can be current on multiple threads at the same time).

2 1

Re: [PATCH] wined3d/resource: Performance improvement
by Chris Robinson 30 Jun '16

30 Jun '16

On 06/30/2016 10:20 AM, Patrick Rudolph wrote: > Tests on Windows showed that mapping a buffer with flags WINED3D_MAP_DISCARD > and WINED3D_MAP_NOOVERWRITE is valid combination. Writing reliable tests > is difficult as the driver is free to choose when using discard. > > Unigine Heavon maps a lot of buffers with both flags, but run on about > 85% GPU-load, as WINE removes both hints and the game has to wait for > the buffer to be mapped. It makes logical sense to me that mapping a buffer with both DISCARD and NOOVERWRITE would effectively ignore NOOVERWRITE. I've noticed that at least some engines will map a part of a buffer with NOOVERWRITE and draw with that part, map the next part of the buffer with NOOVERWRITE and draw with that part, etc, then after the last part of the buffer it maps with DISCARD to get new memory and keep going while the previous buffer memory is handled asynchronously by the driver or card. I notice that wined3d has some parts where it ignores/removes DISCARD, so it may not be a good idea to leave both DISCARD and NOOVERWRITE set. In such a case, the driver will get NOOVERWRITE for a part of the buffer that's still in use. It would probably be better to remove NOOVERWRITE when both DISCARD and NOOVERWRITE are set.

1 0

Re: [PATCH 6/7] d3drm: Implement IDirect3DRMViewport*::Init. (v3)
by Aaryaman Vasishta 30 Jun '16

30 Jun '16

On Tue, Jun 28, 2016 at 3:24 AM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > > + if (viewport->d3d_viewport) > + return D3DRMERR_BADOBJECT; > + > + IDirect3DRM_AddRef(viewport->d3drm); > + > FWIW, I didn't put the intentional d3drm, camera leaks here because it seems that the device controls the leaked references via some sort of destroy callback on the device. (See the todo_wine tests in this patch). > + todo_wine ok(ref4 > frame_ref2, "Expected ref4 > frame_ref2, got > frame_ref2 = %u, ref4 = %u.\n", frame_ref2, ref4); > + > + IDirect3DRMDevice3_Release(device3); > + IDirect3DRMDevice_Release(device1); > I tried to release d3drm explicitly myself, like how I did with the texture tests. But the tests would then crash here, at IDirect3DRMDevice_Release, where the device gets destroyed. Which probably indicates that the device stores a list of leaked references and releases them on getting destroyed. For now I've decided to avoid the leak, thus avoiding the use of a destroy callback, and implementing this as a separate later on if an application demands it, unless it's safer to get this done on priority. Cheers, Aaryaman

1 0

Re: [PATCH 5/7] d3drm: Fix device not assigning width and height after creation.
by Henri Verbeet 30 Jun '16

30 Jun '16

On 24 June 2016 at 23:49, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > HRESULT d3drm_device_set_ddraw_device_d3d(struct d3drm_device *device, IDirect3DRM *d3drm, IDirect3D *d3d, IDirect3DDevice *d3d_device) > { > + IDirectDrawSurface *surface; > + IDirect3DDevice2 *d3d_device2; > + DDSURFACEDESC desc; > + HRESULT hr; > + > device->d3drm = d3drm; > IDirect3DRM_AddRef(d3drm); > device->device = d3d_device; > IDirect3DDevice_AddRef(d3d_device); > > + /* Fetch render target and get width/height from there */ > + if (FAILED(hr = IDirect3DDevice_QueryInterface(d3d_device, &IID_IDirectDrawSurface, (void **)&surface))) > + { > + if (FAILED(hr = IDirect3DDevice_QueryInterface(d3d_device, &IID_IDirect3DDevice2, (void **)&d3d_device2))) > + return hr; > + hr = IDirect3DDevice2_GetRenderTarget(d3d_device2, &surface); > + IDirect3DDevice2_Release(d3d_device2); > + if (FAILED(hr)) > + return hr; > + } > + > + desc.dwSize = sizeof(desc); > + if (FAILED(hr = IDirectDrawSurface_GetSurfaceDesc(surface, &desc))) > + { > + IDirectDrawSurface_Release(surface); > + return hr; > + } > + > + device->width = desc.dwWidth; > + device->height = desc.dwHeight; > + IDirectDrawSurface_Release(surface); > + > return IDirect3D_QueryInterface(d3d, &IID_IDirectDraw, (void **)&device->ddraw); > } > This leaks some references (IDirect3DRM, IDirect3DDevice) on error paths, are those on purpose?

2 5

Re: [PATCH 4/5] inetcomm: Support LPSTR to LPWSTR conversion in GetProp
by Nikolay Sivov 30 Jun '16

30 Jun '16

Is it possible to use PropVariantChangeType() for such conversion?

1 0

Re: [PATCH 1/5] inetcomm: Implement IMimeBody DeleteProp
by Nikolay Sivov 30 Jun '16

30 Jun '16

On 06/30/2016 11:58 AM, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/inetcomm/mimeole.c | 23 +++++++++++++++++-- > dlls/inetcomm/tests/mimeole.c | 53 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 74 insertions(+), 2 deletions(-) > > diff --git a/dlls/inetcomm/mimeole.c b/dlls/inetcomm/mimeole.c > index 766503d..cff95a1 100644 > --- a/dlls/inetcomm/mimeole.c > +++ b/dlls/inetcomm/mimeole.c > @@ -898,8 +898,27 @@ static HRESULT WINAPI MimeBody_DeleteProp( > LPCSTR pszName) > { > MimeBody *This = impl_from_IMimeBody(iface); > - FIXME("(%p)->(%s) stub\n", This, debugstr_a(pszName)); > - return E_NOTIMPL; > + header_t *cursor, *cursor2; > + BOOL found = FALSE; You don't need to initialize 'found'. > + > + TRACE("(%p)->(%s) stub\n", This, debugstr_a(pszName)); 'stub' should be removed, unless it's still too stubby. > + > + LIST_FOR_EACH_ENTRY_SAFE(cursor, cursor2, &This->headers, header_t, entry) > + { > + if(ISPIDSTR(pszName)) > + found = STRTOPID(pszName) == cursor->prop->id; > + else > + found = !lstrcmpiA(pszName, cursor->prop->name); > + > + if(found) > + { > + list_remove(&cursor->entry); > + HeapFree(GetProcessHeap(), 0, cursor); > + return S_OK; > + } > + } > + > + return MIME_E_NOT_FOUND; > } The way you use it, there's no need for _SAFE() list iteration. > static HRESULT WINAPI MimeBody_CopyProps( > diff --git a/dlls/inetcomm/tests/mimeole.c b/dlls/inetcomm/tests/mimeole.c > index 8063b86..46fd1d5 100644 > --- a/dlls/inetcomm/tests/mimeole.c > +++ b/dlls/inetcomm/tests/mimeole.c > @@ -604,6 +604,58 @@ static void test_BindToObject(void) > IMimeMessage_Release(msg); > } > > +static void test_BodyDeleteProp(void) > +{ > + static const char topic[] = "wine topic"; > + HRESULT hr; > + IMimeMessage *msg; > + IMimeBody *body; > + PROPVARIANT prop; > + > + hr = MimeOleCreateMessage(NULL, &msg); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + PropVariantInit(&prop); > + > + hr = IMimeMessage_BindToObject(msg, HBODY_ROOT, &IID_IMimeBody, (void**)&body); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + hr = IMimeBody_DeleteProp(body, "Subject"); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + hr = IMimeBody_DeleteProp(body, PIDTOSTR(PID_HDR_SUBJECT)); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + prop.vt = VT_LPSTR; > + prop.u.pszVal = CoTaskMemAlloc(strlen(topic)+1); > + strcpy(prop.u.pszVal, topic); > + hr = IMimeBody_SetProp(body, "Subject", 0, &prop); > + ok(hr == S_OK, "ret %08x\n", hr); > + PropVariantClear(&prop); > + > + hr = IMimeBody_DeleteProp(body, "Subject"); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + hr = IMimeBody_GetProp(body, "Subject", 0, &prop); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + prop.vt = VT_LPSTR; > + prop.u.pszVal = CoTaskMemAlloc(strlen(topic)+1); > + strcpy(prop.u.pszVal, topic); > + hr = IMimeBody_SetProp(body, PIDTOSTR(PID_HDR_SUBJECT), 0, &prop); > + ok(hr == S_OK, "ret %08x\n", hr); > + PropVariantClear(&prop); > + > + hr = IMimeBody_DeleteProp(body, PIDTOSTR(PID_HDR_SUBJECT)); > + ok(hr == S_OK, "ret %08x\n", hr); > + > + hr = IMimeBody_GetProp(body, PIDTOSTR(PID_HDR_SUBJECT), 0, &prop); > + ok(hr == MIME_E_NOT_FOUND, "ret %08x\n", hr); > + > + IMimeBody_Release(body); > + IMimeMessage_Release(msg); > +} > + > static void test_MimeOleGetPropertySchema(void) > { > HRESULT hr; > @@ -627,6 +679,7 @@ START_TEST(mimeole) > test_MessageGetPropInfo(); > test_MessageOptions(); > test_BindToObject(); > + test_BodyDeleteProp(); > test_MimeOleGetPropertySchema(); > OleUninitialize(); > }

1 0

Re: [v2 1/3] dinput: Print location ID in debugstr_device on the Mac
by Dmitry Timoshkov 30 Jun '16

30 Jun '16

David Lawrie <david.dljunk(a)gmail.com> wrote: > +static Boolean get_device_property_long(IOHIDDeviceRef in_device, CFStringRef in_key, long * out_value) > +{ > + Boolean result = FALSE; > + CFTypeRef type; > + > + if (in_device) > + { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(in_device)); > + > + type = IOHIDDeviceGetProperty(in_device, in_key); > + > + if (type) > + { > + if (CFNumberGetTypeID() == CFGetTypeID(type)) > + result = CFNumberGetValue((CFNumberRef)type, kCFNumberLongType, out_value); > + } > + } > + return result; > +} > + > +long get_device_location_ID(IOHIDDeviceRef device) > +{ > + long result = 0; > + get_device_property_long(device, CFSTR(kIOHIDLocationIDKey), &result); > + return result; > +} The helper should be 'static'. Also, probably you should return value from the helper directly since you don't check for the boolean result anyway. Same comment applies for a similar winejoystick.drv patch. -- Dmitry.

2 1

Re: [PATCH] ddraw/tests: P8 color keying does not work on WARP (v2).
by Marvin 29 Jun '16

29 Jun '16

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=23888 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2540: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2204: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2270: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2355: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH] d3dx9: Avoid overflowing debug channel buffer when tracing ASCII effect errors.
by Alistair Leslie-Hughes 29 Jun '16

29 Jun '16

Hi Matteo, On 29/06/16 03:06, Matteo Bruni wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > Inspired by a patch by Alistair Leslie-Hughes. > > dlls/d3dx9_36/effect.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c trace:d3dx:d3dx9_base_effect_init "Shaders/commonVertexLight.fx(53,7): warning X3205: conversion from larger type t" trace:d3dx:d3dx9_base_effect_init "o smaller, possible loss of data" trace:d3dx:d3dx9_base_effect_init "Shaders/commonVertexLight.fx(55,9): warning X3205: conversion from larger type t" trace:d3dx:d3dx9_base_effect_init "o smaller, possible loss of data" trace:d3dx:d3dx9_base_effect_init "StaticMesh.fx(484,39): warning X3206: implicit truncation of vector type" Hers is the output from your patch. The first too lines are warnings are split across trace statement. Should we use a larger number to attempt to have each error/warning on one line. Best Regards Alistair Leslie-Hughes

2 1

Re: [v1 2/2] dinput/joystick_osx.c: sorts devices by location ID
by Ken Thomases 29 Jun '16

29 Jun '16

On Jun 24, 2016, at 8:33 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Fixes https://bugs.winehq.org/show_bug.cgi?id=38997 > for dinput joysticks > > Note: if multiple virtual joysticks have the same location ID, they will > still be unordered > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/dinput/joystick_osx.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) Similar comments as for the corresponding winejoystick.drv patch, of which this is a subset. -Ken

2 1

Re: [v1 2/2] winejoystick.drv/joystick_osx.c: sorts devices by location ID
by Ken Thomases 29 Jun '16

29 Jun '16

On Jun 24, 2016, at 8:33 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Fixes https://bugs.winehq.org/show_bug.cgi?id=38997 > for winmm joysticks This should probably be a note and go below the "---" line, below. Also, please adjust the subjects of these patches. Take a look at how Alexandre changed the subjects of your previous commits. Try to save him the effort. The prefix should generally be just the DLL name without the name of the specific file (although changes to tests can have "/tests"). The first word after the colon should be capitalized. The verb should be in the imperative mood ("Sort" vs. "Sorts"). If you want to include the information that this patch is for the Mac which is lost by removing the file name, add that to the subject (e.g. "Sort devices by location ID on the Mac"). > @@ -321,6 +321,34 @@ static CFIndex find_top_level(IOHIDDeviceRef hid_device, CFMutableArrayRef main_ > /************************************************************************** > * find_osx_devices > */ You've separated the function header comment above from the function it goes with. > + > +/* > + * Helper to sort array by location ID since they are consistent across boots & launches > + */ Use the function header comment format used elsewhere in the file. > +static CFComparisonResult CFDeviceArrayComparatorFunction(const void *val1, const void *val2, void *context) As with the previous patches, don't start your function names with "CF" which is for Core Foundation functions. There's no reason to include "Function" in the name of a function. Use lowercase-and-underscores. Also, it should mention what it's comparing by or for. For example, "device_location_comparator" similar to button_usage_comparator() elsewhere in this file. > +{ > +#pragma unused(context) Don't bother with that. > + CFComparisonResult result = kCFCompareEqualTo; > + > + long loc1 = IOHIDDevice_GetLocationID((IOHIDDeviceRef)val1); > + long loc2 = IOHIDDevice_GetLocationID((IOHIDDeviceRef)val2); There's no need to cast void pointers to other pointer types. > + if (loc1 < loc2) { > + result = kCFCompareLessThan; > + } else if (loc1 > loc2) { > + result = kCFCompareGreaterThan; > + } If you're going to use braces around these blocks (which isn't necessary), put the braces on separate lines. > +/* > + * Helper to copy the CFSet to a CFArray > + */ > +static void CFSetApplierFunctionCopyToCFArray(const void *value, void *context) I know this name was copied from dinput, but it's still terrible. ;) > +{ > + CFArrayAppendValue((CFMutableArrayRef)context, value); Unneeded cast. > @@ -363,20 +391,16 @@ static int find_osx_devices(void) > if (devset) > { > CFIndex num_devices, num_main_elements; > - const void** refs; > - CFArrayRef devices; > + CFMutableArrayRef devices; > > num_devices = CFSetGetCount(devset); > - refs = HeapAlloc(GetProcessHeap(), 0, num_devices * sizeof(*refs)); > - if (!refs) > - { > - CFRelease(devset); > - goto fail; > - } > > - CFSetGetValues(devset, refs); > - devices = CFArrayCreate(NULL, refs, num_devices, &kCFTypeArrayCallBacks); > - HeapFree(GetProcessHeap(), 0, refs); > + devices = CFArrayCreateMutable(kCFAllocatorDefault, 0, &kCFTypeArrayCallBacks); As a minor optimization, you can specify a capacity to the above call. > + /* copy devices from (unordered) set to array */ > + CFSetApplyFunction(devset, CFSetApplierFunctionCopyToCFArray, (void *)devices); Unneeded cast. > + /* now sort the array by location ID's */ Again, these comments don't add much and better names for the functions would make the code more self-explanatory. It might be worthwhile to put a comment here or in the function header about _why_ you're sorting by location ID (i.e. to provide a stable order across runs). That's a good general rule: comments shouldn't narrate what the code is doing, they should explain why it's doing it, or why it's doing it in a particular way, if that's non-obvious. > + CFArraySortValues(devices, CFRangeMake(0, num_devices), CFDeviceArrayComparatorFunction, NULL); > + -Ken

1 0

Re: [v1 1/2] winejoystick.drv/joystick_osx.c: debugstr_device prints location ID
by Ken Thomases 29 Jun '16

29 Jun '16

On Jun 24, 2016, at 8:33 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > Tested on OS X 10.10.5. > > Signed-off-by: David Lawrie <david.dljunk(a)gmail.com> > --- > dlls/winejoystick.drv/joystick_osx.c | 32 ++++++++++++++++++++++++++++++-- > 1 file changed, 30 insertions(+), 2 deletions(-) Same issues as the corresponding dinput patch. -Ken

1 0

Re: [v1 1/2] dinput/joystick_osx.c: debugstr_device prints location ID
by Ken Thomases 29 Jun '16

29 Jun '16

On Jun 24, 2016, at 8:33 PM, David Lawrie <david.dljunk(a)gmail.com> wrote: > > +static Boolean IOHIDDevice_GetLongProperty(IOHIDDeviceRef inIOHIDDeviceRef, CFStringRef inKey, long * outValue) Don't name your functions as though they were Apple's. Apple "owns" the namespace of identifiers starting with "IOHIDDevice". In general, just use simple lowercase-and-underscores names unless there's a strong reason not to. Something like "get_device_property_long". Same goes for the parameters: "key" and "out_value" or the like. > +{ > + Boolean result = FALSE; > + CFTypeRef tCFTypeRef; Don't use this naming convention either (is that Hungarian notation?). Why is the type repeated in the variable name? What does the "t" prefix signify. Just call this "value" or something. > + > + if (inIOHIDDeviceRef) { > + assert(IOHIDDeviceGetTypeID() == CFGetTypeID(inIOHIDDeviceRef)); > + > + tCFTypeRef = IOHIDDeviceGetProperty(inIOHIDDeviceRef, inKey); > + > + if ( tCFTypeRef ) { > + /* if this is a number */ > + if (CFNumberGetTypeID() == CFGetTypeID(tCFTypeRef)) { > + /* get it's value */ What do these comments add? > + result = CFNumberGetValue((CFNumberRef)tCFTypeRef, kCFNumberSInt32Type, outValue); "long" and "SInt32" don't match reliably. Why not kCFNumberLongType? > +long IOHIDDevice_GetLocationID(IOHIDDeviceRef inIOHIDDeviceRef) Naming conventions here, too. > +{ > + long result = 0; > + (void)IOHIDDevice_GetLongProperty(inIOHIDDeviceRef, CFSTR(kIOHIDLocationIDKey), &result); I don't think we generally use the cast-to-void thing for unused return values in Wine. -Ken

1 0

Re: shell32/tests: Avoid casts from a COM object to an iface.
by Marvin 29 Jun '16

29 Jun '16

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=23879 Your paranoid android. === w1064 (32 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057 === w1064 (64 bit shlfolder) === shlfolder.c:1591: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057

2 1

Re: [PATCH] winex11: fix destroying of top-level windows
by Alexandre Julliard 28 Jun '16

28 Jun '16

Miklós Máté <mtmkls(a)gmail.com> writes: > Fixes https://bugs.winehq.org/show_bug.cgi?id=40767 > > Signed-off-by: Miklós Máté <mtmkls(a)gmail.com> > --- > dlls/winex11.drv/opengl.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c > index d89a193..27ddd79 100644 > --- a/dlls/winex11.drv/opengl.c > +++ b/dlls/winex11.drv/opengl.c > @@ -1314,6 +1314,9 @@ static void free_gl_drawable( struct gl_drawable *gl ) > { > switch (gl->type) > { > + case DC_GL_WINDOW: > + pglXDestroyWindow( gdi_display, gl->drawable ); > + break; Actually this one has some issues too: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so device && touch device.ok device.c:2250: Tests skipped: could not create device, IDirect3D9_CreateDevice returned 0x8876086c device.c:6312: Tests skipped: This GPU supports SM3, skipping unsupported shader test. device.c:6724: Tests skipped: D3DFMT_A32B32G32R32F supports filtering, skipping tests. device.c:7747: Tests skipped: Failed to create cube texture for format R8G8B8 (hr 0x8876086c), skipping tests. device.c:8450: Tests skipped: Dynamic D3DFMT_YUY2 textures not supported, skipping mipmap test. device.c:8450: Tests skipped: Dynamic D3DFMT_UYVY textures not supported, skipping mipmap test. X Error of failed request: GLXBadWindow Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 32 (X_GLXDestroyWindow) Serial number of failed request: 8900 Current serial number in output stream: 8901 Makefile:208: recipe for target 'device.ok' failed -- Alexandre Julliard julliard(a)winehq.org

4 6

Re: d3dx10: Implement D3DX10CompileFromMemory.
by Matteo Bruni 28 Jun '16

28 Jun '16

2016-06-27 21:49 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > + TRACE("data %s, data_size %lu, filename %s, defines %p, include %p, entry_point %s, target %s, " > + "sflags %#x, eflage %#x, pump %p, shader %p, error_messages %p, hresult %p.\n", "eflage" typo. > diff --git a/dlls/d3dx10_43/d3dx10_43_main.c b/dlls/d3dx10_43/d3dx10_43_main.c > index 0c1ff80..fe56ee0 100644 > --- a/dlls/d3dx10_43/d3dx10_43_main.c > +++ b/dlls/d3dx10_43/d3dx10_43_main.c > @@ -37,6 +37,8 @@ > #include "d3dx10core.h" > #include "d3dx10tex.h" > > +#include "wine/debug.h" That is already included a few lines above. Looks good otherwise.

1 0

Re: [d3dcompiler] - add missing fields to d3dcompiler_shader_reflection
by Matteo Bruni 28 Jun '16

28 Jun '16

2016-06-23 1:45 GMT+02:00 Vijay Kiran Kamuju <infyquest(a)gmail.com>: > [d3dcompiler] - add missing fields to d3dcompiler_shader_reflection > > This add missing fields to the d3dcompiler_shader_reflection based on > http://timjones.tw/blog/archive/2015/09/02/parsing-direct3d-shader-bytecode > https://msdn.microsoft.com/en-us/library/windows/desktop/ff476590(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/bb694550(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/bb172432(v=vs.85).… > https://msdn.microsoft.com/en-us/library/windows/desktop/ff476209(v=vs.85).… Thank you for the links, that saved me some time to have to look them up. > + UINT sample_frequency_shader; As far as I understand, that would be better served by a BOOL. > UINT dcl_count; > + UINT def_count; Nitpick but def_count is right before dcl_count in both D3D11_SHADER_DESC and in the shader bytecode, it would be nice to have the same order everywhere. We have tests for this in d3dcompiler_43/tests/reflection.c. Can you please add some tests for those new fields too? Notice that you don't necessarily need n separate new tests for each of the n new features. The patch subject should be something like "d3dcompiler: Add d3d11 fields to struct d3dcompiler_shader_reflection." i.e. no square brackets for the dll prefix and put a colon after it. Also, while not strictly required, it's encouraged to use git send-email, it will inline the patch without wrapping and generally take care of most of the formatting details, assuming git is configured correctly.

1 0

Re: [v2 PATCH] d3dx9_36: Stop crash when displaying effect errors
by Matteo Bruni 28 Jun '16

28 Jun '16

2016-06-22 13:10 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > if (temp_errors) > - TRACE("%s\n", (char *)ID3D10Blob_GetBufferPointer(temp_errors)); > + { > + const char *p = ID3D10Blob_GetBufferPointer(temp_errors); > + SIZE_T size = ID3D10Blob_GetBufferSize(temp_errors); > + const char *end = p + size; > + const char *line = p; > + > + while (p != end) > + { > + if (*p == '\n') > + { > + UINT len = p - line; > + if (len && *(p - 1) == '\r') --len; > + TRACE("%s\n", debugstr_an(line, len)); > + line = ++p; > + } > + else ++p; > + } > + if (line != p) > + TRACE("%s\n", debugstr_an(line, p - line)); > + } This only breaks at '\n', which might still be too much if the lines are particularly long. I also wrote a patch for this a few days ago. I'm going to send it to wine-patches in a bit, I'd appreciate if you can test if it works for you or point out any issue with it.

1 0

Re: include: Add missing interface declaration.
by Nikolay Sivov 28 Jun '16

28 Jun '16

> interface IWbemContext; > interface IWbemServices; > +interface IWbemLocator; > interface IWbemStatusCodeText; > interface IWbemCallResult; > interface IWbemObjectSink; Why do you need this? IWbemLocator is fully defined later in this file.

1 0

Re: [PATCH 6/7] d3drm: Implement IDirect3DRMViewport*::Init.
by Stefan Dösinger 27 Jun '16

27 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-24 um 22:49 schrieb Aaryaman Vasishta: > + if (FAILED(hr = IDirect3DRMDevice_QueryInterface(device, &IID_IDirect3DRMDevice3, (void **)&device3))) > + return hr; > + > + if (FAILED(hr = IDirect3DRMFrame_QueryInterface(camera, &IID_IDirect3DRMFrame3, (void **)&camera3))) > + { > + IDirect3DRMDevice3_Release(device3); > + return hr; > + } > + IDirect3DRMDevice_Release(device); > + IDirect3DRMFrame_Release(camera); > + > + return d3drm_viewport2_Init(&viewport->IDirect3DRMViewport2_iface, device3, camera3, x, y, width, height); This has the same problem as the first version of your frame thunks: You get "device3", but then you release "device", to which you don't hold a reference. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXcFfoAAoJEN0/YqbEcdMweH8P/RBg+lEvXxGES0C1Uo5aN6Ht E0TOftji/AaGrVcaoHLWMsl30/GUpmh+iRdM19ZHwL0vey3yKKdTmFlt4tMrG5aP LLHLlxRqcJt1h+MREvMYb7JJjCAMcR/2Bn63nxWZpZ+PncQo1H90ZsBHCrd4Y707 JukrA3QfPm9cyXiX/ER8cj7QgpnNsk5y8ZXgbdtDDGOzShf2OSoslU5ivQQsmZ4W 2fiJWOeWdpi3P9Fh6EUTDOwUf5Rnj7mBYb3KFASc9o0VZXHuI/f35LGG9AdNkSxs lf6RbPDcXxPQqUxlz0VnmS/31/oGb0pDczESx+alDU9n29tWPANY+yBGUmDStyJ0 /RHl2qpZJMs/lQpk9UQ/RpvuVdZfLVxgftqyZuoWT4EfW5iseOlCytmsJEG1AVpd BKAMFRbueGhPYfUcuLAH1GL4keRg7P3QUd36MlR0wWVdYGtMWrbQL+6SrHT6r75C QmXU9mTJMTleA/Yzskenm71Tz9/wbwavYjUMaEQp3+7OKrG0Zqnt4foh2GpNUT+6 M7jxfSSng4+irWvxf3ZKdpjfGNHRn1ZhRKrEpxKQptiGlFvYSMDy7tHtyybK2MbB h8CO19YAzcVjfFHj5sRSYtZIHdVm5aG5FJLfVm9UPBA7xT2l9b6EgqXEhLTVLYC6 /TSyEFgT5j+DkKf6DCm+ =0tcs -----END PGP SIGNATURE-----

2 3

OSSCOM 2016 Conference - Dec, 2016 (Call for Papers)
by 2nd International Conference on Open Source Software Computing (OSSCOM 2016) 27 Jun '16

27 Jun '16

OSSCOM 2016 Call for Proposals/ Papers OSSCOM 2016 The 2nd International Conference on Open Source Software Computing 1st - 3rd December 2016 Lebanese University, Beirut - Lebanon http://mailer.tagorg.com/lists/lt.php?id=bB0DBlQZUAJSTlQNAFIEAA Partially funded by EC - Tempus and technically sponsored by IEEE Objectives To promote opportunities for cooperation towards enabling OSS key technologies, building cross-cutting sciences, and driving disruptive innovations; to disseminate research on technology and applications of open source software computing; and to expand the framework of effective participation of universities in developing OSS industry through incubators and business accelerators. Structure - Keynotes - Panel and roundtable discussions - Presentation sessions - Industry and technology discussions - Consultation meetings, focus groups, and roundtables - Best practice showcases and practical demonstration - Workshops Submission Deadline 1st September, 2016 (Manuscripts) 1st October, 2016 (Proposals) Topics of Interest Track 1: Systems Software - Operating systems: Linux Kernel, Server and Desktop Linux: RedHat, Debian, Slackware, Caldera, SuSe, Fedora - Distributed Operating systems: Open source platforms and software for the cloud platform as a service (PaaS), software as a service (SaaS), and infrastructure as a service (IaaS). Open stack, Open-source software in scientific computing including clouds, grids and HPCs - Embedded and Realtime Operating systems - Ubiquitous mobile computing and technologies: middleware, operating system (e.g. Android), new I/O and user interfaces, mobile protocols Track 2: Applications and Services - Open-source software services and applications in energy, environment, education, health, climate, water, agriculture, biology, economy, medicine and other pressing global issues and problems - Open-source software for e-Services, including e-Government, e-Libraries, e-Learning and any e-* - Open-source software for Smart Education, Smart Cities, Smart Power Grids, Smart Transportation - Open Source applications for mobile and tablets Track 3: Networking and Security - Open source network simulation/emulations tools - Open source platforms for network security deployment, testing and verification - Network and security open source management software Track 4: Open Source Development and Support - Perspectives on open-source software development and services, including challenges, operation, sustainability, funding, governance, business models, and security - National, regional and international organizations and their role in funding and supporting open-source software applications in research and education - Collaborative projects and initiatives in research and education at national, regional and global levels - Research and education challenges and open access paradigm - Business models for open-source software development and services Track 5: Software Engineering This track will bring together researchers, students and industry experts from diverse areas associated with software engineering who are utilizing, developing or even improving open source software systems during their research and experiments. Software Engineering influences all aspects of computer science research and touches every software researchers and practitioners. There are diverse Free and open-source software that could be utilized in many fields under the umbrella of Software Engineering such as but not limited to: - Software Process Models - Software Process Improvement - Software Architecture - Component-Based Software Engineering - Software Verification and Validation - Model Checking - Software Impact Analysis - Design Patterns and Frameworks - Model Driven Architecture - Modeling with UML - Reusable Software and Metrics - Reverse Engineering, Re-engineering - Adaptive Software - Software Define Network - Data Mining and Machine Learning - Safety and Security in Critical Software Conference Venue Lebanese University, Beirut - Lebanon Submit a Participation <http://mailer.tagorg.com/lists/lt.php?id=bB0DB1EZUAJSTlQNAFIEAA> Language English Registration Fees OSSCOM members 50 Euro OSSCOM non-members 100 Euro Authors and Speakers 50 Euro Students Free All papers will be peer-reviewed and selected papers will be published in the conference proceedings and submitted to IEEE Explore. Partners and Organisers - Hochschule Bonn-Rhein-Sieg University of Applied Sciences, Germany - German Jordanian University, Jordan - Lebanese University, Lebanon - Brunel University, United Kingdom - Yarmouk University, Jordan - Notre Dame University, Lebanon - University of Castilla-La Mancha, Spain - Tarent AG, Germany - Talal Abu-Ghazaleh Information Technology International, Jordan - Information Management Ltd, Lebanon - Le Cnam Liban Important Dates 1st Sept, 2016 Manuscript Submission Deadline 1st Oct, 2016 Acceptance Notification 15th Nov 2016 Registration Deadline 1st – 3rd Dec 2016 OSSCOM 2016 Conference For more information and paper submission, please contact Paper Submission: - Please submit your manuscript or proposal at: http://mailer.tagorg.com/lists/lt.php?id=bB0DBVQZUAJSTlQNAFIEAA Registration: - Please register for OSSCOM 2016 conference at: http://mailer.tagorg.com/lists/lt.php?id=bB0DBlYZUAJSTlQNAFIEAA Publicity: - Dr. Yaser Jararweh, yijararweh(a)just.edu.jo <mailto:yijararweh@just.edu.jo> - Dr. Muhannad Quwaider, mqquwaider(a)just.edu.jo <mailto:mqquwaider@just.edu.jo> More Information: - Please contact us through our email: office(a)osscom.org <mailto:office@osscom.org> All information is available at: http://mailer.tagorg.com/lists/lt.php?id=bB0DBlcZUAJSTlQNAFIEAA -- This message was sent to wine-devel(a)winehq.org by Office(a)osscom.org To forward this message, please do not use the forward button of your email application, because this message was made specifically for you only. Instead use the forward page <http://mailer.tagorg.com/lists/lt.php?id=bB0DBVcZUAJSTlQNAFIEAA> in our newsletter system. To change your details and to choose which lists to be subscribed to, visit your personal preferences page <http://mailer.tagorg.com/lists/lt.php?id=bB0DS1dUUE9WClYGBlc> Or you can opt-out completely <http://mailer.tagorg.com/lists/lt.php?id=bB0CS1dUUE9WClYGBlc> from all future mailings. -- powered by phpList, www.phplist.com --

1 0

Host_Quit implementation in wscript
by Thiago Barbato 27 Jun '16

27 Jun '16

I tried running a .js with a WScript.Quit() call and noticed it isn't implemented yet in programs/wscript/host.c. Would a simple ExitProcess( ExitCode ) do the job or are there cases where this would be the wrong thing to do?

2 1

Re: [PATCH 4/4] rpcrt4: Added RpcServerRegisterAuthInfoW failure test.
by Marvin 27 Jun '16

27 Jun '16

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=23875 Your paranoid android. === w864 (32 bit rpc) === rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {6eb1cf99-3c79-11e6-be78-e71666c2e04a} === w864 (64 bit rpc) === rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {f4f8b15d-3c7a-11e6-be78-e71666c2e04a}

1 0

Re: wordpad: Avoid buffer overrun in registry_set_filelist.
by Huw Davies 27 Jun '16

27 Jun '16

On Sun, Jun 26, 2016 at 11:42:31AM +0200, Thomas Faber wrote: > From e80a75cfe223a82eea4c55874975e54de4981282 Mon Sep 17 00:00:00 2001 > From: Thomas Faber <thomas.faber(a)reactos.org> > Date: Sun, 26 Jun 2016 10:59:08 +0200 > Subject: wordpad: Avoid buffer overrun in registry_set_filelist. > > Signed-off-by: Thomas Faber <thomas.faber(a)reactos.org> > --- > programs/wordpad/registry.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/programs/wordpad/registry.c b/programs/wordpad/registry.c > index bf2af5b..e047f37 100644 > --- a/programs/wordpad/registry.c > +++ b/programs/wordpad/registry.c > @@ -298,7 +298,7 @@ void registry_set_filelist(LPCWSTR newFile, HWND hMainWnd) > if(!lstrcmpiW(pFiles[i], newFile)) > { > int j; > - for(j = 0; pFiles[j] && j < i; j++) > + for(j = 0; j < i && pFiles[j]; j++) > { > pFiles[i-j] = pFiles[i-j-1]; > } This looks odd to me. I don't see how this could avoid an overflow; pFiles[i] is valid at this point and so pFiles[j] will be ok if j == i. More confusingly though, is why pFiles[j] is in the test at all. Huw.

2 1

Re: d3d9/tests: Use SetRect() instead of open coding it.
by Marvin 27 Jun '16

27 Jun '16

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=23872 Your paranoid android. === w1064 (64 bit device) === device.c:4348: Test failed: cw is 0xf60, expected 0x7f. device.c:4357: Test failed: Callback cw is 0xf60, expected 0x7f.

2 1

Re: [PATCH 7/7] d3drm: Implement IDirect3DRM*::CreateViewport.
by Stefan Dösinger 27 Jun '16

27 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-06-24 um 22:49 schrieb Aaryaman Vasishta: > + hr = IDirect3DRM3_CreateViewport(d3drm3, device3, frame3, rc.left, rc.top, rc.right, rc.bottom + 1, &viewport2); > + ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %#x.\n", hr); > + if (FAILED(hr)) > + { > + hr = IDirect3DRM3_CreateViewport(d3drm3, device3, frame3, rc.left, rc.top, rc.right, rc.bottom, NULL); > + ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %#x.\n", hr); > + } Afaics the if (FAILED(hr)) isn't necessary here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXcFm2AAoJEN0/YqbEcdMwbewP/11c9oFcbQjek33cW30miUka fO/BIk3qk6xpsz/CMF/DRmwQvqPObSnG5zsAXn4j1hsJM2y3EBRjLeZx1/CqyR9s uQ9JyN85zB2rEDkSpLFNaOIW0hnX7bFFnOmZlIlZPYRH1cqQSJcg5gcAq8EnLeIl ioWW0qK3ZREeRDZXEe0YxuwGqWE+HouUNzS/En9OrlZ9b76zfuRcH2rrGSw+2BPo Az8PzllV8v3Df/HxqYyeG9JxgjWElk2aQGfHP5BPUE/JF5+Ky2xEb6RvHVGJQ64P G/HKJGlKZT/VgQGCbJx6s5bNazBiJSyD4a6dj5IbEbWmnySJIbwW2DNXrcxKT9MO oz0NNyjMQAVkJx45QVvtxm+5QsJIbO6V/38h+zsPW0F6dGrYoqBXXSFbsbp4ge2G S2EC+bJVHsUwc2en52BaqJCRDYLSgxNaD2kL8ovZjLYBVi3jlfTP/OcIXYjam2I7 67b8VEeV7xBILU2uvhFxwpwLIgtVJ1b2QUyH3TjrKfClGu5lbe/VbASsrDjBaJV1 ZZMqcmn1JU/P24wQVWb2gfqN12ktvhEnnYznwz8zw7OKdpOUoKlOXr/06tlrMmei YfuGMZmJyxMJQSsfIVtoFH1HmqlZuk5QUjnjyShYDDf4TlKWZAtn4o4JJbt4n1J0 bOobnKLPsEGKSNhoZbnm =xbZw -----END PGP SIGNATURE-----

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel