Martin Storsjö <mar...@martin.st> writes: > On Thu, 8 Jun 2023, Alexandre Julliard wrote: > >> Martin Storsjö <mar...@martin.st> 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
