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

Re: [2/6] wsdapi: Add code to create SOAP envelope from header and body elements.

by Vincent Povirk

>> Do we need the namespace for SequenceID? > > The namespace needs to be passed in, but it won't appear in the generated > message, as per: > > https://msdn.microsoft.com/en-us/library/windows/desktop/bb513682(v=vs.85).… Is there something special about SequenceId compared to InstanceId and MessageNumber?

July 31, 2017

Re: [4/6] wsdapi: Implement "Hello" message creation support.

by Owen Rudge

On 27/07/2017 22:11, Vincent Povirk wrote: > I really hope we don't have to start optimizing for fewer GetProcessHeap calls. I'll amend. :) > This doesn't account for the terminating NULL wsprintfW will add. Thanks for catching that. > + discoveredNamespaces = WSDAllocateLinkedMemory(NULL, sizeof(struct list)); > + if (!discoveredNamespaces) goto cleanup; > > Why not allocate this on the stack? The discovered namespaces (and their child strings) are linked to the parent namespace (and ultimately the discoveredNamespaces list), simplifying cleanup. Cheers, -- Owen Rudge http://www.owenrudge.net/

July 31, 2017

Re: [2/6] wsdapi: Add code to create SOAP envelope from header and body elements.

by Owen Rudge

On 28/07/2017 21:00, Vincent Povirk wrote: > This would be much simpler if you passed in -1 as the wide string > length. Using HEAP_ZERO_MEMORY to null-terminate the string is a bit > weird. I'll amend that, thanks. > I'm not sure, but I think you need to add textNode as a child of newElement? It gets added as a child of "parent" (which "newElement" is also a child of). It would be more consistent to attach it to "newElement" though, I'll change that. > Do we need the namespace for SequenceID? The namespace needs to be passed in, but it won't appear in the generated message, as per: https://msdn.microsoft.com/en-us/library/windows/desktop/bb513682(v=vs.85).… Cheers, -- Owen Rudge http://www.owenrudge.net/

July 31, 2017

Re: [PATCHv2] msvcrt: Export -f suffixed float functions functions on arm64

by Martin Storsjö

Hi Piotr, On Mon, 31 Jul 2017, Piotr Caban wrote: > Why do you need it? Is there native arm64 version of the dlls (I've seen some > announcements but is it already available)? I don't have the native arm64 version of the DLLs, but I do have corresponding import libs. The public win10 SDK (from already 2 years ago) contains arm64 import libraries. There's no publicly available MSVC compiler targeting arm64 yet though (and I don't have any private one either), but I'm working on trying to bootstrap a build/test env for win/arm64. Clang as compiler and lld as linker have gotten to the point now that they are pretty usable for building things for win/arm64, able to build pretty large real world projects - but the only environment I have for actually running the code is in wine so far. In normal app code, built with clang and linked to the public win10 sdk import libs, I'm ending up with references to fabsf in api-ms-win-crt-math-l1-1-0.dll. The part of the patch that touches msvcr80/90/100/110/120 was only done for consistency - in practice it's probably only needed for ucrtbase.dll. (Similarly the case of -arch=arm in msvcr80/90/100 for arm probably isn't necessary since there's afaik nobody referencing those on arm, but it's probably easiest to keep them for consistency - that's why I'm adding it to all of them here as well.) // Martin

July 31, 2017

Re: [PATCH] kernel32: Load library search in system32 directory.

by Alexandre Julliard

Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> writes: > I think today its working for some of those unsupported flags because it's a side effect of calling MODULE_get_dll_load_path with NULL. > Probably using only system32 path it might break some of the application that are working based on a side effect. Nevertheless i run the existing tests for module and its ok. > > I will look at it and add the other SEARCH flags. If i check the other flags then there is no need to fallback to MODULE_get_dll_load_path(NULL), do you agree? My guess is that you'd want to integrate the flags handling into MODULE_get_dll_load_path instead of bypassing it. -- Alexandre Julliard julliard(a)winehq.org

July 31, 2017

Re: [PATCH] kernel32: Load library search in system32 directory.

by Carlos Palminha

On 31-07-2017 18:50, Alexandre Julliard wrote: > Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> writes: > >> On 31-07-2017 17:54, Alexandre Julliard wrote: >>> Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> writes: >>> >>>> Hi Alexandre, >>>> >>>> I tested with iTunes installation that was crashing when calling load_libraryin my system. After the patch it was ok. Probably not enough indicator that was working properly in all systems. >>>> >>>> I will send a second version calling GetWindowsDirectory instead of using %windows%. >>>> >>>> Regarding the other cases, when using the flag >>>> LOAD_LIBRARY_SEARCH_SYSTEM32, directories in the standard search path >>>> are not searched and the value cannot be combined with >>>> LOAD_WITH_ALTERED_SEARCH_PATH. The search path is reduced to >>>> windows\system32, right? Or probably i need to append >>>> %windows&\system32 to the existing path... >>> >>> If you only specify SEARCH_SYSTEM32 the path is reduced to that, but you >>> could also have other flags like SEARCH_APPLICATION_DIR, >>> SEARCH_DLL_LOAD_DIR, etc. You can't handle just one flag and ignore the >>> others. >>> >> >> All the other cases SEARCH_APPLICATION_DIR, SEARCH_DEFAULT_DIRS, SEARCH_DLL_LOAD_DIR and SEARCH_USER_DIRS are not yet supported (unsopported flags). >> So at this moment LOAD_LIBRARY_SEARCH_* are reduced to ALTERED_SEARCH_PATH or SEARCH_SYSTEM32. > > They are not supported now, but if you add one you have to add the > others, otherwise dlls are going to fail to load because you are > searching only system32. > I think today its working for some of those unsupported flags because it's a side effect of calling MODULE_get_dll_load_path with NULL. Probably using only system32 path it might break some of the application that are working based on a side effect. Nevertheless i run the existing tests for module and its ok. I will look at it and add the other SEARCH flags. If i check the other flags then there is no need to fallback to MODULE_get_dll_load_path(NULL), do you agree? Regards, C.Palminha

