- wine-devel - winehq.org

Linux desktop integration: Fill StartupWMClass in .desktop menu entries
by Eike Hein 21 Apr '17

21 Apr '17

Hi, I maintain the taskbar in Plasma 5 and would like to poke folks about a desktop integration pain point we (and our friends at other DEs) face with apps run via wine. Here's the relevant ticket: https://bugs.winehq.org/show_bug.cgi?id=32699 Let me give some broader context on this. Modern DEs have a swath of UX going on that relies on being able to identify the application owning a particular window in the windowing system. "Identify the application" in practice means "map the window to a .desktop file installed in the menu file system". We want to do this because: a) Many a taskbar/dock-like UI tries to form a smooth life cycle across "launcher button", "startup notification" and "window button(s)". For each of those we need to work out the app they are associated with to be able to match them up. If it fails, ugly things like co-existing task buttons or missing startup throbbers and similar happen. b) UI these days tends to prefer to load assets such as app icons via the values defined in .desktop files instead of using the window icon, to ensure consistent results (apps may load icon assets differently from the shell, leading to asset quality issues, inconsistent theming, the icon changing between the lifecycle states mentioned in 'a', etc.) Plus the Wayland windowing system we're all migrating towards currently doesn'ㅅ have window icons. c) DEs do things like track app starts/quits for things like "Most used apps" launcher lists. To match a window to a .desktop file we rely on window and process metadata. On X11, there's the WM_CLASS window property: https://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS Ideally, the second part of a X11 window's WM_CLASS matches the name of a .desktop file installed on the system. Failing that, it matches the value of StartupWMClass in that .desktop file (this is the key part I'll get back to soon). Here's some more documentation by our friends at Gnome on this standard scheme: https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased (Look for WM_CLASS / StartupWMClass.) In practice, we pull many other tricks to cope with broken meta data. We try to match things by names, we grab process command lines from /proc and check them against Exec keys in .desktop files in complicated ways, ... it's a multi-page heuristic, and other DEs (Unity via bamf, Gnome Shell via iirc ShellWindowTracker) have equivalent code. Something Gnome does that we don't do (because I think it's brittle) is to store the name of the .desktop file an app was launched with as a private window hint on the next window that comes up (which then doesn't work when the app was launched from CLI instead of shell UI). None of these things currently allow us to handle wine very well. As of now (perhaps thanks to the patch mentioned in the linked ticket), wine sets WM_CLASS to the executable name of the app, e.g. "Notepad.exe". But the .desktop files it generates don't match this by name, and they don't contain a StartupWMClass key. The process command line is the Windows-like path to the .exe, which we also can't easily match up to the complicated Exec values in wine's .desktop files. (Aside: On Wayland, there's a more modern version of this: Windows have an appid property, which should be set to a .desktop file name. I don't know what the status of Wayland support in wine is -- currently the wine clients we encounter run over Xwayland, so we're back to WM_CLASS. We hope wine will set this property correctly when the time comes, or we're happy to work with you guys to find a way to support wine.) Long story short ... could this be picked up? The goal must be to have either .desktop file names or their StartupWMClass values match whatever is set as WM_CLASS. Currently, the easiest fix would be to set StartupWMClass to the executable name set as WM_CLASS. I assume the .desktop file generator has access to this, as the .lnk file referred to by Exec should presumably contain the name of the executable to be launched. Cheers, Eike

1 0

Re: [Tools] winetest: Get rid of $gitdir.
by Francois Gouget 21 Apr '17

21 Apr '17

Actually this patch depends on the next one 'winetest/dissect: Check the build id and get its details in one Git call.' I'll resubmit them in a cleaner way. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [PATCH 1/4] regedit: Validate REG_SZ import data before processing it any further (v2)
by Alexandre Julliard 21 Apr '17

21 Apr '17

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/regproc.c | 6 ++++++ > programs/regedit/tests/regedit.c | 14 +++++++------- > 2 files changed, 13 insertions(+), 7 deletions(-) > > diff --git a/programs/regedit/regproc.c b/programs/regedit/regproc.c > index 96c4564..ccd9ebe 100644 > --- a/programs/regedit/regproc.c > +++ b/programs/regedit/regproc.c > @@ -293,6 +293,12 @@ static int REGPROC_unescape_string(WCHAR* str) > str[val_idx] = str[str_idx]; > break; > } > + } else if (str[str_idx] == '"') { > + WCHAR *p = str + str_idx + 1; > + while (*p == ' ' || *p == '\t') p++; > + if (*p && *p != ';') return 0; > + str[val_idx++] = str[str_idx]; > + break; That would work, but it seems to me that the comment check would be better in the caller, so that you can use the same code for validating value names. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] user32: add GetAutoRotationState/GetDisplayAutoRotationPreferences stubs
by Huw Davies 21 Apr '17

21 Apr '17

