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

Re: [2/3] wsdapi/tests: Add tests for Register/UnRegisterNotificationSink
by Nikolay Sivov April 19, 2017

April 19, 2017

Don't know if that's important, but this does not test a case when RegisterNotificationSink is called on already registered sink.

3 3

Re: [PATCH] mfplat: Add MFCreateAttributes stub
by Nikolay Sivov April 19, 2017

April 19, 2017

Does this make some application work, without providing actual interface implementation?

3 2

Re: [v2 PATCH 2/2] wined3d: Update only dirty regions in wined3d_device_update_texture().
by Marvin April 19, 2017

April 19, 2017

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=30251 Your paranoid android. === w1064 (32 bit visual) === visual.c:7992: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors).

1 0

Re: [PATCH 2/3] user32: Switch to normal window drawing on SetLayeredWindowAttributes call
by Ken Thomases April 19, 2017

April 19, 2017

On Apr 18, 2017, at 11:43 AM, Piotr Caban <piotr(a)codeweavers.com> wrote: > > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/user32/win.c | 6 +++++- > dlls/winemac.drv/window.c | 2 ++ > dlls/winex11.drv/window.c | 2 ++ > 3 files changed, 9 insertions(+), 1 deletion(-) The Mac driver part of this looks OK to me. -Ken

1 0

Re: [PATCH 1/3] shell32: Avoid leaking icon handles.
by Andrew Eikum April 19, 2017

April 19, 2017

FWIW you're mixing up indent style in a function that is mostly consistently (if bizarrely) indented. Andrew On Wed, Apr 19, 2017 at 01:13:39PM +0100, Huw Davies wrote: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/shell32/iconcache.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/dlls/shell32/iconcache.c b/dlls/shell32/iconcache.c > index c3284a27d6..7beb47967d 100644 > --- a/dlls/shell32/iconcache.c > +++ b/dlls/shell32/iconcache.c > @@ -305,10 +305,12 @@ static INT SIC_IconAppend (LPCWSTR sSourceFile, INT dwSourceIndex, HICON hSmallI > * gets small/big icon by number from a file > */ > static INT SIC_LoadIcon (LPCWSTR sSourceFile, INT dwSourceIndex, DWORD dwFlags) > -{ HICON hiconLarge=0; > +{ > + HICON hiconLarge=0; > HICON hiconSmall=0; > HICON hiconLargeShortcut; > HICON hiconSmallShortcut; > + int ret; > > PrivateExtractIconsW( sSourceFile, dwSourceIndex, GetSystemMetrics(SM_CXICON), > GetSystemMetrics(SM_CYICON), &hiconLarge, 0, 1, 0 ); > @@ -327,6 +329,8 @@ static INT SIC_LoadIcon (LPCWSTR sSourceFile, INT dwSourceIndex, DWORD dwFlags) > hiconSmallShortcut = SIC_OverlayShortcutImage(hiconSmall, FALSE); > if (NULL != hiconLargeShortcut && NULL != hiconSmallShortcut) > { > + DestroyIcon( hiconLarge ); > + DestroyIcon( hiconSmall ); > hiconLarge = hiconLargeShortcut; > hiconSmall = hiconSmallShortcut; > } > @@ -339,8 +343,12 @@ static INT SIC_LoadIcon (LPCWSTR sSourceFile, INT dwSourceIndex, DWORD dwFlags) > } > } > > - return SIC_IconAppend (sSourceFile, dwSourceIndex, hiconSmall, hiconLarge, dwFlags); > + ret = SIC_IconAppend( sSourceFile, dwSourceIndex, hiconSmall, hiconLarge, dwFlags ); > + DestroyIcon( hiconLarge ); > + DestroyIcon( hiconSmall ); > + return ret; > } > + > /***************************************************************************** > * SIC_Initialize [internal] > */ > -- > 2.12.0 > > >

2 1

Re: [6/6] secur32: Add support for SECPKG_ATTR_KEY_INFO (GnuTLS only).
by Jacek Caban April 19, 2017

April 19, 2017

Hi Akihiro, Thanks for working on that. I have a few comments to the patch. On 17.04.2017 16:26, Akihiro Sagawa wrote: > diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c > index 6914837..317686f 100644 > --- a/dlls/secur32/schannel.c > +++ b/dlls/secur32/schannel.c > @@ -54,11 +54,14 @@ struct schan_handle > enum schan_handle_type type; > }; > > +#define SCHAN_KEY_NAME_MAX 8 > struct schan_context > { > schan_imp_session session; > ULONG req_ctx_attr; > const CERT_CONTEXT *cert; > + SEC_WCHAR key_signature_name[SCHAN_KEY_NAME_MAX]; > + SEC_WCHAR key_encrypt_name[SCHAN_KEY_NAME_MAX]; Those should not be needed. You could for example store both WCHAR and char strings inside alg_name_map. > }; > > static struct schan_handle *schan_handle_table; > @@ -962,6 +965,53 @@ static SECURITY_STATUS SEC_ENTRY schan_InitializeSecurityContextA( > return ret; > } > > +struct schan_alg_id_name { > + ALG_ID alg_id; > + const char* name; > +}; > + > +static int comp_alg_id(const void *a, const void *b) > +{ > + const struct schan_alg_id_name *lhs = a; > + const struct schan_alg_id_name *rhs = b; > + return (int)lhs->alg_id - (int)rhs->alg_id; > +} > + > +static void fill_alg_name(ALG_ID id, void *buffer, BOOL wide) If you change the patch as I suggested above, this could be something like: static void *get_alg_name(ALF_ID id, BOOL wide) > +{ > + static const struct schan_alg_id_name alg_name_map[] = { > + { CALG_ECDSA, "ECDSA" }, > + { CALG_RSA_SIGN, "RSA" }, > + { CALG_DES, "DES" }, > + { CALG_RC2, "RC2" }, > + { CALG_3DES, "3DES" }, > + { CALG_AES_128, "AES" }, > + { CALG_AES_192, "AES" }, > + { CALG_AES_256, "AES" }, > + { CALG_RC4, "RC4" }, > + }; > + const struct schan_alg_id_name *res; > + struct schan_alg_id_name key; > + const char *name; > + > + key.alg_id = id; > + res = bsearch(&key, alg_name_map, > + sizeof(alg_name_map)/sizeof(alg_name_map[0]), sizeof(alg_name_map[0]), > + comp_alg_id); > + if (res) > + name = res->name; > + else > + { > + TRACE("Unknown ALG_ID %04x\n", id); > + name = "???"; > + } A FIXME would would be nice here. Also, I think you could just return NULL in this case. > + > + if (wide) > + MultiByteToWideChar(CP_ACP, 0, name, -1, (SEC_WCHAR*)buffer, SCHAN_KEY_NAME_MAX); > + else > + strcpy((SEC_CHAR*)buffer, name); > +} > + > static SECURITY_STATUS ensure_remote_cert(struct schan_context *ctx) > { > HCERTSTORE cert_store; > @@ -989,6 +1039,7 @@ static SECURITY_STATUS SEC_ENTRY schan_QueryContextAttributesW( > > if (!context_handle) return SEC_E_INVALID_HANDLE; > ctx = schan_get_object(context_handle->dwLower, SCHAN_HANDLE_CTX); > + if (!ctx) return SEC_E_INVALID_HANDLE; This has an effect outside of scope of this patch. This should be be a separated patch, with a test case. > switch(attribute) > { > @@ -1016,6 +1067,19 @@ static SECURITY_STATUS SEC_ENTRY schan_QueryContextAttributesW( > > return status; > } > + case SECPKG_ATTR_KEY_INFO: > + { > + SecPkgContext_KeyInfoW *info = buffer; > + SECURITY_STATUS status = schan_imp_get_key_info(ctx->session, info); > + if (status == SEC_E_OK) > + { > + info->sSignatureAlgorithmName = ctx->key_signature_name; > + info->sEncryptAlgorithmName = ctx->key_encrypt_name; > + fill_alg_name(info->SignatureAlgorithm, info->sSignatureAlgorithmName, TRUE); > + fill_alg_name(info->EncryptAlgorithm, info->sEncryptAlgorithmName, TRUE); > + } > + return status; > + } > case SECPKG_ATTR_REMOTE_CERT_CONTEXT: > { > PCCERT_CONTEXT *cert = buffer; > @@ -1091,6 +1155,24 @@ static SECURITY_STATUS SEC_ENTRY schan_QueryContextAttributesA( > { > case SECPKG_ATTR_STREAM_SIZES: > return schan_QueryContextAttributesW(context_handle, attribute, buffer); > + case SECPKG_ATTR_KEY_INFO: > + { > + SecPkgContext_KeyInfoA *info = buffer; > + struct schan_context *ctx; > + SECURITY_STATUS status; > + if (!context_handle) return SEC_E_INVALID_HANDLE; > + ctx = schan_get_object(context_handle->dwLower, SCHAN_HANDLE_CTX); > + if (!ctx) return SEC_E_INVALID_HANDLE; > + status = schan_imp_get_key_info(ctx->session, (SecPkgContext_KeyInfoW*)info); > + if (status == SEC_E_OK) > + { > + info->sSignatureAlgorithmName = (SEC_CHAR *)ctx->key_signature_name; > + info->sEncryptAlgorithmName = (SEC_CHAR *)ctx->key_encrypt_name; > + fill_alg_name(info->SignatureAlgorithm, info->sSignatureAlgorithmName, FALSE); > + fill_alg_name(info->EncryptAlgorithm, info->sEncryptAlgorithmName, FALSE); > + } > + return status; > + } > case SECPKG_ATTR_REMOTE_CERT_CONTEXT: > return schan_QueryContextAttributesW(context_handle, attribute, buffer); > case SECPKG_ATTR_CONNECTION_INFO: > diff --git a/dlls/secur32/schannel_gnutls.c b/dlls/secur32/schannel_gnutls.c > index 30640d3..ddf33a8 100644 > --- a/dlls/secur32/schannel_gnutls.c > +++ b/dlls/secur32/schannel_gnutls.c > @@ -363,6 +363,22 @@ static ALG_ID schannel_get_kx_algid(int kx) > } > } > > +static ALG_ID schannel_get_kx_signature_algid(gnutls_kx_algorithm_t kx) > +{ > + switch (kx) > + { > + case GNUTLS_KX_UNKNOWN: return 0; > + case GNUTLS_KX_RSA: > + case GNUTLS_KX_RSA_EXPORT: > + case GNUTLS_KX_DHE_RSA: > + case GNUTLS_KX_ECDHE_RSA: return CALG_RSA_SIGN; > + case GNUTLS_KX_ECDHE_ECDSA: return CALG_ECDSA; > + default: > + FIXME("unknown algorithm %d\n", kx); > + return 0; > + } > +} > + > unsigned int schan_imp_get_session_cipher_block_size(schan_imp_session session) > { > gnutls_session_t s = (gnutls_session_t)session; > @@ -394,6 +410,23 @@ SECURITY_STATUS schan_imp_get_connection_info(schan_imp_session session, > return SEC_E_OK; > } > > +SECURITY_STATUS schan_imp_get_key_info(schan_imp_session session, SecPkgContext_KeyInfoW *info) > +{ > + gnutls_session_t s = (gnutls_session_t)session; > + gnutls_cipher_algorithm_t alg = pgnutls_cipher_get(s); > + gnutls_kx_algorithm_t kx = pgnutls_kx_get(s); > + > + TRACE("(%p,%p)\n", session, info); > + > + info->sSignatureAlgorithmName = NULL; /* filled later */ > + info->sEncryptAlgorithmName = NULL; /* filled later */ > + info->KeySize = pgnutls_cipher_get_key_size(alg) * 8; > + info->SignatureAlgorithm = schannel_get_kx_signature_algid(kx); > + info->EncryptAlgorithm = schannel_get_cipher_algid(alg); > + > + return SEC_E_OK; > +} I don't think such helper that fills output partially is the right solution here. You could use schan_imp_get_connection_info to get all info you need except signature algorithm. For signature algorithm, you may introduce a new, simpler, function. Thanks, Jacek

1 0

Re: [5/6] secur32/tests: Add tests with SECPKG_ATTR_KEY_INFO.
by Jacek Caban April 19, 2017

April 19, 2017

Hi Akihiro, On 17.04.2017 16:26, Akihiro Sagawa wrote: > @@ -923,6 +924,15 @@ todo_wine > ok(conn_info.dwHashStrength >= 128, "conn_info.dwHashStrength = %d\n", conn_info.dwHashStrength); > } > > + status = pQueryContextAttributesA(&context, SECPKG_ATTR_KEY_INFO, &key_info); > + todo_wine_if(status == SEC_E_UNSUPPORTED_FUNCTION) > + ok(status == SEC_E_OK, "QueryContextAttributesW(SECPKG_ATTR_KEY_INFO) failed: %08x\n", status); I think this should use todo_wine, not todo_wine_if(). Thanks, Jacek

