On 31-07-2017 18:50, Alexandre Julliard wrote:
Carlos Palminha [email protected] writes:
On 31-07-2017 17:54, Alexandre Julliard wrote:
Carlos Palminha [email protected] 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
Carlos Palminha [email protected] 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.
On 31-07-2017 19:56, Alexandre Julliard wrote:
Carlos Palminha [email protected] 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.
i thought on that but it seems wine_kernel_init and SearchPathW are also using it. Do you think its acceptable for these functions to call dll_load_path with the SEARCH flags?
Regards, C.Palminha
Carlos Palminha [email protected] writes:
On 31-07-2017 19:56, Alexandre Julliard wrote:
Carlos Palminha [email protected] 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.
i thought on that but it seems wine_kernel_init and SearchPathW are also using it. Do you think its acceptable for these functions to call dll_load_path with the SEARCH flags?
That should be fine.