On Thu, Apr 20, 2017 at 05:33:15PM -0500, Austin English wrote: > diff --git a/dlls/user32/misc.c b/dlls/user32/misc.c > index fa0502e..3581235 100644 > --- a/dlls/user32/misc.c > +++ b/dlls/user32/misc.c > @@ -910,3 +910,24 @@ LRESULT WINAPI ImeWndProcW( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam ) > > return DefWindowProcW(hwnd, msg, wParam, lParam); > } > + > +/********************************************************************** > + * GetAutoRotationState [USER32.@] > + */ > +BOOL WINAPI GetAutoRotationState( AR_STATE *state ) > +{ > + *state = AR_NOT_SUPPORTED; > + FIXME("(%p): stub\n", state); > + return TRUE; > +} > + I think these would be better in sysparams.c. I realise that there are already functions of this nature in misc.c - they could probably be moved across too. User32 does indeed have some odd 'misc' like functions, but these aren't them. Also, we'd generally put the FIXME() at the start of the function, not after the assignment. Apart from that, this looks good to me. Huw.

1 0

shell32: Solve the problem about 'OK' button is always gray when call SHBrowseForFolder with flags including both BIF_BROWSEFORCOMPUTER and BIF_RETURNONLYFSDIRS
by 许文龙 20 Apr '17

20 Apr '17

shell32: Solve the problem about 'OK' button is always gray when call SHBrowseForFolder with flags including both BIF_BROWSEFORCOMPUTER and BIF_RETURNONLYFSDIRS

2 1

Re: [05/10] webservices: Add support for outgoing TCP connections.
by Alexandre Julliard 20 Apr '17

20 Apr '17

Hans Leidekker <hans(a)codeweavers.com> writes: > Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> > --- > dlls/webservices/channel.c | 286 ++++++++++++++++++++++++++------- > dlls/webservices/listener.c | 16 +- > dlls/webservices/webservices_private.h | 5 + > 3 files changed, 240 insertions(+), 67 deletions(-) This breaks the Android build: x86_64-linux-android-gcc -m64 -c -o proxy.o ../../../wine/dlls/webservices/proxy.c -I. -I../../../wine/dlls/webservices \ -I../../include -I../../../wine/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-2 -gstrict-dwarf -g -O2 -fno-diagnostics-show-caret In file included from ../../../wine/dlls/webservices/webservices_private.h:19:0, from ../../../wine/dlls/webservices/proxy.c:29: ../../../wine/include/ws2tcpip.h:57:16: error: conflicting types for 'socklen_t' ../../../wine/include/ws2tcpip.h:29:18: note: in definition of macro 'WS' In file included from /home/julliard/wine/build/toolchain-android-x86_64/sysroot/usr/include/stdio.h:50:0, from ../../../wine/dlls/webservices/proxy.c:19: /home/julliard/wine/build/toolchain-android-x86_64/sysroot/usr/include/sys/types.h:127:21: note: previous declaration of 'socklen_t' was here -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v3 PATCH 2/2] wined3d: Update only dirty regions in wined3d_device_update_texture().
by Marvin 20 Apr '17

20 Apr '17

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=30284 Your paranoid android. === w864 (64 bit visual) === visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8096: Test failed: Got unexpected color 0x00000080 for no color attribute test. === w1064 (64 bit visual) === visual.c:8096: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [v3 PATCH 1/2] wined3d: Add dirty region tracking.
by Marvin 20 Apr '17

20 Apr '17

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=30282 Your paranoid android. === w864 (64 bit visual) === visual.c:8096: Test failed: Got unexpected color 0x00ff0000 for no color attribute test.

1 0

Re: [PATCH] mfplat: Implement MFCreateAttributes
by Nikolay Sivov 20 Apr '17

20 Apr '17

