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

Re: [4/6] secur32: Return PRF algorithm value when using GCM. (resend)

by Bruno Jesus

On Fri, Apr 28, 2017 at 5:21 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 4/28/17 2:19 AM, Bruno Jesus wrote: > >> On Thu, Apr 27, 2017 at 8:27 PM, Michael Müller <michael(a)fds-team.de> >> wrote: >>> >>> This patch broke the compilation on Debian Wheezy and Ubuntu Trusty: >>> >>> schannel_gnutls.c: In function schannel_get_mac_algid: >>> schannel_gnutls.c:329:10: error: ‘GNUTLS_MAC_AEAD undeclared (first use >>> in this function) >>> schannel_gnutls.c:329:10: note: each undeclared identifier is reported >>> only once for each function it appears in >>> >>> Build overview: https://dev.wine-staging.com/builder/group/60/ (Click >>> Downloads for build logs) >>> Debian Wheezy build log: >>> https://builds.wine-staging.com/2017-04-27-21-23-02-job-10597/build.log >> >> PC-BSD 9 broke too, same error. > > > Please verify that the attached patch fixes the problem. Yes, it fixes the problem. Thanks, Bruno

April 28, 2017

Re: [PATCH 4/4] dmloader/tests: Add some IDirectMusicLoader directory tests.

by Sebastian Lackner

On 27.04.2017 19:15, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)winehq.org> > --- > dlls/dmloader/tests/loader.c | 41 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 41 insertions(+) > Your patch introduced a bunch of test failures here: loader.c:69: Test succeeded inside todo block: SetSearchDirectory failed with 0 loader.c:71: Test failed: Second SetSearchDirectory failed with 0 loader.c:73: Test failed: SetSearchDirectory failed with 0x1

April 28, 2017

Re: [PATCH 4/4] mfplat/tests: Add tests.

by Andrew Eikum

