On 14.06.2016 21:28, Alex Henrie wrote:
Cc: Piotr Caban piotr@codeweavers.com
For https://bugs.winehq.org/show_bug.cgi?id=40796
The Windows 10 SDK helpfully explains that calloc simply wraps _calloc_dbg if _DEBUG is defined and _calloc_base if _DEBUG is not defined. Since Wine will not be implementing _calloc_dbg because it is only available in debug builds of the C runtime library, we can make _calloc_base wrap calloc instead.
Signed-off-by: Alex Henrie alexhenrie24@gmail.com
dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec | 2 +- dlls/ucrtbase/ucrtbase.spec | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec b/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec index 18ca9d4..85b2b83 100644 --- a/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec +++ b/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec @@ -7,7 +7,7 @@ @ cdecl _aligned_realloc(ptr long long) ucrtbase._aligned_realloc @ stub _aligned_recalloc @ cdecl _callnewh(long) ucrtbase._callnewh -@ stub _calloc_base +@ cdecl _calloc_base(long long) ucrtbase._calloc_base @ cdecl _expand(ptr long) ucrtbase._expand @ stub _free_base @ cdecl _get_heap_handle() ucrtbase._get_heap_handle diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec index 690072b..365674b 100644 --- a/dlls/ucrtbase/ucrtbase.spec +++ b/dlls/ucrtbase/ucrtbase.spec @@ -211,7 +211,7 @@ @ cdecl _c_exit() MSVCRT__c_exit @ cdecl _cabs(long) MSVCRT__cabs @ cdecl _callnewh(long) -@ stub _calloc_base +@ cdecl _calloc_base(long long) MSVCRT_calloc @ cdecl _cexit() MSVCRT__cexit @ cdecl _cgets(ptr) @ stub _cgets_s
Correct me if I'm wrong, but as I remember those exports are only used when you mix some of native dlls from vcrun2015 with some of builtins. Like when application imports from api-ms-* one, which is actually installed with vcrun2015 redist. What I mean is that such mixed environment exposes such glue exports that normally are not used directly, that could potentially qualify as implementation details. I'll be happy to be wrong about that.
2016-06-14 12:56 GMT-06:00 Nikolay Sivov bunglehead@gmail.com:
On 14.06.2016 21:28, Alex Henrie wrote:
Cc: Piotr Caban piotr@codeweavers.com
For https://bugs.winehq.org/show_bug.cgi?id=40796
The Windows 10 SDK helpfully explains that calloc simply wraps _calloc_dbg if _DEBUG is defined and _calloc_base if _DEBUG is not defined. Since Wine will not be implementing _calloc_dbg because it is only available in debug builds of the C runtime library, we can make _calloc_base wrap calloc instead.
Signed-off-by: Alex Henrie alexhenrie24@gmail.com
dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec | 2 +- dlls/ucrtbase/ucrtbase.spec | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec b/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec index 18ca9d4..85b2b83 100644 --- a/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec +++ b/dlls/api-ms-win-crt-heap-l1-1-0/api-ms-win-crt-heap-l1-1-0.spec @@ -7,7 +7,7 @@ @ cdecl _aligned_realloc(ptr long long) ucrtbase._aligned_realloc @ stub _aligned_recalloc @ cdecl _callnewh(long) ucrtbase._callnewh -@ stub _calloc_base +@ cdecl _calloc_base(long long) ucrtbase._calloc_base @ cdecl _expand(ptr long) ucrtbase._expand @ stub _free_base @ cdecl _get_heap_handle() ucrtbase._get_heap_handle diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec index 690072b..365674b 100644 --- a/dlls/ucrtbase/ucrtbase.spec +++ b/dlls/ucrtbase/ucrtbase.spec @@ -211,7 +211,7 @@ @ cdecl _c_exit() MSVCRT__c_exit @ cdecl _cabs(long) MSVCRT__cabs @ cdecl _callnewh(long) -@ stub _calloc_base +@ cdecl _calloc_base(long long) MSVCRT_calloc @ cdecl _cexit() MSVCRT__cexit @ cdecl _cgets(ptr) @ stub _cgets_s
Correct me if I'm wrong, but as I remember those exports are only used when you mix some of native dlls from vcrun2015 with some of builtins. Like when application imports from api-ms-* one, which is actually installed with vcrun2015 redist. What I mean is that such mixed environment exposes such glue exports that normally are not used directly, that could potentially qualify as implementation details. I'll be happy to be wrong about that.
Good point. I just looked at this a little more closely and discovered that when you install PyQt5, it downloads a copy of msvcp140.dll. It's this DLL that's trying to call "implementation detail" functions in api-ms-win-crt-heap-l1-1-0.dll. If we create a msvcp140.dll in Wine, the problem should go away.
Can a reimplemented msvcp140.dll be included in Wine? If so, we can drop patches 2-4 of this series and work on this new DLL instead.
-Alex
PS python35.dll still calls _set_thread_local_invalid_parameter_handler and __fpe_flt_rounds directly, so implementing msvcp140.dll would not remove the need for these functions.
2016-06-14 13:22 GMT-06:00 Alex Henrie alexhenrie24@gmail.com:
Can a reimplemented msvcp140.dll be included in Wine? If so, we can drop patches 2-4 of this series and work on this new DLL instead.
Actually we could drop the entire series, patches 1-4. I forgot that _lock_locales and _unlock_locales are also only used by msvcrp140.dll.
-Alex
On 06/14/16 21:22, Alex Henrie wrote:
Correct me if I'm wrong, but as I remember those exports are only used when you mix some of native dlls from vcrun2015 with some of builtins. Like when application imports from api-ms-* one, which is actually installed with vcrun2015 redist. What I mean is that such mixed environment exposes such glue exports that normally are not used directly, that could potentially qualify as implementation details. I'll be happy to be wrong about that.
I'm not sure if we should qualify them as implementation detail taking in account the functions are exported. I don't know if any real application uses them but as long as it's a simple forward to function without _base in name I don't see anything wrong in implementing them.
Anyway I don't think it's obvious that FUNCTION_base is identical as FUNCTION.
Can a reimplemented msvcp140.dll be included in Wine? If so, we can drop patches 2-4 of this series and work on this new DLL instead.
Sure, msvcp140.dll can (and should) be included in wine. It may be not that easy though. As far as I remember vcruntime140 is missing many functions that are needed to build msvcp*. I'm not sure if all of them are available in e.g. api-* dlls.
Thanks, Piotr
-
Alex Henrie -
Nikolay Sivov -
Piotr Caban