# GET\_RUNTIME\_DEPENDENCIES has difficulties with windows API sets
**URL:** https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768
**Category:** Code
**Created:** [September 2, 2020, 7:47am UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768 "2020-09-02T07:47:37Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Stephan268](https://discourse.cmake.org/u/Stephan268)
#### Post date: [September 2, 2020, 7:47am UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/1 "2020-09-02T07:47:38Z")
GET\_RUNTIME\_DEPENDENCIES return dlls that do not physically exist and are part of the concept that Microsoft refers to as API sets.
Examples:
- api-ms-win-core-libraryloader-l1-2-1.dll
- api-ms-win-core-atoms-l1-1-0.dll
- api-ms-win-core-winrt-error-l1-1-1.dll
- api-ms-win-core-sidebyside-l1-1-0.dll
- api-ms-win-core-localization-obsolete-l1-3-0.dll
- api-ms-win-core-heap-l1-2-0.dll
- api-ms-win-core-heap-l2-1-0.dll
- api-ms-win-core-delayload-l1-1-1.dll
- api-ms-win-core-libraryloader-l1-2-0.dll
- api-ms-win-core-rtlsupport-l1-2-0.dll
- api-ms-win-core-shlwapi-obsolete-l1-2-0.dll
- api-ms-win-security-base-l1-2-0.dll
There are other with the prefix “ext-ms-win” or “ext-ms”.
I can add exclusion patterns to GET\_RUNTIME\_DEPENDENCIES using pre\_exclude\_regexes but this is very fragile, because it depends on OS versions. I think it would be better if cmake handles these tricky aspects. It would fit better into the philosophy of cmake to provide abstraction of the OS, makesystem, …
References: [On API-MS-WIN-XXXXX.DLL, and Other Dependency Walker Glitches](https://ofekshilon.com/2016/03/27/on-api-ms-win-xxxxx-dll-and-other-dependency-walker-glitches/)
---
### Author:  [@hsattler](https://discourse.cmake.org/u/hsattler)
#### Post date: [September 2, 2020, 12:51pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/2 "2020-09-02T12:51:10Z")
And why did MS added those to the VC runtime installers for e.g. Windows XP? Because sometimes they are needed.
---
### Author:  [@Stephan268](https://discourse.cmake.org/u/Stephan268)
#### Post date: [September 2, 2020, 3:43pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/3 "2020-09-02T15:43:05Z")
I probably did not phrase the problem I have with the implementation in cmake very well.
I use GET\_RUNTIME\_DEPENDENCIES to figure out which external DLLs I need to add to my application kit. This can be tricky because I need to classify into “own”, “used 3rd party”, “part of the OS”, “part of the VC runtime”.
Ideally cmake could help classify the latter two classes.
I would not add “part of the OS” to my kit.
I would not add “part of the VC runtime” to my kit but reference it so that it can be installed seperatly.
The API set “DLLs” are (to my knowledge) not a physical DLL but an abstract concept which is part of the OS. So actually they should never be output by GET\_RUNTIME\_DEPENDENCIES.
---
### Author:  [@hsattler](https://discourse.cmake.org/u/hsattler)
#### Post date: [September 3, 2020, 11:48am UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/4 "2020-09-03T11:48:51Z")
They are “part” of Windows 8 and later. This is a problem when deploying to older Windows versions. That’s why they are part of the redistributable files.
---
### Author:  [@Stephan268](https://discourse.cmake.org/u/Stephan268)
#### Post date: [September 3, 2020, 1:33pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/5 "2020-09-03T13:33:25Z")
Aha! Maybe the problem I am facing has a different reason. I am running Visual Studio 2015 on Windows 10.
> file (GET\_RUNTIME\_DEPENDENCIES …)
returns
> file Could not resolve file api-ms-win-crt-convert-l1-1-0.dll
Searching for _api-ms-win-crt-convert-l1-1-0.dll_ locates in a multitude of locations, e.g. Appdata or installation directory of MS-Teams, MS-Office, MS-Onedrive, firefox, …
as well as
C:\Programs(x86)\Windows Kits\10\Redist…
C:\Programs(x86)\Microsoft Visual Studio 14.0\Common7.…
As I build with VS2015 I would have expected that cmake locates the DLL in the installation directory of VS2015. Maybe it would even be better if it additionally treats it as something special, i.e. part of a redistributable. This would allow the programmer to decide if he/she wants to add the DLLs to his/her own kit or have it installed via the original Microsoft redistributable package.
With the way it is now I do not know if I should treat unresolved files as error. I could maintain a whitelist. This would force me to update this list with every new VS or redistributable version. This might better be done with cmake. Also I cannot add these files to my install kit because my code does not know where they are located.
Ideas warmely welcome.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 3, 2020, 6:01pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/6 "2020-09-03T18:01:47Z")
I did this in the Python prototype the CMake implementation was based on. I remember @kyle.edwards and I discussing these cases, but can’t remember exactly what we decided to do about them. It seems that yes, `PRE_EXCLUDE_REGEXES` is the thing to do right now. Maybe we could add something like `PRE_EXCLUDE_SYSTEM_LIBRARIES` which is defined to be some sensible, but still restricted set of libraries for each platform (`libSystem.dylib`, `api-ms-*.dll` (and friends), and `libc.so` is about as high as I think we’d want to go).
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 3, 2020, 6:04pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/7 "2020-09-03T18:04:16Z")
> [@ben.boeckel](#):
>
> Maybe we could add something like `PRE_EXCLUDE_SYSTEM_LIBRARIES` which is defined to be some sensible, but still restricted set of libraries for each platform ( `libSystem.dylib` , `api-ms-*.dll` (and friends), and `libc.so` is about as high as I think we’d want to go).
Though this does open up a huge hole of keeping compatibility if we ever try to change it… Maybe we just have regexes for classes of libraries in a module?
```cmake
# CMakeSystemLibraryRegexes.cmake
set(CMAKE_SYSTEM_WINDOWS_API_DLLS "...")
set(CMAKE_SYSTEM_APPLE_LIBSYSTEM "...")
```
Then users can use them as wanted in `PRE_EXCLUDE_REGEXES` and we can add new variables as new “classes” of libraries appear?
---
### Author:  [@Stephan268](https://discourse.cmake.org/u/Stephan268)
#### Post date: [September 4, 2020, 3:48pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/8 "2020-09-04T15:48:35Z")
At first glance the provisioning of regex looks good. It could give users a good starting point for further modifications. Some ideas and design considerations.
- the regex should probably depend on compiler+version, build platform, target platform
- the required classes will need some thought especially if they abstract well from the OS
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 8, 2020, 1:20pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/9 "2020-09-08T13:20:27Z")
I think it’s sufficient to have a blanket exclusion for the pseudo DLL names that never actually is exist. MSVC runtime DLLs _might_ warrant a per-toolchain regex, but who is packaging up more than one at a time anyways?
---
### Author:  [@Stephan268](https://discourse.cmake.org/u/Stephan268)
#### Post date: [September 14, 2020, 1:18pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/10 "2020-09-14T13:18:37Z")
It seems that my initial assumption that windows API sets are the problem is incorrect. Hendrik Sattler’s reply (see above) started me having a closer look at the topic. See replies below.
I now have an additional dll that cannot be resolved: “gdiplus.dll”. It seems that GET\_RUNTIME\_DEPENDENCIES does not search in all required directories. The problem occurs on a Windows 7 build machine.
---
### Author:  [@gabyx](https://discourse.cmake.org/u/gabyx)
#### Post date: [May 18, 2022, 12:04pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/11 "2022-05-18T12:04:44Z")
Is therre any solution to this exceept the exclusion regexes?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 18, 2022, 1:10pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/12 "2022-05-18T13:10:52Z")
Not today. Eventually, it’d be nice to have a module that provides the regexes for easy use (MRs welcome 🙂 ), but there’s no other mechanism that is necessary.
---
### Author:  [@gabyx](https://discourse.cmake.org/u/gabyx)
#### Post date: [May 19, 2022, 10:14am UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/13 "2022-05-19T10:14:53Z")
Thanks, for your reply, is there alreardy a Bug rerport ffor this or is the implementation forr the logic of the runtime loading mechanism corrrect in `GET_RUNTIME_DEPENDENCIES` under Windows.
I am just currious as cerrtain librraries such as `emclient.dll` pop up which have nothing to do with the traversed Dependency Graph
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 19, 2022, 11:28am UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/14 "2022-05-19T11:28:07Z")
Libraries that show up are listed somewhere in your dependency chain in some way. If you can show an example which reports a DLL that is not actually used, that would go a long way to figuring out what’s wrong.
---
### Author:  [@gabyx](https://discourse.cmake.org/u/gabyx)
#### Post date: [May 19, 2022, 11:52am UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/15 "2022-05-19T11:52:31Z")
The strange dependencies come in by the following:
Delay Load Dependencies from Dumbin.exe with `coreuicomponents.dll` (system lib)
Maybe the delay load can be ignored, or made optionally ignored, but probaly not always the case…
Also `urlmon.dll` has some strange delay load dependencies `wpaxholder.dll`
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 19, 2022, 6:41pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/16 "2022-05-19T18:41:43Z")
Hmm. I thought delayload dependencies were ignored. @kyle.edwards?
---
### Author:  [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [May 19, 2022, 6:50pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/17 "2022-05-19T18:50:52Z")
On Windows, `GET_RUNTIME_DEPENDENCIES` simply scans the output of `dumpbin` (or `objdump`) for `.dll`. It doesn’t distinguish between delay load and normal dependencies.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 19, 2022, 7:58pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/18 "2022-05-19T19:58:57Z")
Ah, the prototype extractor from the superbuild bails when it sees “delay load dependencies”. I suppose a flag to handle this is likely warranted (possibly with a policy to change the default).
---
### Author:  [@gabyx](https://discourse.cmake.org/u/gabyx)
#### Post date: [May 20, 2022, 5:55am UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/19 "2022-05-20T05:55:47Z")
That would be great. Or might there be an option to set arguments to the dumbbin.exe?. Actually the depedency tool can be set (but no arguments), but CMake then does the parsing, not sure how that should work to set another tool. I guess only the supported ones on the doc pages are meaningful.
Otherwise maye support a tool which outputs JSON in some sensful format, which can then be parsed platform independent etc…
---
### Author:  [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [May 20, 2022, 12:56pm UTC](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/20 "2022-05-20T12:56:35Z")
In the long term, I think the goal should be for CMake to parse the PE file format directly and not use external tools like `dumpbin` and `objdump`. The format is well-documented.
[Next page](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768.md?page=2)