July 31, 2017

Re: [PATCH] kernel32: Load library search in system32 directory.

by Carlos Palminha

On 31-07-2017 17:54, Alexandre Julliard wrote: > Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> writes: > >> Hi Alexandre, >> >> I tested with iTunes installation that was crashing when calling load_libraryin my system. After the patch it was ok. Probably not enough indicator that was working properly in all systems. >> >> I will send a second version calling GetWindowsDirectory instead of using %windows%. >> >> Regarding the other cases, when using the flag >> LOAD_LIBRARY_SEARCH_SYSTEM32, directories in the standard search path >> are not searched and the value cannot be combined with >> LOAD_WITH_ALTERED_SEARCH_PATH. The search path is reduced to >> windows\system32, right? Or probably i need to append >> %windows&\system32 to the existing path... > > If you only specify SEARCH_SYSTEM32 the path is reduced to that, but you > could also have other flags like SEARCH_APPLICATION_DIR, > SEARCH_DLL_LOAD_DIR, etc. You can't handle just one flag and ignore the > others. > All the other cases SEARCH_APPLICATION_DIR, SEARCH_DEFAULT_DIRS, SEARCH_DLL_LOAD_DIR and SEARCH_USER_DIRS are not yet supported (unsopported flags). So at this moment LOAD_LIBRARY_SEARCH_* are reduced to ALTERED_SEARCH_PATH or SEARCH_SYSTEM32. Regards, C.Palminha

July 31, 2017

Re: [PATCH] kernel32: Load library search in system32 directory.

by Alexandre Julliard

Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> writes: > Hi Alexandre, > > I tested with iTunes installation that was crashing when calling load_libraryin my system. After the patch it was ok. Probably not enough indicator that was working properly in all systems. > > I will send a second version calling GetWindowsDirectory instead of using %windows%. > > Regarding the other cases, when using the flag > LOAD_LIBRARY_SEARCH_SYSTEM32, directories in the standard search path > are not searched and the value cannot be combined with > LOAD_WITH_ALTERED_SEARCH_PATH. The search path is reduced to > windows\system32, right? Or probably i need to append > %windows&\system32 to the existing path... If you only specify SEARCH_SYSTEM32 the path is reduced to that, but you could also have other flags like SEARCH_APPLICATION_DIR, SEARCH_DLL_LOAD_DIR, etc. You can't handle just one flag and ignore the others. -- Alexandre Julliard julliard(a)winehq.org

July 31, 2017

Re: [PATCH] kernel32: Load library search in system32 directory.

by Carlos Palminha

Hi Alexandre, I tested with iTunes installation that was crashing when calling load_libraryin my system. After the patch it was ok. Probably not enough indicator that was working properly in all systems. I will send a second version calling GetWindowsDirectory instead of using %windows%. Regarding the other cases, when using the flag LOAD_LIBRARY_SEARCH_SYSTEM32, directories in the standard search path are not searched and the value cannot be combined with LOAD_WITH_ALTERED_SEARCH_PATH. The search path is reduced to windows\system32, right? Or probably i need to append %windows&\system32 to the existing path... Regards, C.Palminha On 31-07-2017 17:25, Alexandre Julliard wrote: > Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> writes: > >> Use %windows%\system32 directory to search for the DLL. >> Standard search path is not used. >> >> Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> >> --- >> dlls/kernel32/module.c | 10 ++++++++-- >> 1 file changed, 8 insertions(+), 2 deletions(-) > > %windows% cannot possibly work, environment variables are not expanded, > and even if they were, there's no such variable. How did you test this? > > Also it's possible to specify multiple flags, this needs to be > integrated properly in the code that builds the search path. >

July 31, 2017

Re: [PATCH] kernel32: Load library search in system32 directory.

by Alexandre Julliard

Carlos Palminha <CARLOS.PALMINHA(a)synopsys.com> writes: > Use %windows%\system32 directory to search for the DLL. > Standard search path is not used. > > Signed-off-by: Carlos Palminha <palminha(a)synopsys.com> > --- > dlls/kernel32/module.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) %windows% cannot possibly work, environment variables are not expanded, and even if they were, there's no such variable. How did you test this? Also it's possible to specify multiple flags, this needs to be integrated properly in the code that builds the search path. -- Alexandre Julliard julliard(a)winehq.org

July 31, 2017