1 0

Re: [PATCH 01/10] wined3d: Introduce struct wined3d_dirty_regions.
by Stefan Dösinger April 19, 2017

April 19, 2017

Hi Masanori, Thank you for your patches! I have a few comments: Regarding the big picture I think it would be great if we had a scheme that also worked for partially mapping resources. It's also necessary to make the D3DLOCK_NO_DIRTY_UPDATE test on managed textures work. However, doing this is a lot more work than your patchset and complicates location management a lot. If Henri tells you something different follow his advice. He is the authority for decisions in d3d :-) . Patch 1: Am 2017-04-17 um 15:47 schrieb Masanori Kakura: > +struct wined3d_dirty_regions > +{ > + UINT left; > + UINT top; > + UINT right; > + UINT bottom; > + UINT front; > + UINT back; > + struct wined3d_dirty_regions *next; > +}; A standard wine list would be better IMHO. Patch 2: > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 785105d7b9..711f98a0a6 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -2765,6 +2765,27 @@ struct wined3d_dirty_regions > struct wined3d_dirty_regions *next; > }; > > +static inline BOOL wined3d_dirty_regions_add(struct wined3d_dirty_regions **regions, > + UINT left, UINT top, UINT right, UINT bottom, UINT front, UINT back) I don't think we want this in the header file, I think it'd be better placed in resource.c. Also note that buffers already have a related mechanism (buffer->modified_areas). You can predeclare the functions in the header if you need to call them from multiple files. > +{ > + struct wined3d_dirty_regions *new_region; > + > + if (!(new_region = HeapAlloc(GetProcessHeap(), 0, sizeof(struct wined3d_dirty_regions)))) > + return FALSE; HeapAlloc is expensive. I think it is OK for the start, but in the long run a way to keep some old dirty region elements around and reuse them instead of always calling Alloc / Free. Patch 5: > + if (!wined3d_dirty_regions_add(&resource->dirty_regions, 0, 0, width, height, 0, depth)) Why not use wined3d_resource_maximize_dirty_region here? > wined3d_resource_acquire(resource); > + wined3d_dirty_regions_clear(&resource->dirty_regions); > wined3d_cs_destroy_object(resource->device->cs, wined3d_resource_destroy_object, resource); Regions need to be cleared from inside the cs thread in case there are pending update_texture commands. Similarly patch 6 needs to put the region modifying into wined3d_cs_exec_add_dirty_texture_region. Patch 7: > + if (box->left < box->right && box->top < box->bottom && box->front < box->back) > + { You don't need to check the box, texture_resource_sub_resource_map already does it before it reaches this place of the code. See wined3d_texture_check_box_dimensions. Patch 8: I am not sure if this is necessary at all. In d3d9 it doesn't matter because a UpdateSurface destination can never be an UpdateTexture source. Patch 9/10: These should be merged, and I don't think patch 10 looks right. I think dirty regions should be honored on sublevels as well, just adjusted (i.e., divide by 2 for every level). > + if (src_texture->resource.width <= dst_texture->resource.width > + && src_texture->resource.height <= dst_texture->resource.height > + && src_texture->resource.depth <= dst_texture->resource.depth) Why are you adding this check? Is it because the src_skip_levels broke the if (i == 0) root level detection? If you apply the dirty region to all levels this problem should go away.

3 8

Re: [PATCH 6/6] dwrite: Make CreateFontFaceFromHdc() properly fail on unsupported font format
by Marvin April 19, 2017

April 19, 2017

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=30243 Your paranoid android. === wvistau64 (32 bit font) === font.c:3510: Test failed: got 0x80004005 === w2008s64 (32 bit font) === font.c:3510: Test failed: got 0x80004005 === wvistau64 (64 bit font) === font.c:3510: Test failed: got 0x80004005 === w2008s64 (64 bit font) === font.c:3510: Test failed: got 0x80004005

1 0

Re: [2/3] msi: Properly handle DWORD registry values in MsiGetPatchInfoEx.
by Marvin April 19, 2017

April 19, 2017

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=30239 Your paranoid android. === w7u (32 bit msi) === The task timed out

1 0

Re: 0001-Fix-some-bugs-about-some-special-Chinese-tests-in-lo
by Jactry Zeng April 19, 2017

April 19, 2017

Hi, Please have a look at this wiki page before you submitting a patch: https://wiki.winehq.org/Submitting_Patches Thanks for your work! 2017-04-18 16:00 GMT+08:00 Matrix95 <matrix95(a)foxmail.com>: > > > > > > -- Regards, Jactry Zeng

1 0

Re: [PATCH 3/3] user32: Add layered window child painting test when WS_CLIPCHILDREN flag is specified
by Marvin April 18, 2017

April 18, 2017

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=30230 Your paranoid android. === w864 (32 bit win) === win.c:2323: Test failed: expected !100 win.c:2323: Test failed: expected !100

2 1

Re: [PATCH 1/2] mountmgr: Create devices and registry entries for serial ports.
by Hugh McMaster April 18, 2017

April 18, 2017