On 04/20/2017 10:44 AM, Alistair Leslie-Hughes wrote: > +{ > + mfattributes *This = impl_from_IMFAttributes(iface); > + > + if(IsEqualGUID(riid, &IID_IUnknown) || > + IsEqualGUID(riid, &IID_IMFAttributes)) > + { > + TRACE("(IID_IUnknown %p)\n", object); > + *object = This; > + } > + else > + { > + FIXME("(%s, %p)\n", debugstr_guid(riid), object); > + *object = NULL; > + return E_NOINTERFACE; > + } > + > + IUnknown_AddRef((IUnknown*)*object); > + return S_OK; > +} Please add a regular TRACE for this method, and return iface or interface pointer from This, instead of This itself. Trace you have now is inaccurate. > +HRESULT WINAPI MFCreateAttributes(IMFAttributes **attributes, UINT32 size) > +{ > + mfattributes *object; > + > + TRACE("%p, %d\n", attributes, size); > + > + object = HeapAlloc( GetProcessHeap(), 0, sizeof(*attributes) ); > + if(!object) > + return E_OUTOFMEMORY; This should use sizeof(*object).

2 1

Re: [v2 PATCH] mfplat: Implement MFCreateAttributes
by Dmitry Timoshkov 20 Apr '17

20 Apr '17

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > +typedef struct _mfattributes > +{ > + IMFAttributes IMFAttributes_iface; > + LONG ref; > +} mfattributes; Please try to exchange these two lines in the structure above and see what happens. -- Dmitry.

1 0

Review | endproc.c: Implement ProcessPage_OnEndProcessTree
by Akarsha Sehwag 19 Apr '17

19 Apr '17

Hi Could someone take out a little time to review the code once? Bug I intend to solve: https://bugs.winehq.org/show_bug.cgi?id=39640 I am new to wine. So, I would appreciate suggestions regarding my coding style if that's not-so-perfect according to wine standards. Or any other problems with the code I have written. I apologize for submitting an untested code earlier. I hope now it works fine. /*-------------------------------------------CODE--------------------------------------------------*/ typedef struct process_list { DWORD *pid; /*dynamic array to store the process IDs*/ SIZE_T count; /*index to maintain the last entry of the array;*/ SIZE_T size; /*the current size of the pid array*/ } process_list; 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, list->size * sizeof(list->pid)); list->count = 0; } static void increase_list_size(process_list *list) { list->size *= 2; list->pid = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, list->pid, list->size * sizeof(list->pid)); *//DOUBT: *Would sizeof(list->pid) be better or sizeof(int)? //Since in the former case, since list->pid is actually a pointer to DWORD, so //sizeof(list->pid) would return 8 bytes and not 4 bytes. } static void process_list_append(process_list *list, DWORD id) { if(list->count == list->size) increase_list_size(list); list->pid[list->count] = id; list->count += 1; } static void free_process_list(process_list *list) { HeapFree(GetProcessHeap(), 0, list->pid); } static void enum_process_children(HANDLE snapshot, process_list *list, DWORD pid) { PROCESSENTRY32 entry; SIZE_T start, end, i ; start = list->count; entry.dwSize = sizeof(entry); 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]); } } void ProcessPage_OnEndProcessTree(void) { {...} process_list list; SIZE_T i; HANDLE snapshot; {...} init_process_list(&list); if(list.pid == NULL) return; process_list_append(&list, dwProcessId); snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); if(!snapshot) return; enum_process_children(snapshot, &list, dwProcessId); CloseHandle(snapshot); for(i = 0; i < list.count; ++i) { hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, list.pid[i]); if (!hProcess) { GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); break; } if (!TerminateProcess(hProcess, 0)) { GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); MessageBoxW(hMainWnd, wstrErrorText,wszUnable2Terminate, MB_OK|MB_ICONSTOP); } CloseHandle(hProcess); } free_process_list(&list); } /*---------------------------------------END OF CODE------------------------------------------*/ Thanks and regards -- Akarsha Sehwag

1 0

Re: [2/3] wsdapi/tests: Add tests for Register/UnRegisterNotificationSink
by Nikolay Sivov 19 Apr '17

19 Apr '17

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 19 Apr '17

19 Apr '17

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 19 Apr '17

19 Apr '17

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 19 Apr '17

19 Apr '17

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 19 Apr '17

19 Apr '17

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 19 Apr '17

19 Apr '17

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 19 Apr '17

19 Apr '17

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 19 Apr '17

19 Apr '17

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 19 Apr '17

19 Apr '17

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 19 Apr '17

19 Apr '17

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 19 Apr '17

19 Apr '17

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 18 Apr '17

18 Apr '17

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 18 Apr '17

18 Apr '17

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 18 Apr '17

18 Apr '17

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 18 Apr '17

18 Apr '17

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 18 Apr '17

18 Apr '17

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 18 Apr '17

18 Apr '17

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 18 Apr '17

18 Apr '17

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 18 Apr '17

18 Apr '17

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 18 Apr '17

18 Apr '17

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 17 Apr '17

17 Apr '17

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 17 Apr '17

17 Apr '17

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 17 Apr '17

17 Apr '17

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 17 Apr '17

17 Apr '17

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

1 0

Re: localeNameToLCID
by Marvin 16 Apr '17

16 Apr '17

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 16 Apr '17

16 Apr '17

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 16 Apr '17

16 Apr '17

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 16 Apr '17

16 Apr '17

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 16 Apr '17

16 Apr '17

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 16 Apr '17

16 Apr '17

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 15 Apr '17

15 Apr '17

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 15 Apr '17

15 Apr '17

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 15 Apr '17

15 Apr '17

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 15 Apr '17

15 Apr '17

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 14 Apr '17

14 Apr '17

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 14 Apr '17

14 Apr '17

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 14 Apr '17

14 Apr '17

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 13 Apr '17

13 Apr '17

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 13 Apr '17

13 Apr '17

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel