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