Hi Alex, Just a few things I noticed. On Monday, 17 April 2017 2:23 PM, Alex Henrie wrote: >+ /* create registry entry */ >+ sprintfW( reg_value, reg_value_format, n ); >+ RegSetValueExW( windows_ports_key, nt_name.Buffer, 0, REG_SZ, >+ (BYTE *)reg_value, strlenW( reg_value ) * sizeof(WCHAR) ); >+ >+ return TRUE; >+} You need to pass RegSetValueExW() the string length plus the null-terminating character. >+/* find and create serial or parallel ports */ >+static void create_port_devices( DRIVER_OBJECT *driver ) >+{ >+ static const char *serial_search_paths[] = { >+#ifdef linux >+ "/dev/ttyS%u", >+ "/dev/ttyUSB%u", >+#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) >+ "/dev/cuau%u", >+#elif defined(__DragonFly__) >+ "/dev/cuaa%u", >+#else >+ "", >+#endif >+ }; >+ static const WCHAR serialcomm_keyW[] = {'H','A','R','D','W','A','R','E','\\', >+ 'D','E','V','I','C','E','M','A','P','\\', >+ 'S','E','R','I','A','L','C','O','M','M',0}; >+ const char **search_paths; >+ const WCHAR *windows_ports_key_name; >+ char *dosdevices_path, *p; >+ HKEY wine_ports_key = NULL, windows_ports_key = NULL; >+ char unix_path[256]; >+ int i, j, n = 1; >+ >+ if (!(dosdevices_path = get_dosdevices_path( &p ))) >+ return; >+ >+ if (driver == serial_driver) >+ { >+ p[0] = 'c'; >+ p[1] = 'o'; >+ p[2] = 'm'; >+ search_paths = serial_search_paths; >+ windows_ports_key_name = serialcomm_keyW; >+ } >+ else >+ { >+ /* TODO: support parallel ports */ >+ } >+ p += 3; >+ >+ RegOpenKeyW( HKEY_LOCAL_MACHINE, ports_keyW, &wine_ports_key ); >+ RegOpenKeyW( HKEY_LOCAL_MACHINE, windows_ports_key_name, &windows_ports_key ); Please use RegOpenKeyExW() and check for any failures from these functions. >+ /* remove old symlinks */ >+ for (n = 1; n <= MAX_PORTS; n++) >+ { >+ sprintf( p, "%u", n ); >+ if (unlink( dosdevices_path ) != 0 && !errno) >+ break; >+ } >+ >+ /* look for ports in the usual places */ >+ n = 1; >+ for (i = 0; i < sizeof(search_paths)/sizeof(search_paths[0]); i++) This won't do what you expect. sizeof(search_paths)/sizeof(search_paths[0]) is 1. You need to pass in the number of elements in the array. Also, it's better to avoid making this calculation during each loop. Hugh

2 1

Re: [v2 PATCH] oleaut32: Remove redentant VariantClear call
by Huw Davies April 18, 2017

April 18, 2017

I've sent another version with the typo in the subject fixed. Huw.

1 0

Re: [PATCH 4/4] ddraw/tests: Work around an Nvidia DEPTHFILL bug in ddraw2.
by Henri Verbeet April 18, 2017

April 18, 2017

On 17 April 2017 at 22:14, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + /* Nvidia drivers (Tested on Geforce 7 to Geforce 650) on Windows incorrectly handle > + * depth fills in ddraw2. X axis coordinates are scaled by 3/4, so we end up clearing What is the depth format it ends up with? D24X8 by any chance?

1 0

Re: [PATCH 3/4] ddraw/tests: Don'T use DDBLT_COLORFILL in test_flip.
by Henri Verbeet April 18, 2017

April 18, 2017

On 17 April 2017 at 22:14, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +/* The Nvidia Geforce 7 driver cannot do a color fill on a texture backbuffer after > + * the backbuffer has been locked. Do it ourselves as a workaround. Unlike ddraw1 > + * and 2 GetSurfaceDesc does not cause issues in ddraw4 and ddraw7. */ > +static void fill_surface(IDirectDrawSurface7 *surface, D3DCOLOR color) I think this kind of helper is fine, but the comment seems more appropriate for the place using it than the helper itself. > + color = get_surface_color(backbuffer1, 320, 240); > + color = get_surface_color(backbuffer2, 320, 240); > + color = get_surface_color(backbuffer3, 320, 240); Is this debug code?

1 0

Re: [PATCH] oleaut32: Improve support for IDispatch in VarCat
by Nikolay Sivov April 18, 2017

April 18, 2017

On 17.04.2017 6:43, Alistair Leslie-Hughes wrote: > + else if (rightvt == VT_DISPATCH) > + { > + /* The returned Dispatch Value, may not be able to be coerced, ie. VT_NULL */ > + hres = VariantChangeTypeEx(&bstrvar_left,left,0,0,VT_BSTR); > + if (hres != S_OK && hres != DISP_E_TYPEMISMATCH) > + return hres; > + } > else > { > hres = VariantChangeTypeEx(&bstrvar_left,left,0,0,VT_BSTR); This is suspiciously similar to default case, in last else block. Could it mean VariantChangeTypeEx() should be fixed instead? > + if (This->bFailInvoke) > + return E_OUTOFMEMORY; I think it's better to use some non-specific error code that triggers FAILED() but is not generic as E_OUTOFMEMORY, anything above 0x8000000 I suppose. Also maybe it's better to use exact code instead of bFailInvoke, and return if (FAILED(This->hr))? > +static inline DummyDispatch *impl_from_IDispatch(IDispatch *iface) > +{ > + return CONTAINING_RECORD(iface, DummyDispatch, IDispatch_iface); > +} > + > +static ULONG WINAPI DummyDispatch_AddRef(IDispatch *iface) > +{ > + DummyDispatch *This = impl_from_IDispatch(iface); > + return InterlockedIncrement(&This->ref); > +} If static object is enough, you can remove reference counter. > + if (pVarCmp) > + ok(pVarCmp(&result,&expected,lcid,0) == VARCMP_EQ, > + "VarCat: EMPTY concat with EMPTY did not return empty VT_BSTR\n"); This is not a problem this patch introduces, but there's no reason to continue to use pVarCmp, as it's always available on platforms we're testing on.

2 1

Re: [v3 PATCH] odbccp32: Handle ODBC_CONFIG_DRIVER request in SQLConfigDriver/W
by Huw Davies April 18, 2017

April 18, 2017

On Thu, Apr 13, 2017 at 01:06:50AM +0000, Alistair Leslie-Hughes wrote: > +static BOOL write_config_value(const WCHAR *driver, const WCHAR *args) > +{ > + long ret; > + HKEY hkey; > + > + if (!args) > + return FALSE; > + > + if ((ret = RegOpenKeyW(HKEY_LOCAL_MACHINE, odbcini, &hkey)) == ERROR_SUCCESS) > + { > + HKEY hkeydriver; > + > + if ((ret = RegOpenKeyW(hkey, driver, &hkeydriver)) == ERROR_SUCCESS) > + { > + WCHAR *divider, *value; > + > + WCHAR *name = heap_alloc( (strlenW(args) + 1) * sizeof(WCHAR)); > + if(!name) > + { > + push_error(ODBC_ERROR_OUT_OF_MEM, odbc_error_out_of_mem); > + return FALSE; You're returning without closing the registry keys. You may want to change the error handling to a 'goto fail;' type behaviour. > diff --git a/dlls/odbccp32/tests/misc.c b/dlls/odbccp32/tests/misc.c > index ed8e6f1..e5a8896 100644 > --- a/dlls/odbccp32/tests/misc.c > +++ b/dlls/odbccp32/tests/misc.c ... > + > ret = SQLInstallDriverEx("WINE ODBC Driver Path\0Driver=sample.dll\0Setup=sample.dll\0\0", "c:\\temp", path, MAX_PATH, &size, ODBC_INSTALL_COMPLETE, NULL); > + ok(ret, "SQLInstallDriverEx failed\n"); > sql_ret = SQLInstallerErrorW(1, &error_code, NULL, 0, NULL); > - ok(sql_ret && error_code == SQL_SUCCESS, "SQLInstallDriverEx failed %d, %u\n", sql_ret, error_code); > + ok(sql_ret == SQL_NO_DATA || (sql_ret && error_code == SQL_SUCCESS), "SQLInstallDriverEx failed %d, %u\n", sql_ret, error_code); > ok(!strcmp(path, "c:\\temp"), "invalid path %s\n", path); > > + ret = SQLConfigDriver(NULL, ODBC_CONFIG_DRIVER, "WINE ODBC Driver Path", "NoWrite=60;xxxx=555", error, sizeof(error), NULL); > + ok(ret, "SQLConfigDriver failed\n"); > + sql_ret = SQLInstallerErrorW(1, &error_code, NULL, 0, NULL); > + ok(sql_ret == SQL_NO_DATA || (sql_ret && error_code == SQL_SUCCESS), "SQLConfigDriver failed %d, %u\n", sql_ret, error_code); > + > + ret = SQLConfigDriver(NULL, ODBC_CONFIG_DRIVER, "WINE ODBC Driver Path", "empty", error, sizeof(error), NULL); > + ok(!ret, "SQLConfigDriver successed\n"); > + sql_ret = SQLInstallerErrorW(1, &error_code, NULL, 0, NULL); > + ok(sql_ret && error_code == ODBC_ERROR_INVALID_KEYWORD_VALUE, "SQLConfigDriver failed %d, %u\n", sql_ret, error_code); > + > if (ret) > { This entire block is now skipped if things proceed as expected... Also, 'successed' is not a word ;-) Huw.

1 0

Re: [PATCH] oleaut32: Pass the correct variable to VariantClear
by Huw Davies April 18, 2017

April 18, 2017

On Tue, Apr 18, 2017 at 04:05:31AM +0000, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oleaut32/vartype.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/oleaut32/vartype.c b/dlls/oleaut32/vartype.c > index fc5a025..3513399 100644 > --- a/dlls/oleaut32/vartype.c > +++ b/dlls/oleaut32/vartype.c > @@ -136,7 +136,7 @@ static HRESULT VARIANT_FromDisp(IDispatch* pdispIn, LCID lcid, void* pOut, > if (SUCCEEDED(hRet)) > { > VARIANT_CopyData(&dstVar, vt, pOut); > - VariantClear(&srcVar); > + VariantClear(&dstVar); This isn't right. In the BSTR case (the only interesting case) CopyData doesn't allocate a new BSTR, so you would end up free'ing the BSTR you return. This VariantClear() should just go away. Huw.

1 0

Re: [v3 PATCH] oleaut32: Improve support for IDispatch in VarCat
by Marvin April 18, 2017

April 18, 2017

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=30222 Your paranoid android. === wxppro (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w2003std (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === wvistau64 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w2008s64 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w7u (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w7pro64 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w8 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w864 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w1064 (32 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === wvistau64 (64 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w2008s64 (64 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w7pro64 (64 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w864 (64 bit vartest) === vartest.c:6153: Test failed: got 0x00000000 === w1064 (64 bit vartest) === vartest.c:6153: Test failed: got 0x00000000

1 0

Re: [v2 2/3] d3dx9: Use magic number instead of parameter tables for parameter handles.
by Matteo Bruni April 17, 2017

April 17, 2017

2017-04-11 15:58 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > static struct d3dx_parameter *get_valid_parameter(struct d3dx9_base_effect *base, D3DXHANDLE parameter) > { > - struct d3dx_parameter **handle_param = (struct d3dx_parameter **)parameter; > + struct d3dx_parameter *handle_param = (struct d3dx_parameter *)parameter; > > - if (handle_param >= base->param_table.table && handle_param < base->param_table.table + base->param_table.count) > - return *handle_param; > + if (handle_param && !strncmp(handle_param->magic_string, parameter_magic_string, > + sizeof(parameter_magic_string))) > + return handle_param; > > return get_parameter_by_name(base, NULL, parameter); > } Not new and somewhat separate from the patch, although it gets "more interesting" with the new handles scheme: we should probably avoid the call to get_parameter_by_name() if the effect was created with the D3DXFX_LARGEADDRESSAWARE flag, returning NULL instead. Worth a test I think.

2 4

Re: [5/6] secur32/tests: Add tests with SECPKG_ATTR_KEY_INFO.
by Marvin April 17, 2017

April 17, 2017

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=30216 Your paranoid android. === wxppro (32 bit schannel) === schannel.c:931: Test failed: key_info.SignatureAlgorithm = 0000 schannel.c:932: Test failed: key_info.sSignatureAlgorithmName = PKCS === w2003std (32 bit schannel) === schannel.c:931: Test failed: key_info.SignatureAlgorithm = 0000 schannel.c:932: Test failed: key_info.sSignatureAlgorithmName = PKCS

1 0

Re: [PATCH 10/10] wined3d: Update only dirty region for level 0 in wined3d_device_update_texture().
by Marvin April 17, 2017

April 17, 2017

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=30215 Your paranoid android. === w1064 (32 bit visual) === visual.c:7944: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 visual.c:7992: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors).

1 0

Re: [PATCH] oleaut32: Improve support for IDispatch in VarCat
by Nikolay Sivov April 17, 2017

April 17, 2017

Another thing I noticed, also unrelated to your changes, but to VarCat - static strings there should go away.

1 0

Re: localeNameToLCID
by Marvin April 16, 2017

April 16, 2017

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=30192 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin April 16, 2017

April 16, 2017

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=30191 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin April 16, 2017

April 16, 2017

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=30190 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: locale
by Marvin April 16, 2017

April 16, 2017

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=30189 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test inparse_locale_name()
by Marvin April 16, 2017

April 16, 2017

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=30188 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin April 16, 2017

April 16, 2017

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=30187 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin April 15, 2017

April 15, 2017

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=30184 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin April 15, 2017

April 15, 2017

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=30183 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin April 15, 2017

April 15, 2017

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=30182 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin April 15, 2017

April 15, 2017

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=30181 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: PATCH:kernel32/locale:Fix some bugs about special Chinese test inparse_locale_name()
by Nikolay Sivov April 14, 2017

April 14, 2017

On 14.04.2017 13:58, loagen95 wrote: > I tried in this way ,but it doesn't work. > 发自我的iPhone Please be more specific, what did you try and it didn't work? > > > ------------------ Original ------------------ > *From:* Nikolay Sivov <bunglehead(a)gmail.com> > *Date:* Fri,Apr 14,2017 18:42 > *To:* wine-devel <wine-devel(a)winehq.org> > *Cc:* loagen95 <loagen95(a)gmail.com> > *Subject:* Re: PATCH:kernel32/locale:Fix some bugs about special Chinese > test inparse_locale_name() > > On 14.04.2017 13:21, THuang wrote: >> >> > > >> @@ -457,6 +457,8 @@ static void parse_locale_name( const WCHAR *str, struct locale_name *name ) >> static const WCHAR cW[] = {'C',0}; >> static const WCHAR latinW[] = {'l','a','t','i','n',0}; >> static const WCHAR latnW[] = {'-','L','a','t','n',0}; >> + static const WCHAR HantW[] = {'-','H','a','n','t',0}; >> + static const WCHAR HansW[] = {'-','H','a','n','s',0}; >> WCHAR *p; >> >> TRACE("%s\n", debugstr_w(str)); >> @@ -487,6 +489,16 @@ static void parse_locale_name( const WCHAR *str, struct locale_name *name ) >> else if (*p == '-') /* Windows format */ >> { >> strcpyW( name->win_name, name->lang ); >> + if(!strcmpiW(p,HantW)){ >> + name->lcid = 0x0c04; >> + name->matches = 1; >> + return ; >> + } >> + if(!strcmpiW(p,HansW)){ >> + name->lcid = 0x0804; >> + name->matches = 1; >> + return ; >> + } >> *p++ = 0; >> name->country = p; >> if (!(p = strpbrkW( p, winsepW ))) goto done; > > Well, no, that's not how it works. Did you explore a possibility if > adding hant/hans specific locale data to kernel32/nls will help? >

1 0

Re: PATCH:kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Nikolay Sivov April 14, 2017

April 14, 2017

On 14.04.2017 13:21, THuang wrote: > > > @@ -457,6 +457,8 @@ static void parse_locale_name( const WCHAR *str, struct locale_name *name ) > static const WCHAR cW[] = {'C',0}; > static const WCHAR latinW[] = {'l','a','t','i','n',0}; > static const WCHAR latnW[] = {'-','L','a','t','n',0}; > + static const WCHAR HantW[] = {'-','H','a','n','t',0}; > + static const WCHAR HansW[] = {'-','H','a','n','s',0}; > WCHAR *p; > > TRACE("%s\n", debugstr_w(str)); > @@ -487,6 +489,16 @@ static void parse_locale_name( const WCHAR *str, struct locale_name *name ) > else if (*p == '-') /* Windows format */ > { > strcpyW( name->win_name, name->lang ); > + if(!strcmpiW(p,HantW)){ > + name->lcid = 0x0c04; > + name->matches = 1; > + return ; > + } > + if(!strcmpiW(p,HansW)){ > + name->lcid = 0x0804; > + name->matches = 1; > + return ; > + } > *p++ = 0; > name->country = p; > if (!(p = strpbrkW( p, winsepW ))) goto done; Well, no, that's not how it works. Did you explore a possibility if adding hant/hans specific locale data to kernel32/nls will help?

1 0

Re: PATCH:kernel32/locale:Fix some bugs about special Chinese test in parse_locale_name()
by Marvin April 14, 2017

April 14, 2017

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=30177 Your paranoid android. === wvistau64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (32 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === wvistau64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed === w2008s64 (64 bit locale) === locale.c:4532: Test failed: IsValidLocaleName failed locale.c:4534: Test failed: IsValidLocaleName failed

1 0

Re: [v2 3/3] d3dx9: Compare parameter definition instead of parameter handle in IsParameterUsed().
by Matteo Bruni April 13, 2017

April 13, 2017

2017-04-11 15:58 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > is_same_parameter() is defined this way (argument type and placement in the file) > for a more straightforward reuse later in shared parameters implementation. > - if (walk_state_dep(&pass->states[j], compare_param_ptr, param)) > + if (walk_state_dep(&pass->states[j], (walk_parameter_dep_func)is_same_parameter, param)) The cast isn't nice though. Either change the signature of is_same_parameter() to match walk_parameter_dep_func or, if that really isn't an option, add a wrapper function with the correct signature and use that here instead. Even if you prefer the latter, it's probably better to do that only when you need it, in a later patch.

1 0

Re: [PATCH 1/3] d3dx9/tests: Add tests for cross effect handles usage.
by Matteo Bruni April 13, 2017

April 13, 2017

2017-04-11 15:22 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/tests/effect.c | 75 ++++++++++++++++++++++++++++++++++++++++---- > 1 file changed, 69 insertions(+), 6 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c > index de5ae69..62da636 100644 > --- a/dlls/d3dx9_36/tests/effect.c > +++ b/dlls/d3dx9_36/tests/effect.c > @@ -4515,18 +4515,26 @@ static void test_isparameterused_children(ID3DXEffect *effect, D3DXHANDLE tech, > } > } > > -static void test_isparameterused_param_with_children(ID3DXEffect *effect, D3DXHANDLE tech, const char *name, > - BOOL expected_result) > +static void test_isparameterused_param_with_children(ID3DXEffect *effect, ID3DXEffect *effect2, D3DXHANDLE tech, > + const char *name, BOOL expected_result) I think you want to pass the source line to the function (like e.g. test_effect_preshader_compare_vconsts()) now that you call it from multiple places. > { > D3DXHANDLE param; > > - param = effect->lpVtbl->GetParameterByName(effect, NULL, name); > + ok(!effect->lpVtbl->IsParameterUsed(effect, (D3DXHANDLE)name, tech) == !expected_result, > + "Unexpected IsParameterUsed() result for %s.\n", name); > + > + if (effect2) > + param = effect2->lpVtbl->GetParameterByName(effect2, NULL, name); > + else > + param = effect->lpVtbl->GetParameterByName(effect, NULL, name); > ok(!!param, "GetParameterByName failed for %s.\n", name); > > + todo_wine_if(!!effect2 && expected_result) You don't need the !! here, the && gives an integer result anyway. > ok(!effect->lpVtbl->IsParameterUsed(effect, param, tech) == !expected_result, > "Unexpected IsParameterUsed() result for %s.\n", name); This is not new, but again the negations shouldn't be necessary. Actually if it turns out that they are, that means IsParameterUsed() doesn't always return a proper BOOL and that's an interesting result by itself. > +static void test_cross_effect_handle(IDirect3DDevice9 *device) > +{ > + ID3DXEffect *effect1, *effect2; > + D3DXHANDLE param1, param2; > + static int expected_ivect[4] = {28, 29, 30, 31}; > + int ivect[4]; > + HRESULT hr; > + > + hr = D3DXCreateEffect(device, test_effect_preshader_effect_blob, sizeof(test_effect_preshader_effect_blob), > + NULL, NULL, 0, NULL, &effect1, NULL); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + hr = D3DXCreateEffect(device, test_effect_preshader_effect_blob, sizeof(test_effect_preshader_effect_blob), > + NULL, NULL, 0, NULL, &effect2, NULL); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); It probably makes sense to add a ok(effect1 != effect2) here, to show that native doesn't do effect object deduplication (which would trivially imply that the rest of this test passes). > + param1 = effect1->lpVtbl->GetParameterByName(effect1, NULL, "g_iVect"); > + ok(!!param1, "GetParameterByName failed.\n"); > + > + param2 = effect2->lpVtbl->GetParameterByName(effect2, NULL, "g_iVect"); > + ok(!!param2, "GetParameterByName failed.\n"); Same here with param1 and param2.

1 0

Re: [PATCH 1/8] mshtml/tests: Added IMarshal and IManagedObject QueryInterface tests.
by Marvin April 13, 2017

April 13, 2017

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=30167 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2671: Test failed: unexpected call GetOverrideKeyPath htmldoc.c:5081: Test failed: unexpected call {d9befc84-f21e-4166-874b-a8d3010dc764}

1 0

Re: [PATCH 1/3] uuid: Include mscoree.idl.
by Alexandre Julliard April 13, 2017

April 13, 2017

Jacek Caban <jacek(a)codeweavers.com> writes: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/uuid/uuid.c | 1 + > 1 file changed, 1 insertion(+) > > > diff --git a/dlls/uuid/uuid.c b/dlls/uuid/uuid.c > index 913e99c..b8e15a2 100644 > --- a/dlls/uuid/uuid.c > +++ b/dlls/uuid/uuid.c > @@ -89,6 +89,7 @@ DEFINE_GUID(GUID_NULL,0,0,0,0,0,0,0,0,0,0,0); > #include "netcfgx.h" > #include "shimgdata.h" > #include "comsvcs.h" > +#include "mscoree.h" That doesn't seem to match the PSDK. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] msvcp90: Update exception RTTI data to reflect it's part of std namespace
by Piotr Caban April 13, 2017

April 13, 2017

Hi, On 04/12/17 23:32, Daniel Lehman wrote: > -#ifdef _MSVCIRT > +#if defined(_MSVCIRT) || (_MSVCP_VER >= 80) I think that this condition should be following: #if _MSVCP_VER >= 80 ... AVexception(a)std #else ... AVexception Thanks, Piotr

1 0

Re: [v2 PATCH] odbccp32: Handle ODBC_CONFIG_DRIVER request in SQLConfigDriver/W
by Marvin April 13, 2017

April 13, 2017

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=30163 Your paranoid android. === wxppro (32 bit misc) === 0a20:misc: unhandled exception c0000005 at 5FE8DFF9

1 0

Re: [PATCH 2/3] mshtml/tests: Added IMarshal and IManagedObject QueryInterface tests.
by Marvin April 12, 2017

April 12, 2017

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=30156 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2671: Test failed: unexpected call GetOverrideKeyPath

1 0

Re: [PATCH 2/3] regedit: Validate REG_SZ import data before processing it any further
by Alexandre Julliard April 12, 2017

April 12, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -390,6 +390,25 @@ static const WCHAR *reg_type_to_wchar(DWORD type) > return NULL; > } > > +static BOOL validate_reg_sz_data(WCHAR *str) > +{ > + WCHAR *p, *end; > + > + if (!*str || !(p = strchrW(str, '"'))) > + return FALSE; > + > + while (*p && *(p - 1) == '\\') > + p = strchrW(++p, '"'); The backslash could have been escaped, you have to check the whole string. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] d3d9/tests: Relax the partially initialized varyings test (v2).
by Marvin April 12, 2017

April 12, 2017

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=30147 Your paranoid android. === w1064 (64 bit visual) === visual.c:7944: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080

1 0

Re: [PATCH 5/5] d3d9/tests: Fix stream_test cases which do not use stream 0.
by Marvin April 12, 2017

April 12, 2017

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=30146 Your paranoid android. === w8 (32 bit visual) === visual.c:7992: Test failed: Got unexpected color 0x00ff0000 for quad 2 (different colors).

1 0

Re: [PATCH 1/5] d3d9/tests: Relax the partially initialized varyings test.
by Marvin April 12, 2017

April 12, 2017

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=30142 Your paranoid android. === w8 (32 bit visual) === visual.c:7928: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080

1 0

Re: [1/2] winhttp/tests: Test when large amount of data is returned from a 401.
by Marvin April 12, 2017

April 12, 2017

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=30140 Your paranoid android. === wxppro (32 bit winhttp) === winhttp.c:1143: Test failed: request failed unexpectedly 400

2 1

Re: [2/2] winhttp: Always drain content before sending the next request.
by Marvin April 12, 2017

April 12, 2017

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=30141 Your paranoid android. === w2003std (32 bit winhttp) === winhttp.c:1143: Test failed: request failed unexpectedly 400

1 0

Re: [PATCH] winhttp/tests: Test when large amount of data is returned from a 410
by Marvin April 11, 2017

April 11, 2017

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=30136 Your paranoid android. === wvistau64 (32 bit winhttp) === winhttp.c:1143: Test failed: request failed unexpectedly 400 === w2008s64 (64 bit winhttp) === winhttp.c:1143: Test failed: request failed unexpectedly 400

1 0

Re: [PATCH 2/5] wined3d: Send texture dirty region updates through the command stream.
by Józef Kucia April 11, 2017

April 11, 2017

On Tue, Apr 11, 2017 at 11:24 PM, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > - context = context_acquire(texture->resource.device, NULL, 0); > - sub_resource_idx = layer * texture->level_count; > - for (i = 0; i < texture->level_count; ++i, ++sub_resource_idx) > - { > - if (!wined3d_texture_load_location(texture, sub_resource_idx, context, texture->resource.map_binding)) > - { > - ERR("Failed to load location %s.\n", wined3d_debug_location(texture->resource.map_binding)); > - context_release(context); > - return E_OUTOFMEMORY; > - } > - wined3d_texture_invalidate_location(texture, sub_resource_idx, ~texture->resource.map_binding); > - } > - context_release(context); > + wined3d_cs_emit_add_dirty_texture_region(texture->resource.device->cs, texture, layer * texture->level_count); I think that just "layer" should be passed as the last argument to wined3d_cs_emit_add_dirty_texture_region().

1 0

Re: [PATCH v2] mountmgr: Create registry entries for serial ports.
by Alexandre Julliard April 11, 2017

April 11, 2017

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -453,7 +457,21 @@ NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > RegCloseKey( hkey ); > if (!RegCreateKeyExW( devicemap_key, serialW, 0, NULL, REG_OPTION_VOLATILE, > KEY_ALL_ACCESS, NULL, &hkey, NULL )) > + { > + /* create a registry entry for each serial port */ > + for (i = 1; i <= 256; i++) > + { > + sprintfW( pathW, comW, i ); > + serial_device = CreateFileW( pathW, 0, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL ); > + if (serial_device == INVALID_HANDLE_VALUE) > + break; > + > + CloseHandle( serial_device ); > + RegSetValueExW( hkey, pathW + 4, 0, REG_SZ, (BYTE *)(pathW + 4), > + (strlenW( pathW + 4 ) + 1) * sizeof(WCHAR) ); The registry key name is supposed to be the NT device. Ideally, what you'd want is to actually create the NT device pointing it to the corresponding Unix device, as well as the DOS symlink. If you do this, CreateFile can then use the normal path, and the ntdll serial device detection logic can be moved to mountmgr. -- Alexandre Julliard julliard(a)winehq.org

1 0

Putting in place traffic shaping on winehq
by Jeremy White April 11, 2017

April 11, 2017

Hey folks, We've been getting nailed with peak charges on the traffic coming from the WineHQ web server. We think a large reason for this is that we were not sophisticated in how we flushed the fastly cache, so we'd get slammed in a big rush when we flushed. I believe that Jeremy Newman has fixed that now, so hopefully it won't happen again. But those overcharges are brutal (i.e. thousands of dollars) :-(. So I'm planning to put in place some traffic shaping to provide a hard upper limit for winehq (I'm going to impose 8Mbit; we currently pay for 10Mbpit committed; if I up that to 20, I may expand that). This should not disrupt anything, but I thought I'd warn folks, so you'd know to blame me if things suddenly go dark <grin>. Cheers, Jeremy

3 4

Re: [PATCH 2/4] user32/tests: Correctly restore the caption sizes when run in DPI scaling mode.
by Marvin April 11, 2017

April 11, 2017

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=30112 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2500: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2511: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (32 bit sysparams) === sysparams.c:272: SPI_SETSCREENSAVETIMEOUT failed for reason: 329. Indicating test failure and skipping remainder of test sysparams.c:273: Test failed: SystemParametersInfoA: rc=0 err=329 sysparams.c:273: Test failed: SystemParametersInfoA: rc=0 err=329 sysparams.c:2500: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2511: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

2 1

Re: [PATCH 4/4] user32/tests: Fix tests for minimium icon spacing when not in DPI scaling mode.
by Marvin April 11, 2017

April 11, 2017

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=30117 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2500: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2511: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0

Re: [PATCH 3/4] user32/tests: Fix a few failures in DPI scaling mode.
by Marvin April 11, 2017

April 11, 2017

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=30116 Your paranoid android. === w7u (32 bit sysparams) === sysparams.c:246: Test failed: Missed a message: change_counter=0 sysparams.c:249: Test failed: Wrong action got 0 expected 4 sysparams.c:246: Test failed: Missed a message: change_counter=0 sysparams.c:249: Test failed: Wrong action got 0 expected 4 === w8 (32 bit sysparams) === sysparams.c:2500: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2511: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (32 bit sysparams) === The task timed out

1 0

Re: [PATCH 2/2] regedit: Re-implement convertHextToDWord() (v3)
by Alexandre Julliard April 11, 2017

April 11, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > + while (*buf == ' ' || *buf == '\t') buf++; > + if (!*buf) goto exit; > + > + p = buf; > + while (isxdigit(*p)) > + { > + count++; > + p++; > } > - return TRUE; > + if (count > 8) goto exit; > + > + end = p; > + while (*p == ' ' || *p == '\t') p++; > + if (*p && *p != ';') goto exit; > + > + *end = 0; > + *dw = strtoul(buf, &end, 16); > + ret = TRUE; > + > + exit: > + if (!ret) output_message(STRING_INVALID_HEX); > + HeapFree(GetProcessHeap(), 0, buf); The pointer has been modified, you need to free the original one. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/2] endproc.c: Implement ProcessPage_OnEndProcessTree
by Stefan Dösinger April 11, 2017

April 11, 2017

Hi Akarsha, Thank you for your patches! My apologies for the very late review of your code. I am currently catching up on my mail after moving :-\ . Your patch has numerous compile errors. Please make sure that the code compiles without errors or warnings before sending it. Am 2017-03-30 um 19:57 schrieb Akarsha Sehwag: > +typedef struct process_list { > + int *pid; /*dynamic array to store the process IDs*/ MODULEENTRY32.th32ProcessID is a DWORD, please use it here as well. > + SIZE_T count; /*index to maintain the last entry of the array;*/ > + SIZE_T size; /*the current size of the pid array*/ > +} process_list; Is it necessary to store the child processes in a separate list? I'd expect that CreateToolhelp32Snapshot creates a snapshot that is not affected by changes to the process tree after it returns. If this is the case you can kill processes as you iterate over the snapshot with Process32Next. This would simplify the code a lot If you keep the list please use a wine list from include/wine/list.h. This will also give you more flexibility in the order of how you kill the processes, see below. > +static void init_process_list(process_list *list) { > + list->size = 4; /*initialise size with 4. Will increase if necessary.*/ > + list->pid = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size * sizeof(int)); Minor style hint: You can use sizeof(*list->pid) instead of sizeof(int). That way the code doesn't need changes if the type of pid changes. > + if(!Process32First(snapshot, &entry)) > + return; > + > + do > + { > + if(entry.th32ParentProcessID == pid) > + process_list_append(list, entry.th32ProcessID); > + } while (Process32Next(snapshot, &entry)); > + > + end = list->count; > + > + for(i = start; i < end; ++i) > + { > + enum_process_children(snapshot, list, list->pid[i]); > + } I am not sure if this matters, but this will kill parent processes before their children. It may or may not be the correct thing and may be an interesting thing to find out with a test (unfortunately writing automated tests for taskmgr is not easy) I think the same kind of recursion should work if you operate on the snapshot directly without the helper list. > + for(i = 0; i <= list->last; ++i) { > + hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, list->pid[i]); > > --- patch 2 --- > - for(i = 0; i <= list->last; ++i) { > + for(i = 0; i < list->count; ++i) { This should be merged into patch 1. It is important that the code always builds to prevent problems in git bisect (e.g. assume I am looking for a regression in the d3d code, but one of the revisions I want to test doesn't compile taskmgr) With best regards, Stefan

1 1

Help on how to run winetest in debug
by Yashodeep Mahapatra April 11, 2017

April 11, 2017

Hi All, This is Yashodeep Mahapatra from Birla Institute Of Technology ,Mesra,India. I tried running wine on my machine after building and installing it. But the problem that I am facing is that my system just keeps running the process wine and displays Wine Shell Script in the window. Running wine winecfg also runs in the same way without giving any output on the screen. I also tried running notepad.exe but only a blank screen appeared. wine winecfg command led to this output: err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 err:wincodecs:PngDecoder_CreateInstance Failed reading PNG because unable to find libpng16.16.dylib err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 err:wincodecs:PngDecoder_CreateInstance Failed reading PNG because unable to find libpng16.16.dylib err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 err:wincodecs:PngDecoder_CreateInstance Failed reading PNG because unable to find libpng16.16.dylib err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 and nothing appeared on the screen. wine /programs/winetest/winetest.exe.so gave the following result: err:wincodecs:PngDecoder_CreateInstance Failed reading PNG because unable to find libpng16.16.dylib err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 err:wincodecs:PngDecoder_CreateInstance Failed reading PNG because unable to find libpng16.16.dylib err:menubuilder:convert_to_native_icon error 0x80004005 getting frame 0 Can anyone please help me?

3 2

Re: [PATCH] winhttp/tests: Test when large amount of data is returned from a 410
by Hans Leidekker April 11, 2017

April 11, 2017

On Tue, 2017-04-11 at 02:08 +0000, Alistair Leslie-Hughes wrote: > diff --git a/dlls/winhttp/tests/winhttp.c b/dlls/winhttp/tests/winhttp.c > index a5eff11..0761c2e 100644 > --- a/dlls/winhttp/tests/winhttp.c > +++ b/dlls/winhttp/tests/winhttp.c > @@ -2059,6 +2059,16 @@ static const char multiauth[] = > "Content-Type: text/plain\r\n" > "\r\n"; > > +static const char largeauth[] = > +"HTTP/1.1 401 Unauthorized\r\n" > +"Server: winetest\r\n" > +"WWW-Authenticate: Bearer\r\n" > +"WWW-Authenticate: Basic realm=\"placebo\"\r\n" > +"WWW-Authenticate: NTLM\r\n" > +"Content-Length: 10240\r\n" > +"Content-Type: text/plain\r\n" > +"\r\n"; Please try to be minimal. You're only using NTLM so the other two authenticate headers are not needed. > @@ -2172,6 +2182,20 @@ static DWORD CALLBACK server_thread(LPVOID param) > { > send(c, multiauth, sizeof multiauth - 1, 0); > } > + if(strstr(buffer, "GET /largeauth")) > + { > + if (strstr(buffer, "Authorization: NTLM")) > + send(c, okmsg, sizeof(okmsg) - 1, 0); > + else > + { > + void *data = malloc(10240); > + send(c, largeauth, sizeof largeauth - 1, 0); > + memset(data, 'A', 10240); > + send(c, data, 10240, 0); > + free(data); > + continue; You can avoid the allocation e.g. by sending 1 byte in a loop. > +static void test_large_data_authentication(int port) > +{ > + static const WCHAR largeauthW[] = {'/','l','a','r','g','e','a','u','t','h',0}; > + static const WCHAR getW[] = {'G','E','T',0}; > + static WCHAR userW[] = {'u','s','e','r',0}; > + static WCHAR passW[] = {'p','w','d',0}; > + HINTERNET ses, con, req; > + DWORD supported, first, target, status, size; > + BOOL ret; > + > + ses = WinHttpOpen(test_useragent, WINHTTP_ACCESS_TYPE_NO_PROXY, NULL, NULL, 0); > + ok(ses != NULL, "failed to open session %u\n", GetLastError()); > + > + con = WinHttpConnect(ses, localhostW, port, 0); > + ok(con != NULL, "failed to open a connection %u\n", GetLastError()); > + > + req = WinHttpOpenRequest(con, getW, largeauthW, NULL, NULL, NULL, 0); > + ok(req != NULL, "failed to open a request %u\n", GetLastError()); > + > + ret = WinHttpSendRequest(req, WINHTTP_NO_ADDITIONAL_HEADERS, 0, > + WINHTTP_NO_REQUEST_DATA,0, 0, 0 ); > + ok(ret, "expected success\n"); > + > + ret = WinHttpReceiveResponse(req, NULL); > + ok(ret, "expected success\n"); > + > + size = sizeof(status); > + ret = WinHttpQueryHeaders(req, WINHTTP_QUERY_STATUS_CODE | WINHTTP_QUERY_FLAG_NUMBER, NULL, > + &status, &size, NULL ); > + ok(ret, "expected success\n"); > + ok(status == HTTP_STATUS_DENIED, "got %d\n", status); > + > + supported = first = target = 0xdeadbeef; > + ret = WinHttpQueryAuthSchemes(req, &supported, &first, &target); > + ok(ret, "expected success\n"); > + ok(supported == (WINHTTP_AUTH_SCHEME_BASIC | WINHTTP_AUTH_SCHEME_NTLM), "got %x\n", supported); > + ok(target == WINHTTP_AUTH_TARGET_SERVER, "got %x\n", target); > + ok(first == WINHTTP_AUTH_SCHEME_BASIC, "got %x\n", first); This is also copied from another test and not strictly needed. You can hardcode scheme and target. WinHttpQueryAuthSchemes is already tested elsewhere.

1 0

Re: [v2 PATCH 2/2] odbccp32: Handle ODBC_CONFIG_DRIVER request in SQLConfigDriver/W
by Huw Davies April 11, 2017

April 11, 2017

On Mon, Apr 10, 2017 at 04:30:48AM +0000, Alistair Leslie-Hughes wrote: > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index f28d464..2f415c7 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -303,6 +303,41 @@ static HMODULE load_config_driver(const WCHAR *driver) > return hmod; > } > > +static BOOL write_timeout_value(const WCHAR *driver, const WCHAR *args) > +{ > + static WCHAR cptimeout[] = {'C','P','T','i','m','e','o','u','t',0}; > + long ret; > + HKEY hkey; > + WCHAR *position; > + > + if ( !(position = strstrW(args, cptimeout))) > + return FALSE; > + > + if ((ret = RegOpenKeyW(HKEY_LOCAL_MACHINE, odbcini, &hkey)) == ERROR_SUCCESS) > + { > + HKEY hkeydriver; > + > + if ((ret = RegOpenKeyW(hkey, driver, &hkeydriver)) == ERROR_SUCCESS) > + { > + const WCHAR *value = &args[sizeof(cptimeout) / sizeof(WCHAR)]; > + > + TRACE("CPTimeout value %s\n", debugstr_w(value)); > + if(RegSetValueExW(hkeydriver, cptimeout, 0, REG_SZ, (BYTE*)value, > + strlenW(value) * sizeof(WCHAR)) != ERROR_SUCCESS) > + ERR("Failed to write registry installed key\n"); > + What are the possible formats of the arg string here? You initially strstr to find "CPTimeout" (which is fine). Later on, when you assign value, you're assuming that "CPTimeout" is at the beginning of the string (and this is a pretty ugly way of doing it). You're then writting anything that follows to the registry. Could there be more than one arg, if so how are they separated? Huw.

1 0

Re: [PATCH] winhttp/tests: Test when large amount of data is returned from a 410
by Marvin April 11, 2017

April 11, 2017

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=30105 Your paranoid android. === w864 (64 bit winhttp) === winhttp.c:3831: Test failed: got 80090321

1 0

Re: [PATCH 4/5] wined3d: Fix specular lighting calculation.
by Alexandre Julliard April 10, 2017

April 10, 2017

Matteo Bruni <mbruni(a)codeweavers.com> writes: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > For bug 41827. > > I don't really like the shader_glsl_ffp_vertex_lighting_footer name but I > couldn't think of anything nicer... > > dlls/d3d8/tests/visual.c | 59 +++++++++++++++++++++++++++++++++------------- > dlls/d3d9/tests/visual.c | 59 +++++++++++++++++++++++++++++++++------------- > dlls/ddraw/tests/ddraw2.c | 49 +++++++++++++++++++++++++++++--------- > dlls/ddraw/tests/ddraw4.c | 51 +++++++++++++++++++++++++++++---------- > dlls/ddraw/tests/ddraw7.c | 59 +++++++++++++++++++++++++++++++++------------- > dlls/wined3d/glsl_shader.c | 50 +++++++++++++++------------------------ > 6 files changed, 225 insertions(+), 102 deletions(-) The tests fail here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p d3d8_test.exe.so visual && touch visual.ok visual.c:793: Test failed: Expected color 0x00000000 at location (160, 120), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (320, 120), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (480, 120), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (160, 240), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (320, 240), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (480, 240), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (160, 360), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (320, 360), got 0x00ffffff, case 7. visual.c:793: Test failed: Expected color 0x00000000 at location (480, 360), got 0x00ffffff, case 7. visual.c:2790: Tests skipped: D3DFMT_P8 textures not supported. visual.c:4294: Tests skipped: No RESZ support, skipping RESZ test. visual.c:4971: Tests skipped: Volume DXT5 textures are not supported, skipping test. visual.c:6632: Tests skipped: Volume ATI2N textures are not supported, skipping some tests. Makefile:246: recipe for target 'visual.ok' failed make: *** [visual.ok] Error 9 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] regedit/tests: Add tests for importing DWORD values
by Alexandre Julliard April 10, 2017

April 10, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/tests/regedit.c | 56 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 56 insertions(+) It fails here: ../../../tools/runtest -q -P wine -T ../../.. -M regedit.exe -p regedit.exe_test.exe.so regedit && touch regedit.ok regedit.c:803: Test failed: RegQueryValueEx failed: got 2 regedit.c:804: Test failed: RegQueryValueEx failed: got 2 Makefile:174: recipe for target 'regedit.ok' failed make[1]: *** [regedit.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v2 1/2] d3dx9: Support relative addressing in preshader.
by Matteo Bruni April 10, 2017

April 10, 2017

2017-03-24 23:12 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -697,13 +739,13 @@ static HRESULT parse_preshader(struct d3dx_preshader *pres, unsigned int *ptr, u > for (i = 0; i < pres->ins_count; ++i) > { > for (j = 0; j < pres_op_info[pres->ins[i].op].input_count; ++j) > - update_table_size(pres->regs.table_sizes, pres->ins[i].inputs[j].table, > - get_reg_offset(pres->ins[i].inputs[j].table, > - pres->ins[i].inputs[j].offset + pres->ins[i].component_count - 1)); > + update_table_size(pres->regs.table_sizes, pres->ins[i].inputs[j].reg.table, > + get_reg_offset(pres->ins[i].inputs[j].reg.table, > + pres->ins[i].inputs[j].reg.offset + pres->ins[i].component_count - 1)); > > - update_table_size(pres->regs.table_sizes, pres->ins[i].output.table, > - get_reg_offset(pres->ins[i].output.table, > - pres->ins[i].output.offset + pres->ins[i].component_count - 1)); > + update_table_size(pres->regs.table_sizes, pres->ins[i].output.reg.table, > + get_reg_offset(pres->ins[i].output.reg.table, > + pres->ins[i].output.reg.offset + pres->ins[i].component_count - 1)); Do these update_table_size() always do the right thing with relative addressing? If I'm not mistaken, they should be fine because we only accept relative addressing for CONST and IMMED and the former is taken care by update_table_sizes_consts() just below while the latter's size is set statically just above this chunk. I think that means though that we don't need to call update_table_size() on the input arguments. If that sounds right to you, you could drop that "for(j)" altogether or, probably better, replace the update_table_size() with a check that the argument is not out of bounds (probably returning failure if the check doesn't pass). That should be a separate patch. > @@ -1088,18 +1130,65 @@ static HRESULT init_set_constants(struct d3dx_const_tab *const_tab, ID3DXConstan > return ret; > } > > +static double exec_get_reg_value(struct d3dx_regstore *rs, enum pres_reg_tables table, unsigned int offset) > +{ > + if (!regstore_is_val_set_reg(rs, table, offset / table_info[table].reg_component_count)) > + WARN("Using uninitialized input, table %u, offset %u.\n", table, offset); > + > + return regstore_get_double(rs, table, offset); > +} > + > static double exec_get_arg(struct d3dx_regstore *rs, const struct d3dx_pres_operand *opr, unsigned int comp) > { > - if (!regstore_is_val_set_reg(rs, opr->table, (opr->offset + comp) / table_info[opr->table].reg_component_count)) > - WARN("Using uninitialized input, table %u, offset %u.\n", opr->table, opr->offset + comp); > + unsigned int offset, base_index, reg_index, table; > + > + table = opr->reg.table; > + > + if (opr->index_reg.table == PRES_REGTAB_COUNT) > + base_index = 0; > + else > + base_index = lrint(exec_get_reg_value(rs, opr->index_reg.table, opr->index_reg.offset)); > + > + /* '4' is used instead of reg_component_count, as immediate constants (which have > + * reg_component_count of 1) are still indexed as 4 values according to the tests. > + */ > + offset = base_index * 4 + opr->reg.offset + comp; Actually, is there any reason why reg_component_count for PRES_REGTAB_IMMED isn't 4? Maybe change it to 4 and in parse_preshader() check that const_count is a multiple of 4 (which is something we're depending on anyway). That would be a separate patch too. Clue me if I'm missing anything. > + reg_index = offset / table_info[table].reg_component_count; > + > + if (reg_index >= rs->table_sizes[table]) > + { > + unsigned int wrap_size; > + > + if (table == PRES_REGTAB_CONST) > + { > + /* As it can be guessed from tests (by iterating base register value and > + * observing the period of result values repeat), offset into floating > + * constant table are wrapped to the nearest power of 2 and not to the > + * actual table size. > + */ > + for (wrap_size = 1; wrap_size < rs->table_sizes[table]; wrap_size <<= 1) > + ; Please close the comment on the last text line (i.e. "*/" shouldn't be on its own line) and maybe remove the part in parentheses which is pretty obvious. I like the comment otherwise. Another thing on this, maybe add a WARN() on wrapped accesses to show what offset (or value) is returned in that case? Ignore it if you don't think that's useful.

2 9

Re: [3/3] [resend] wsdapi/tests: Add initial tests for WSDCreateDiscoveryPublisher
by Alexandre Julliard April 10, 2017

April 10, 2017

Owen Rudge <orudge(a)codeweavers.com> writes: > +START_TEST(discovery) > +{ > + HMODULE dllHandle; > + > + CoInitialize(NULL); > + > + dllHandle = LoadLibraryA("wsdapi.dll"); > + > + if (dllHandle) > + { > + BOOL ret; > + > + ret = FreeLibrary(dllHandle); > + ok(ret, "FreeLibrary(1) returned %d\n", GetLastError()); > + } This test doesn't seem very useful. Also there shouldn't be any reason to load the library dynamically, you could simply link to it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/13] msidb: Add stub tool for manipulating MSI databases.
by Hans Leidekker April 10, 2017

April 10, 2017

On Sun, 2017-04-09 at 13:12 -0600, Erich E. Hoover wrote: > The "Windows SDK Components for Windows Installer Developers" has a > command line tool called msidb that is incredibly useful for creating, > editing, and exporting MSI installer databases, think of it as > winemsibuilder on steroids. This patch series implements much of the > functionality of the msidb tool, maintains compatible CLI flags, and > the underlying MSI functionality necessary to support these features. > With this patch series all the existing winemsibuilder functionality > is available, plus the ability to drop streams, export the > _SummaryInformation table, export binary streams (Binary/Icon tables), > and some miscellaneous bug fixes. A big feature of the implementation > is that it allows you to edit existing installer databases, rather > than just creating new ones. I can see how the extra functionality is useful for package builders but at the same time it's not essential to build Wine. That doesn't mean we can't maintain it in Wine, but I can also see it being part of a separate SDK tools project. Have you considered that?

2 1

Re: [PATCH] regedit: Do not import DWORD values beginning with "0x" (v2)
by Marvin April 10, 2017

April 10, 2017

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

1 0

Re: [PATCH] xmllite/writer: Fix IID argument handling in CreateXmlWriter()
by Jacek Caban April 10, 2017

April 10, 2017

Hi Nikolay, On 4/10/17 6:37 AM, Nikolay Sivov wrote: > + hr = CreateXmlWriter(&IID_IStream, (void **)&unk, NULL); > + ok(hr == E_NOINTERFACE, "got %08x\n", hr); > + > + hr = CreateXmlWriter(&IID_IUnknown, (void **)&unk, NULL); > + ok(hr == S_OK, "Expected S_OK, got %08x\n", hr); > + hr = IUnknown_QueryInterface(unk, &IID_IUnknown, (void **)&writer); > + I think you meant IID_IXmlWriter here. Jacek

2 1

Re: [PATCH 2/2] odbccp32: Handle ODBC_CONFIG_DRIVER request in SQLConfigDriver/W
by Marvin April 10, 2017

April 10, 2017

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=30067 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 2/2 v2] ntdll: Zero debug registers after thread creation
by Michael Müller April 9, 2017

April 9, 2017

Am 07.04.2017 um 17:52 schrieb Christian Inci: > DWORD tid = 0; > int request_pipe[2]; > + CONTEXT ctx; > NTSTATUS status; > > [...] > > + ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS; > + NtSetContextThread(handle, &ctx); > + You didn't initialize the register values and therefore set the debug registers to random stack values. You should either initialize them manually or memset the whole struct.

3 4

Re: [PATCH v2 1/5] wined3d: Save pixel and vertex shader resource views in stateblocks.
by Henri Verbeet April 9, 2017

April 9, 2017

On 5 April 2017 at 15:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -3129,6 +3129,8 @@ struct wined3d_saved_states > WORD vertexShaderConstantsB; /* WINED3D_MAX_CONSTS_B, 16 */ > WORD vertexShaderConstantsI; /* WINED3D_MAX_CONSTS_I, 16 */ > BOOL vs_consts_f[WINED3D_MAX_VS_CONSTS_F]; > + DWORD pixel_shader_resource_views : 16; /* MAX_FRAGMENT_SAMPLERS, 16 */ > + DWORD vertex_shader_resource_views : 4; /* MAX_VERTEX_SAMPLERS, 4 */ > DWORD textures : 20; /* MAX_COMBINED_SAMPLERS, 20 */ > DWORD indices : 1; > DWORD material : 1; > @@ -3137,17 +3139,18 @@ struct wined3d_saved_states > DWORD pixelShader : 1; > DWORD vertexShader : 1; > DWORD scissorRect : 1; > - DWORD padding : 5; > + DWORD padding : 17; That doesn't do the right thing, unfortunately: struct wined3d_saved_states { DWORD transform[16]; /* 0 64 */ /* --- cacheline 1 boundary (64 bytes) --- */ WORD streamSource; /* 64 2 */ WORD streamFreq; /* 66 2 */ DWORD renderState[7]; /* 68 28 */ DWORD textureState[8]; /* 96 32 */ /* --- cacheline 2 boundary (128 bytes) --- */ WORD samplerState[20]; /* 128 40 */ DWORD clipplane; /* 168 4 */ WORD pixelShaderConstantsB; /* 172 2 */ WORD pixelShaderConstantsI; /* 174 2 */ BOOL ps_consts_f[224]; /* 176 896 */ /* --- cacheline 16 boundary (1024 bytes) was 48 bytes ago --- */ WORD vertexShaderConstantsB; /* 1072 2 */ WORD vertexShaderConstantsI; /* 1074 2 */ BOOL vs_consts_f[256]; /* 1076 1024 */ /* --- cacheline 32 boundary (2048 bytes) was 52 bytes ago --- */ DWORD pixel_shader_resource_views:16; /* 2100:16 4 */ DWORD vertex_shader_resource_views:4; /* 2100:12 4 */ /* XXX 12 bits hole, try to pack */ DWORD textures:20; /* 2104:12 4 */ DWORD indices:1; /* 2104:11 4 */ DWORD material:1; /* 2104:10 4 */ DWORD viewport:1; /* 2104: 9 4 */ DWORD vertexDecl:1; /* 2104: 8 4 */ DWORD pixelShader:1; /* 2104: 7 4 */ DWORD vertexShader:1; /* 2104: 6 4 */ DWORD scissorRect:1; /* 2104: 5 4 */ /* XXX 5 bits hole, try to pack */ DWORD padding:17; /* 2108:15 4 */ /* --- cacheline 33 boundary (2112 bytes) --- */ /* size: 2112, cachelines: 33, members: 24 */ /* bit holes: 2, sum bit holes: 17 bits */ /* bit_padding: 15 bits */ }; Incidentally, this also illustrates the issue of the ps_consts_f and vs_consts_f fields using up way more space than needed.

3 2

Re: [resend PATCH 4/4] d3dx9: Effect should preserve states regardless of state manager presence.
by Matteo Bruni April 9, 2017

April 9, 2017

2017-04-06 1:32 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> Given that you have to resend anyway... It's generally preferred to write commit subjects in the imperative mood, so in this case it would be "Preserve states regardless of state manager presence." A slightly different, more direct, alternative would be "Ignore state manager when saving and restoring device state." Choose whatever you prefer (including something else entirely).

1 0

Re: [resend PATCH 2/4] d3dx9/tests: Add tests for effect state manager.
by Matteo Bruni April 9, 2017

April 9, 2017

2017-04-06 1:32 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > + static const struct test_state_manager_update test_effect_states_record[] = expected_updates[]?

1 0

Re: [resend PATCH 1/4] d3dx9/tests: Add test implementation for ID3DXEffectStateManager interface.
by Matteo Bruni April 9, 2017

April 9, 2017

2017-04-06 1:32 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +struct test_state_manager_update > +{ > + unsigned int state_op; > + DWORD param1; > + DWORD param2; > +}; > + > +struct test_ID3DXEffectStateManagerImpl Sorry for being a PITA but it would be better to avoid this kind of naming, at a first glance it might be confused with a MS structure. Just call it test_manager or similar. > +static HRESULT WINAPI test_ID3DXEffectStateManagerImpl_QueryInterface(ID3DXEffectStateManager *iface, > + REFIID riid, void **object) > +{ > + if (IsEqualGUID(riid, &IID_IUnknown) > + || IsEqualGUID(riid, &IID_ID3DXEffectStateManager)) > + { > + iface->lpVtbl->AddRef(iface); > + *object = iface; > + return S_OK; > + } > + > + return E_NOINTERFACE; > +} Do you know if this is called by d3dx9 at all? Either way, adding some ok() here would be nice. > + state_manager->update_record = new_alloc; > + state_manager->update_record_size = new_size; > + > + } Spurious blank line. Also I'm not sure it makes a lot of sense to use new_alloc / new_size and check that the allocation succeeded with ok() to then always assign the new variables to the struct fields anyway. Memory allocation should never legitimately fail there so I'd remove the vestigial error checking entirely and let the test crash if the allocation somehow fails.

1 0

Re: [PATCH] d3dx11: Add D3DX11FilterTexture stub.
by Matteo Bruni April 9, 2017

April 9, 2017

2017-04-03 18:49 GMT+02:00 Andrey Gusev <andrey.goosev(a)gmail.com>: > Signed-off-by: Andrey Gusev <andrey.goosev(a)gmail.com> > diff --git a/include/d3dx11tex.h b/include/d3dx11tex.h > index 16b280a..81a43cc 100644 > --- a/include/d3dx11tex.h > +++ b/include/d3dx11tex.h > @@ -93,6 +93,8 @@ HRESULT WINAPI D3DX11CreateShaderResourceViewFromMemory(ID3D11Device *device, co > HRESULT WINAPI D3DX11CreateTextureFromMemory(ID3D11Device *device, const void *src_data, SIZE_T src_data_size, > D3DX11_IMAGE_LOAD_INFO *loadinfo, ID3DX11ThreadPump *pump, ID3D11Resource **texture, HRESULT *hresult); > > +HRESULT WINAPI D3DX11FilterTexture(ID3D11DeviceContext *context, ID3D11Resource *texture, UINT src_level, UINT filter); > + > HRESULT WINAPI D3DX11GetImageInfoFromMemory(const void *src_data, SIZE_T src_data_size, ID3DX11ThreadPump *pump, > D3DX11_IMAGE_INFO *img_info, HRESULT *hresult); > > -- > 2.7.4 Could you please also add the D3DX11_FILTER_FLAG definition to d3dx11tex.h? Looks okay otherwise.

1 0

GSoC Mentors
by André Hentschel April 9, 2017

April 9, 2017

Hi, for those who had not had a look at the proposals yet, please review them and comment. Thanks!

1 0

Re: [PATCH v5] ntdll/tests: Check debug registers of a newly created thread
by Marvin April 9, 2017

April 9, 2017

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=30054 Your paranoid android. === build (build) === Make failed

1 0

Wine-Staging Performance Regression since 2.0rc6
by Bjoern Bidar/Thaodan April 8, 2017

April 8, 2017

Hello guys I hope this is the right place to ask. Since after 2.0rc6 many Wow user getting worse performance. For comparsion: 2.0rc6: 65fps 2.1/2.2: about 40 2.4: no change either even the main menu lags when you look close. To test just download the game and open it even the main menu lags as said before. Me and many users don't know how to help in debugging the issue, so im asking here. Greetings Björn

1 0

Re: [PATCH 2/4] winex11: move XDestroyWindow() after free_gl_drawable() in set_win_format()
by Alexandre Julliard April 8, 2017

April 8, 2017

Miklós Máté <mtmkls(a)gmail.com> writes: > @@ -1334,21 +1334,21 @@ static void free_gl_drawable( struct gl_drawable *gl ) > /*********************************************************************** > * create_gl_drawable > */ > -static BOOL create_gl_drawable( HWND hwnd, struct gl_drawable *gl ) > +static BOOL create_gl_drawable( HWND hwnd, struct gl_drawable *gl, struct x11drv_win_data *data ) > { > gl->drawable = 0; > > if (GetAncestor( hwnd, GA_PARENT ) == GetDesktopWindow()) /* top-level window */ > { > - struct x11drv_win_data *data = get_win_data( hwnd ); > - > if (data) > { > gl->type = DC_GL_WINDOW; > gl->window = create_client_window( data, gl->visual ); > if (gl->window) > + { > gl->drawable = pglXCreateWindow( gdi_display, gl->format->fbconfig, gl->window, NULL ); > - release_win_data( data ); > + XSync( gdi_display, False ); Do you really need all the extra XSync calls? We try to avoid server round-trips as much as possible. -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [PATCH 1/2 v4] ntdll/tests: Check debug registers of a newly created thread
by Dmitry Timoshkov April 8, 2017

April 8, 2017

Hi Christian, Christian Inci <chris.wine(a)broke-the-inter.net> wrote: > + thread = CreateThread(NULL, 0, dummy_thread, NULL, CREATE_SUSPENDED, NULL); > + ok(thread != INVALID_HANDLE_VALUE, "CreateThread failed with %d\n", GetLastError()); > + memset(&ctx, 0, sizeof(ctx)); > + ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS; > + status = pNtGetContextThread(thread, &ctx); > + ok(status == STATUS_SUCCESS, "NtGetContextThread failed with %x\n", status); > + ok(!ctx.Dr0, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr0); > + ok(!ctx.Dr1, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr1); > + ok(!ctx.Dr2, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr2); > + ok(!ctx.Dr3, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr3); > + todo_wine ok(!ctx.Dr6, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr6); > + todo_wine ok(!ctx.Dr7, "expected 0, got %lx\n", (DWORD_PTR)ctx.Dr7); > + CloseHandle(thread); > +} The thread needs to be explicitly terminated. -- Dmitry.

2 1

Re: [PATCH] tools/winedump: Change duplicate flag.
by Alexandre Julliard April 7, 2017

April 7, 2017

Zebediah Figura <z.figura12(a)gmail.com> writes: > diff --git a/tools/winedump/main.c b/tools/winedump/main.c > index a4ebb43..5c683f6 100644 > --- a/tools/winedump/main.c > +++ b/tools/winedump/main.c > @@ -226,7 +226,7 @@ static const struct my_option option_table[] = { > {"-v", SPEC, 0, do_verbose, "-v Show lots of detail while working (verbose)."}, > {"dump", DUMP, 0, do_dump, "dump <file> Dump the contents of 'file' (dll, exe, lib...)"}, > {"-C", DUMP, 0, do_symdmngl, "-C Turn on symbol demangling"}, > - {"-f", DUMP, 0, do_dumphead, "-f Dump file header information"}, > + {"-F", DUMP, 0, do_dumphead, "-F Dump file header information"}, Not a big deal, but is there a reason for changing this? -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [PATCH 1/2 v2] ntdll/tests: Check debug registers of a newly created thread
by Christian Inci April 7, 2017

April 7, 2017

Forgot to send the response to wine-devel too. On 04/07/2017 10:01 PM, Christian Inci wrote: > Thank you very much for letting me know. > > Setting Dr7 with the "wrong" bits set will result into this error. > I'm going to change the testcase right now. > > On 04/07/2017 09:07 PM, Alexandre Julliard wrote: >> Christian Inci <chris.wine(a)broke-the-inter.net> writes: >> >>> +static void test_thread_debug_registers(void) >>> +{ >>> + HANDLE thread; >>> + CONTEXT ctx; >>> + NTSTATUS status; >>> + >>> + ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS; >>> + ctx.Dr0 = 0xffffffff; >>> + ctx.Dr1 = 0xffffffff; >>> + ctx.Dr2 = 0xffffffff; >>> + ctx.Dr3 = 0xffffffff; >>> + ctx.Dr6 = 0xffffffff; >>> + ctx.Dr7 = 0xffffffff; >>> + status = pNtSetContextThread(GetCurrentThread(), &ctx); >>> + todo_wine ok(status == STATUS_SUCCESS, "NtSetContextThread failed with %x\n", status); >> >> It would be a more convincing test if setting the context succeeded. The >> failure is of course interesting too, but that could be a separate test. >>

1 0

Re: [PATCH v4 4/4] user32/tests: Fix an intermittent failure. (resend)
by Marvin April 7, 2017

April 7, 2017

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=30041 Your paranoid android. === w7u (32 bit msg) === msg.c:12062: Test failed: WmMouseHoverSeq: 0: the msg sequence is not complete: expected 0118 - actual 0000 msg.c:12064: Test failed: wrong tme.dwFlags 00000001, expected 00000000 msg.c:12064: Test failed: wrong tme.hwndTrack 0018017E, expected 00000000 msg.c:12064: Test failed: wrong tme.dwHoverTime 400, expected 0 === w7pro64 (32 bit msg) === msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 4: in msg 0x0047 expecting wParam 0x8170 got 0x1803 msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 5: the msg 0x0003 was expected, but got msg 0x0047 instead msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 6: the msg 0x0005 was expected, but got msg 0x0003 instead msg.c:12609: Test failed: 54: ShowWindow(SW_MINIMIZE): 7: the msg sequence is not complete: expected 0000 - actual 0005

1 0

Re: [PATCH] tools/winedump: Change duplicate flag.
by Austin English April 7, 2017

April 7, 2017

On Apr 7, 2017 2:22 PM, "Zebediah Figura" <z.figura12(a)gmail.com> wrote: On 04/07/2017 02:09 PM, Alexandre Julliard wrote: > Zebediah Figura <z.figura12(a)gmail.com> writes: > >> diff --git a/tools/winedump/main.c b/tools/winedump/main.c >> index a4ebb43..5c683f6 100644 >> --- a/tools/winedump/main.c >> +++ b/tools/winedump/main.c >> @@ -226,7 +226,7 @@ static const struct my_option option_table[] = { >> {"-v", SPEC, 0, do_verbose, "-v Show lots of detail while working (verbose)."}, >> {"dump", DUMP, 0, do_dump, "dump <file> Dump the contents of 'file' (dll, exe, lib...)"}, >> {"-C", DUMP, 0, do_symdmngl, "-C Turn on symbol demangling"}, >> - {"-f", DUMP, 0, do_dumphead, "-f Dump file header information"}, >> + {"-F", DUMP, 0, do_dumphead, "-F Dump file header information"}, > > Not a big deal, but is there a reason for changing this? > The -f flag is assigned to two different options, yielding this one unreachable. Please also update the manpage. Thanks for catching this!

1 0

Re: [PATCH 1/2 v2] ntdll/tests: Check debug registers of a newly created thread
by Alexandre Julliard April 7, 2017

April 7, 2017

Christian Inci <chris.wine(a)broke-the-inter.net> writes: > +static void test_thread_debug_registers(void) > +{ > + HANDLE thread; > + CONTEXT ctx; > + NTSTATUS status; > + > + ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS; > + ctx.Dr0 = 0xffffffff; > + ctx.Dr1 = 0xffffffff; > + ctx.Dr2 = 0xffffffff; > + ctx.Dr3 = 0xffffffff; > + ctx.Dr6 = 0xffffffff; > + ctx.Dr7 = 0xffffffff; > + status = pNtSetContextThread(GetCurrentThread(), &ctx); > + todo_wine ok(status == STATUS_SUCCESS, "NtSetContextThread failed with %x\n", status); It would be a more convincing test if setting the context succeeded. The failure is of course interesting too, but that could be a separate test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] regedit: Correctly handle the importing of DWORD strings that are followed by a comment
by Alexandre Julliard April 7, 2017

April 7, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/regproc.c | 29 ++++++++++++++++++++++++----- > programs/regedit/tests/regedit.c | 4 ++-- > 2 files changed, 26 insertions(+), 7 deletions(-) > > diff --git a/programs/regedit/regproc.c b/programs/regedit/regproc.c > index e0049c6..c8149f5 100644 > --- a/programs/regedit/regproc.c > +++ b/programs/regedit/regproc.c > @@ -146,15 +146,34 @@ static char* GetMultiByteStringN(const WCHAR* strW, int chars, DWORD* len) > */ > static BOOL convertHexToDWord(WCHAR* str, DWORD *dw) > { > - char buf[9]; > + char *buf; > char dummy; > + BOOL ret = TRUE; > > - WideCharToMultiByte(CP_ACP, 0, str, -1, buf, 9, NULL, NULL); > - if (lstrlenW(str) > 8 || sscanf(buf, "%x%c", dw, &dummy) != 1) { > + buf = GetMultiByteString(str); > + if (!buf) return FALSE; > + > + if (strlen(buf) > 8) /* Look for any characters after the DWORD string */ > + { > + char *p = buf + 8; > + > + while (*p == ' ' || *p == '\t') p++; > + if (*p != ';') > + { > + HeapFree(GetProcessHeap(), 0, buf); > + return FALSE; > + } > + buf[8] = 0; > + } > + > + if (sscanf(buf, "%x%c", dw, &dummy) != 1) > + { > output_message(STRING_INVALID_HEX); > - return FALSE; > + ret = FALSE; > } It may be a good idea to write tests for dwords with different numbers of digits, it's not clear to me that this would be doing the right thing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/8] server: Pass async_data_t as varargs in write request.
by Jacek Caban April 7, 2017

April 7, 2017

On 06.04.2017 17:58, Jacek Caban wrote: > This is needed for later patch that adds APCs to async_data_t, causing > request to exceed allowed size. Having second thoughts about it, I think there is a solution that doesn't require changing async_data_t size. We could require that the first field of callback argument is a pointer to callback. This way we could have just one pointer for callback and its argument, saving space for APC in async_data_t. Please let me know if that would be preferred. Thanks, Jacek

2 1

Re: [PATCH] odbccp32: Implement SQLConfigDriver/W
by Huw Davies April 7, 2017

April 7, 2017

On Fri, Apr 07, 2017 at 12:48:17AM +0000, Alistair Leslie-Hughes wrote: > v2 - Use worker function to load DLL > - Correctly set error when required. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/odbccp32/odbccp32.c | 115 ++++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 105 insertions(+), 10 deletions(-) > > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index 773c5d2..041170a 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -62,6 +62,12 @@ static const WCHAR odbc_error_component_not_found[] = {'C','o','m','p','o','n',' > static const WCHAR odbc_error_out_of_mem[] = {'O','u','t',' ','o','f',' ','m','e','m','o','r','y',0}; > static const WCHAR odbc_error_invalid_param_sequence[] = {'I','n','v','a','l','i','d',' ','p','a','r','a','m','e','t','e','r',' ','s','e','q','u','e','n','c','e',0}; > static const WCHAR odbc_error_invalid_param_string[] = {'I','n','v','a','l','i','d',' ','p','a','r','a','m','e','t','e','r',' ','s','t','r','i','n','g',0}; > +static const WCHAR odbc_error_invalid_dsn[] = {'I','n','v','a','l','i','d',' ','D','S','N',0}; > +static const WCHAR odbc_error_load_lib_failed[] = {'L','o','a','d',' ','L','i','b','r','a','r','y',' ','F','a','i','l','e','d',0}; > +static const WCHAR odbc_error_request_failed[] = {'R','e','q','u','e','s','t',' ','F','a','i','l','e','d',0}; > + > +static BOOL (WINAPI *pConfigDriverW)(HWND hwnd, WORD request, const WCHAR *driver, const WCHAR *args, const WCHAR *msg, WORD msgmax, WORD *msgout); > +static BOOL (WINAPI *pConfigDriverA)(HWND hwnd, WORD request, const char *driver, const char *args, const char *msg, WORD msgmax, WORD *msgout); Is there a reason why pConfigDriverA/W are not local variables? Huw.

1 0

Re: [PATCH 2/2] wmvcore: Add WMReader stubs
by Nikolay Sivov April 7, 2017

April 7, 2017

On 07.04.2017 6:51, Jefferson Carpenter wrote: > Adds interfaces used by IMesh in bug 42416, except for these: > > 5c938aeb-6378-479e-bfd5-eafba63dc6e9 > 7af7d5ed-4ef9-48da-a4b6-8ea7eb38f5cc > --- > dlls/wmvcore/wmvcore_main.c | 1301 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 1301 insertions(+) > Hi, this is too much for a single patch. Please split it up and add some tests that shows such interfaces are actually supported. To add tests create a 'tests' directory, Makefile.in in it, and wmvcore.c (file name could be different), where you place tests. You'll have to modify configure.ac to add WINE_CONFIG_TEST line in it. If you need to link to wmvcore.dll from your test, you'll need to modify WINE_CONFIG_DLL too, to include implib directive.

2 1

Re: shell32: Fix the 'OK' button is always gray when call SHBrowseForFolder with flags BIF_BROWSEFORCOMPUTER and BIF_RETURNONLYFSDIRS (try 2)
by Xu Wenlong April 7, 2017

April 7, 2017

------------------ Original ------------------ From: "Marvin"<testbot(a)winehq.org>; Date: Fri, Apr 7, 2017 04:05 AM To: "Xu Wenlong"<xuwenlong(a)deepin.com>; Subject: Re: shell32: Fix the 'OK' button is always gray when call SHBrowseForFolder with flags BIF_BROWSEFORCOMPUTER and BIF_RETURNONLYFSDIRS (try 2) Thank you for your contribution to Wine! This is an automated notification to let you know that your patch has been reviewed and its status set to "No patch". This means that no patch was found in your mail. If you do not understand the reason for this status, disagree with our assessment, or are simply not sure how to proceed next, please ask for clarification by replying to this email.

1 0

Mailing List Issues
by Jeremy Newman April 6, 2017

April 6, 2017

We have been having issues with bounces and people getting removed from the list subscriptions as of late. It seems to mostly affect Gmail users, but some others have been getting kicked as well. Gmail is getting particularly picky about valid mail headers. I'm looking into ways of preventing this from happening. I've done the following to prevent further issues: * Raise the bounce threshold in mailman to 10.0 * Add SPF record to DNS * Add DMARC policy to DNS * Add DKIM key signing to all outbound mail, and matching key in DNS We also have been hitting our bandwidth threshold at our co-lo. When this happens they start to drop packets on us as a form of throttling. This always happens when I do a full CDN flush. As this really chews up the bits when the mirrors re-sync. To prevent that, we now have a background process watching for changed files on our master, and only changes will be flushed. If you notice any further issues, or have suggestions, let me know. Thanks. -N

1 0

Re: [PATCH 2/2] odbccp32: Implement SQLRemoveTranslator/W
by Huw Davies April 6, 2017

April 6, 2017

On Wed, Apr 05, 2017 at 09:51:15AM +0000, Alistair Leslie-Hughes wrote: > v3 - Fix trace message. > v4 - Fixed assignment of usage_count > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/odbccp32/odbccp32.c | 69 +++++++++++++++++++++++++++++++++++++++++----- > dlls/odbccp32/tests/misc.c | 8 +++--- > 2 files changed, 66 insertions(+), 11 deletions(-) > > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index 7b2f020bbe..161f2c2bd2 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -1229,20 +1229,75 @@ BOOL WINAPI SQLRemoveDSNFromIni(LPCSTR lpszDSN) > return FALSE; > } > > -BOOL WINAPI SQLRemoveTranslatorW(LPCWSTR lpszTranslator, LPDWORD lpdwUsageCount) > +BOOL WINAPI SQLRemoveTranslatorW(const WCHAR *translator, DWORD *usage_count) > { > + HKEY hkey; > + DWORD usagecount = 1; > + > clear_errors(); > - FIXME("%s %p\n", debugstr_w(lpszTranslator), lpdwUsageCount); > - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > - return FALSE; > + TRACE("%s %p\n", debugstr_w(translator), usage_count); > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, odbcini, &hkey) == ERROR_SUCCESS) > + { > + HKEY hkeydriver; > + > + if (RegOpenKeyW(hkey, translator, &hkeydriver) == ERROR_SUCCESS) > + { > + DWORD size, type; > + DWORD count; > + > + size = sizeof(usagecount); > + RegGetValueA(hkeydriver, NULL, "UsageCount", RRF_RT_DWORD, &type, &usagecount, &size); > + TRACE("Usage count %d\n", usagecount); > + count = usagecount - 1; > + if (count) > + { > + if (RegSetValueExA(hkeydriver, "UsageCount", 0, REG_DWORD, (BYTE*)&count, sizeof(count)) != ERROR_SUCCESS) > + ERR("Failed to write registry UsageCount key\n"); > + } > + > + RegCloseKey(hkeydriver); > + } > + > + if (usagecount) > + usagecount--; > + > + if (!usagecount) > + { > + if(RegDeleteKeyW(hkey, translator) != ERROR_SUCCESS) > + ERR("Failed to delete registry key: %s\n", debugstr_w(translator)); > + > + if (RegOpenKeyW(hkey, odbctranslators, &hkeydriver) == ERROR_SUCCESS) > + { > + if(RegDeleteValueW(hkeydriver, translator) != ERROR_SUCCESS) > + ERR("Failed to delete registry value: %s\n", debugstr_w(translator)); > + > + RegCloseKey(hkeydriver); > + } > + } > + > + RegCloseKey(hkey); > + } > + > + if (usage_count) > + *usage_count = usagecount; > + > + return TRUE; > } Sorry, I've just noticed that this returns TRUE even if the requested translator isn't installed, which is not correct. A test for that would be good too. Huw.

1 0

Re: gdi32: Change default interface font to Gothic typeface for CJK.
by Akihiro Sagawa April 6, 2017

April 6, 2017

> On Tue, Apr 04, 2017 at 11:25:18PM +0800, Jactry Zeng wrote: > > This patch changes default interface typeface of CJK from Mincho font to > > Gothic font. > > Windows had made this change since Windows Vista. macOS and most of Linux > > distros are using Gothic typeface by default for CJK, too. > > This seems to be confirmed by the great oracle of truth that is Wikipedia. > > Signed-off-by: Huw Davies <huw(a)codeweavers.com> I'm not sure about this. On my Japanese Windows 7, MS Shell Dlg points to MS UI Gothic, not Meiryo. If I remember correctly, it also points to legacy Mincho font in Chinese/Korean environment. I'm afraid that this change also affects dialog base units (e.g. GetDialogBaseUnits). A lot of application dialogs depend on default font's dialog units. Though Windows 7 introduces new type faces, we should use legacy font face in GDI for that reason. Instead of MS Shell Dlg, how about using "MS Shell Dlg 2" for system dialog windows? Regards, Akihiro Sagawa

3 3

Re: [PATCH 2/6] comctl32/tests: Test messages sent to the pager child.
by Nikolay Sivov April 5, 2017

April 5, 2017

On 05.04.2017 10:15, Stefan Dösinger wrote: > --- > dlls/comctl32/tests/msg.h | 19 ++++++++++-- > dlls/comctl32/tests/pager.c | 70 ++++++++++++++++++++++++++++++++++++++++++--- > 2 files changed, 83 insertions(+), 6 deletions(-) > > diff --git a/dlls/comctl32/tests/msg.h b/dlls/comctl32/tests/msg.h > index b30b5d8..a3c789b 100644 > --- a/dlls/comctl32/tests/msg.h > +++ b/dlls/comctl32/tests/msg.h > @@ -39,7 +39,8 @@ typedef enum > hook = 0x100, > winevent_hook =0x200, > id = 0x400, > - custdraw = 0x800 > + custdraw = 0x800, > + child1 = 0x1000, > } msg_flags_t; > Maybe I don't see a full picture yet, but doesn't this duplicate 'id' flag? We use it for ListView/Header combined sequences for example. > struct message > @@ -182,6 +183,8 @@ static void ok_sequence_(struct msg_sequence **seq, int sequence_index, > { > if (expected->message == actual->message) > { > + const char *expected_win = NULL; > + > if (expected->flags & wparam) > { > if (expected->wParam != actual->wParam && todo) > @@ -304,11 +307,23 @@ static void ok_sequence_(struct msg_sequence **seq, int sequence_index, > context, expected->message, (expected->flags & posted) ? "posted" : "sent"); > if ((expected->flags & (sent|posted)) != (actual->flags & (sent|posted))) dump++; > > + if (expected->flags & parent) > + expected_win = "parent"; > + else if (expected->flags & child1) > + expected_win = "child 1"; > + else > + expected_win = "pager"; This has to be generic, something neutral like "control" instead of "pager" is better, if we'll end up using new flag.

2 2

Re: [PATCH 1/4] regedit: Concatenate the next line when a comment follows the backslash
by Alexandre Julliard April 5, 2017

April 5, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -715,7 +715,7 @@ static char *get_lineA(FILE *fp) > > while (next) > { > - char *p = strpbrk(line, "\r\n"); > + char *p = strpbrk(line, "\r\n"), *s; > if (!p) > { > size_t len, count; > @@ -741,10 +741,11 @@ static char *get_lineA(FILE *fp) > next = p + 1; > if (*p == '\r' && *(p + 1) == '\n') next++; > *p = 0; > - if (p > buf && *(p - 1) == '\\') > + if ((s = strchr(line, ':')) && (*(s - 1) == 'x' || *(s - 1) == ')')) > { > - while (*next == ' ' || *next == '\t') next++; > - memmove(p - 1, next, strlen(next) + 1); > + s = strchr(s, '\\'); > + if (!s) return line; > + memmove(s, next, strlen(next) + 1); This looks wrong. I assume it's meant to check for hex() and the like, but this would have to be done in the parser, not in the line reading code. There could just as well be a "hex:" inside a value string for instance. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] wined3d: Store render target info instead of surfaces in "blit_targets".
by Henri Verbeet April 5, 2017

April 5, 2017

On 5 April 2017 at 15:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -2678,17 +2713,17 @@ BOOL context_apply_clear_state(struct wined3d_context *context, const struct win > > if (!rt_count || wined3d_resource_is_offscreen(rts[0]->resource)) > { > + memset(context->blit_targets, 0, gl_info->limits.buffers * sizeof(context->blit_targets)); Is that sizeof missing a '*'?

1 0

Re: [PATCH 1/6] comctl32/tests: Don't dump successful sequences on Windows.
by Nikolay Sivov April 5, 2017

April 5, 2017

On 05.04.2017 10:15, Stefan Dösinger wrote: > --- > dlls/comctl32/tests/msg.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/comctl32/tests/msg.h b/dlls/comctl32/tests/msg.h > index 3fa0fae..b30b5d8 100644 > --- a/dlls/comctl32/tests/msg.h > +++ b/dlls/comctl32/tests/msg.h > @@ -369,7 +369,7 @@ static void ok_sequence_(struct msg_sequence **seq, int sequence_index, > context, expected->message, actual->message); > } > > - if(todo && !failcount) /* succeeded yet marked todo */ > + if(todo && !failcount && !broken(TRUE)) /* succeeded yet marked todo */ > { > dump++; > todo_wine > This patch is marked is failed by testbot, but it looks like bot inability to deal with header file change in tests directory, as it still tries to run some tests. Anyway, could you make it look similar to user32/tests/msg.c? It's using: --- if( todo && !failcount) /* succeeded yet marked todo */ todo_wine { if (!strcmp(winetest_platform, "wine")) dump++; --- Platform is tested directly. It's not the only place where it's done like that, and it's more readable than broken(1), I think.

3 2

Re: [PATCH 2/4] ws2_32/tests: Added WSARecv tests using completion function.
by Marvin April 5, 2017

April 5, 2017

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=29976 Your paranoid android. === w2008s64 (64 bit sock) === sock.c:6817: Test failed: got 0

1 0