Re: [Mingw-w64-public] [PATCH] crt: add some missing CRT entries
Martin Storsjö writes: > On Thu, 8 Jun 2023, Alexandre Julliard wrote: > >> Martin Storsjö writes: >> >>> When looking at the redistributable api-ms-win-crt*.dlls from the >>> redistributable UCRT, api-ms-win-crt-filesystem-l1-1-0.dll does not >>> contain these symbols; neither in the original releases of UCRT from >>> 2015, nor in the current releases from the latest WinSDK. So if we >>> link against this function from api-ms-win-crt-filesystem-l1-1-0.dll, >>> a binary won't load with the redistributable version of UCRT. >>> >>> As these DLLs don't exist physically on disk in actual Windows 10, I >>> can't inspect that, but I did try to link a test executable with this, >>> which imports _getcwd from api-ms-win-crt-filesystem-l1-1-0.dll and it >>> actually does seem to run successfully on Windows 10, so it is >>> somewhat there still. >> >> Note that at runtime, imports of api-ms-* dlls are not resolved like >> normal imports; first the dll name is mapped to the target dll through >> the apiset data, and then the function is looked up in the target dll >> only. The function is never actually looked up in the api-ms-* dll. >> >> This means that the fact that a function is found on Windows at runtime >> doesn't tell you anything about whether it should be in the api-ms-* >> importlib. > > Thanks, I didn't know that aspect! > >> It also means that there's no issue with having the same function >> exported from multiple api-ms-win-crt-* importlibs, or with having extra >> exports that may not exist on Windows. All that matters at runtime is >> that the function can be found in ucrtbase.dll. > > Except that for older OSes, the UCRT is a separate redistributable > install and not handled as OS-provided apisets. > > My test executable, which imported _getcwd from > api-ms-win-crt-filesystem-l1-1-0.dll, which succeeded on Windows 10, > failed to load on Windows 7 (with UCRT installed), while a similar > executable linked with the current git version of import libs did load > successfully. Good point, indeed the redistributable is using plain forwards instead of apisets, so in that case the imports have to match exactly. -- Alexandre Julliard julli...@winehq.org ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: add some missing CRT entries
Martin Storsjö writes: > When looking at the redistributable api-ms-win-crt*.dlls from the > redistributable UCRT, api-ms-win-crt-filesystem-l1-1-0.dll does not > contain these symbols; neither in the original releases of UCRT from > 2015, nor in the current releases from the latest WinSDK. So if we > link against this function from api-ms-win-crt-filesystem-l1-1-0.dll, > a binary won't load with the redistributable version of UCRT. > > As these DLLs don't exist physically on disk in actual Windows 10, I > can't inspect that, but I did try to link a test executable with this, > which imports _getcwd from api-ms-win-crt-filesystem-l1-1-0.dll and it > actually does seem to run successfully on Windows 10, so it is > somewhat there still. Note that at runtime, imports of api-ms-* dlls are not resolved like normal imports; first the dll name is mapped to the target dll through the apiset data, and then the function is looked up in the target dll only. The function is never actually looked up in the api-ms-* dll. This means that the fact that a function is found on Windows at runtime doesn't tell you anything about whether it should be in the api-ms-* importlib. All the api-ms-win-crt-* dlls resolve to ucrtbase.dll, so you could import _getcwd (or any other ucrtbase.dll function) from any of the api-ms-win-crt-* dlls and it will load correctly on Windows. It also means that there's no issue with having the same function exported from multiple api-ms-win-crt-* importlibs, or with having extra exports that may not exist on Windows. All that matters at runtime is that the function can be found in ucrtbase.dll. -- Alexandre Julliard julli...@winehq.org ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: add some missing CRT entries
On Thu, 8 Jun 2023, Alexandre Julliard wrote: Martin Storsjö writes: When looking at the redistributable api-ms-win-crt*.dlls from the redistributable UCRT, api-ms-win-crt-filesystem-l1-1-0.dll does not contain these symbols; neither in the original releases of UCRT from 2015, nor in the current releases from the latest WinSDK. So if we link against this function from api-ms-win-crt-filesystem-l1-1-0.dll, a binary won't load with the redistributable version of UCRT. As these DLLs don't exist physically on disk in actual Windows 10, I can't inspect that, but I did try to link a test executable with this, which imports _getcwd from api-ms-win-crt-filesystem-l1-1-0.dll and it actually does seem to run successfully on Windows 10, so it is somewhat there still. Note that at runtime, imports of api-ms-* dlls are not resolved like normal imports; first the dll name is mapped to the target dll through the apiset data, and then the function is looked up in the target dll only. The function is never actually looked up in the api-ms-* dll. This means that the fact that a function is found on Windows at runtime doesn't tell you anything about whether it should be in the api-ms-* importlib. Thanks, I didn't know that aspect! It also means that there's no issue with having the same function exported from multiple api-ms-win-crt-* importlibs, or with having extra exports that may not exist on Windows. All that matters at runtime is that the function can be found in ucrtbase.dll. Except that for older OSes, the UCRT is a separate redistributable install and not handled as OS-provided apisets. My test executable, which imported _getcwd from api-ms-win-crt-filesystem-l1-1-0.dll, which succeeded on Windows 10, failed to load on Windows 7 (with UCRT installed), while a similar executable linked with the current git version of import libs did load successfully. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: add some missing CRT entries
On Thu, 8 Jun 2023, Steve Lhomme wrote: According to the WACK. --- .../lib-common/api-ms-win-crt-filesystem-l1-1-0.def | 5 + mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def | 1 + mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def | 1 + 3 files changed, 7 insertions(+) diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def index 45ae728ba..f5ccd2161 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def @@ -27,6 +27,9 @@ _fstat32i64 _fstat64 _fstat64i32 _fullpath +_getcwd +getcwd == _getcwd +_getdcwd This is wrong. When looking through the XML listings of current WACK, yes, it does list _getcwd and _getdcwd as allowed for api-ms-win-crt-filesystem-l1-1-0.dll. But they're also allowed for api-ms-win-crt-stdio-l1-1-0.dll, where we currently provide these symbols. If we provide them in both api-ms-win-crt-filesystem-l1-1-0 and api-ms-win-crt-stdio-l1-1-0, it's somewhat unspecified which one we end up linking against - it's pretty much up to the linker. When looking at the redistributable api-ms-win-crt*.dlls from the redistributable UCRT, api-ms-win-crt-filesystem-l1-1-0.dll does not contain these symbols; neither in the original releases of UCRT from 2015, nor in the current releases from the latest WinSDK. So if we link against this function from api-ms-win-crt-filesystem-l1-1-0.dll, a binary won't load with the redistributable version of UCRT. As these DLLs don't exist physically on disk in actual Windows 10, I can't inspect that, but I did try to link a test executable with this, which imports _getcwd from api-ms-win-crt-filesystem-l1-1-0.dll and it actually does seem to run successfully on Windows 10, so it is somewhat there still. But if looking at ucrt.lib in the WinSDK, it only links _getcwd against api-ms-win-crt-stdio-l1-1-0.dll (otherwise it would also break deployment against the redistributable UCRT). So as this is functions that already is provided elsewhere, we shouldn't provide them in another location with lesser availability. (If it was the question of a function which wasn't available at all previously, it would be a different thing.) @@ -62,6 +65,8 @@ _wfindnext32i64 _wfindnext64 _wfindnext64i32 _wfullpath +_wgetcwd +_wgetdcwd Same thing as _getcwd, already provided in api-ms-win-crt-environment-l1-1-0, also allowed by WACK there. _wmakepath _wmakepath_s _wmkdir diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def index fd793fe82..8a00f801c 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def @@ -25,6 +25,7 @@ _query_new_handler _query_new_mode _realloc_base _recalloc +_resetstkoflw Already in api-ms-win-crt-runtime-l1-1-0 _set_new_mode calloc free diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def index d59859ced..e1020e2ef 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def @@ -179,6 +179,7 @@ getwc getwchar putc putchar +putenv Now this one is actually slightly different from the others. The old redistributable UCRT DLLs don't provide any direct "putenv" symbol, but api-ms-win-crt-environment-l1-1-0.dll does provide "_putenv". Our api-ms-win-crt-environment-l1-1-0.def provides putenv as an alias for _putenv. So here it's still the same; when we already provide the symbol in a more reliable/accessible/compatible way (which also is accepted by the WACK), we shouldn't start linking it this way. TL;DR, I don't think any part of this patch should be applied. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] crt: add some missing CRT entries
According to the WACK. --- .../lib-common/api-ms-win-crt-filesystem-l1-1-0.def | 5 + mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def | 1 + mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def | 1 + 3 files changed, 7 insertions(+) diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def index 45ae728ba..f5ccd2161 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def @@ -27,6 +27,9 @@ _fstat32i64 _fstat64 _fstat64i32 _fullpath +_getcwd +getcwd == _getcwd +_getdcwd _getdiskfree _getdrive _getdrives @@ -62,6 +65,8 @@ _wfindnext32i64 _wfindnext64 _wfindnext64i32 _wfullpath +_wgetcwd +_wgetdcwd _wmakepath _wmakepath_s _wmkdir diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def index fd793fe82..8a00f801c 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-crt-heap-l1-1-0.def @@ -25,6 +25,7 @@ _query_new_handler _query_new_mode _realloc_base _recalloc +_resetstkoflw _set_new_mode calloc free diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def index d59859ced..e1020e2ef 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def @@ -179,6 +179,7 @@ getwc getwchar putc putchar +putenv puts putwc putwchar -- 2.39.2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