On Fri, Apr 28, 2017 at 04:29:07AM +0000, Alistair Leslie-Hughes wrote: > +static void test_register(void) > +{ > + static WCHAR name[] = {'W','i','n','e',' ','t','e','s','t',0}; > + MFT_REGISTER_TYPE_INFO input; > + MFT_REGISTER_TYPE_INFO output; > + CLSID *clsids; > + UINT32 count; > + HRESULT ret; > + > + memcpy(&input.guidMajorType, &DUMMY_GUID1, sizeof(GUID)); > + memcpy(&input.guidMajorType, &DUMMY_GUID2, sizeof(GUID)); > + memcpy(&output.guidSubtype, &DUMMY_GUID1, sizeof(GUID)); > + memcpy(&output.guidSubtype, &DUMMY_GUID3, sizeof(GUID)); > + Looks like some copy-paste errors here. Andrew

April 28, 2017

Re: [v6 PATCH 05/21] x86/insn-eval: Add utility functions to get register offsets

by Borislav Petkov

On Wed, Apr 26, 2017 at 11:13:44AM -0700, Ricardo Neri wrote: > Masami Hiramatsu had originally requested to add the two functions. I > suppose the unneeded functions could be added if/when needed. Yap, exactly. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --

April 28, 2017

Re: ntdll: Use environment variable "WINESERVER" first on search for wineserver to start.

by Ralf Habacker

Am 27.03.2017 um 08:25 schrieb Ralf Habacker: > [...] >>> With the mentioned patch applied to a local wine build (or with a >>> renamed wineserver) the site now runs about two weeks and one noticable >>> change is that the initial >>> mentioned communication issue did not happens. This let me think that >>> there may be a long time running issue with wineserver, which affects >>> the dde interface. >> It is nice that you have found a workaround, however we would also like >> to fix such issues of course. If you find any way to trigger this issue, >> please file a bug report. > I will do but unfortunally I'm not at this point yet. Observations from > the last weeks shows that the error happened two times: > > 1. wineserver is running 12 days and not restarted because one > application showed a message box, therefore did not quit and blocked > wineserver restart, which let other wine applications dde communication fail 3. Yesterday we had a similar issue: dde communication of newly started applications fails after wineserver was running about 9 days because wineserver restart has been blocked by a still running application. Currently it is not possible to say what happens in that incubation period and why it does affect dde comunication. We can only say that the main windows application (the engine which generates the graphics print out) has been started about 5000 times in the last ten days and the windows remote control application which uses dde to communicate with the main application runs between 10 and 356 times for each print out. This indicates that any long time usage of a wine application for example as server backend using dde may have similar issues. Would it be possible to restart wineserver although applications are still running ? > 2. wineserver is running 3 days and applications dde communications > fails because wineserver has been restarted immediatly > ... > applications dde communication fails and wine reports > wine: chdir to /tmp/.wine-37002/server-fd0a-9602c failed: no such file or directory The related part is located in server_connect() (see https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/server.c#l1210) 1210 setup_config_dir(); 1211 serverdir = wine_get_server_dir(); 1212 1213 /* chdir to the server directory */ 1214 if (chdir( serverdir ) == -1) 1215 { 1216 if (errno != ENOENT) fatal_perror( "chdir to %s", serverdir ); 1217 start_server(); 1218 if (chdir( serverdir ) == -1) fatal_perror( "chdir to %s", serverdir ); 1219 } Guessing from the error message "no such file or directory" I would say that the error happens in line 1218, which indicates that the server could not be started Any ideas what could happen here ? Ralf

April 28, 2017

Re: [1/5] wsdapi: Implement WSD LinkedMemory functions [try 2]

by Alexandre Julliard

Owen Rudge <orudge(a)codeweavers.com> writes: > +struct memory_allocation > +{ > + struct list entry; > + void *ptr; > + > + struct list children; > +}; > + > +static struct list memory_allocations = LIST_INIT(memory_allocations); > + > +static struct memory_allocation *find_allocation(struct list *searchList, void *parent) > +{ > + struct memory_allocation *allocation, *childAllocation; > + > + LIST_FOR_EACH_ENTRY(allocation, searchList, struct memory_allocation, entry) > + { > + if (allocation->ptr == parent) > + { > + return allocation; > + } > + > + /* Search the children */ > + childAllocation = find_allocation(&allocation->children, parent); > + > + if (childAllocation != NULL) > + { > + return childAllocation; > + } > + } > + > + return NULL; > +} You should probably store the child list at the start of the allocated block or something like that, you don't want to go through the entire list on every operation. -- Alexandre Julliard julliard(a)winehq.org

April 28, 2017

Re: [4/6] secur32: Return PRF algorithm value when using GCM. (resend)

by Jacek Caban

On 4/28/17 2:19 AM, Bruno Jesus wrote: > On Thu, Apr 27, 2017 at 8:27 PM, Michael Müller <michael(a)fds-team.de> wrote: >> This patch broke the compilation on Debian Wheezy and Ubuntu Trusty: >> >> schannel_gnutls.c: In function schannel_get_mac_algid: >> schannel_gnutls.c:329:10: error: ‘GNUTLS_MAC_AEAD undeclared (first use in this function) >> schannel_gnutls.c:329:10: note: each undeclared identifier is reported only once for each function it appears in >> >> Build overview: https://dev.wine-staging.com/builder/group/60/ (Click Downloads for build logs) >> Debian Wheezy build log: https://builds.wine-staging.com/2017-04-27-21-23-02-job-10597/build.log > PC-BSD 9 broke too, same error. Please verify that the attached patch fixes the problem. Thanks, Jacek

April 28, 2017

Re: [PATCH 4/4] mfplat/tests: Add tests.

by Nikolay Sivov

On 28.04.2017 7:29, Alistair Leslie-Hughes wrote: > +BOOL init_function_ptrs(void) > +{ > + HMODULE mfplat = LoadLibraryA("mfplat.dll"); > + if (!mfplat) > + { > + win_skip("Could not load mfplat.dll\n"); > + return FALSE; > + } > + > + #define LOAD_FUNCPTR(f) p##f = (void*)GetProcAddress(mfplat, #f) > + LOAD_FUNCPTR(MFTEnum); > + LOAD_FUNCPTR(MFTRegister); > + LOAD_FUNCPTR(MFTUnregister); > + #undef LOAD_FUNCPTR > + > + return TRUE; > +} This looks redundant, why is it not statically linked?

April 28, 2017

Re: [PATCH 3/4] mfplat: Implement MFTEnum.

by Nikolay Sivov

On 28.04.2017 7:28, Alistair Leslie-Hughes wrote: > + for (i = 0; i < size / sizeof(GUID); i += 2) > + { > + if (!memcmp(&guids[i], &type->guidMajorType, sizeof(GUID)) && > + !memcmp(&guids[i+1], &type->guidSubtype, sizeof(GUID))) > + { > + ret = TRUE; > + break; > + } > + } IsEqualGUID could be used instead. > +HRESULT WINAPI MFTEnum(GUID category, UINT32 flags, MFT_REGISTER_TYPE_INFO *input_type, > + MFT_REGISTER_TYPE_INFO *output_type, IMFAttributes *attributes, > + CLSID **pclsids, UINT32 *pcount) I think it's better to print a fixme for non-zero flags and attributes, and use TRACE otherwise. > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, categories_keyW, &hcategory)) > + return E_FAIL; > + > + GUIDToString(buffer, &category); > + > + ret = RegOpenKeyW(hcategory, buffer, &hlist); > + RegCloseKey(hcategory); > + if (ret) return E_FAIL; This probably could be replaced with a single RegOpenKeyW(). > + PVOID tmp; Why void*?

April 28, 2017

Re: [PATCH 2/4] mfplat: Implement MFTUnregister.

by Nikolay Sivov

On 28.04.2017 7:28, Alistair Leslie-Hughes wrote: > + FIXME("(%s)\n", debugstr_guid(&clsid)); Same, why fixme?

April 28, 2017