Martin Storsjö <[email protected]> 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 [email protected] _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
