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 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=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