Csdrhrt

• Windows 7 machine


• QtCreator 4.8.0


• Qt 5.12.0


• MSVC2015 64-bit


• Compiler MSVC C++ 14.0 (x86_amd64)

I am trying to create a very simple program which I would like to share with my colleagues. They do not have Qt installed and need to have an executable. I was unsuccessful as the exe had many dependencies which I was unable to find.

To debug the issue I started from scratch with a Qt Widgets Application that does nothing (i.e. just the header file, main.cpp and mainWindow.cpp). When I run the program in QtCreator it builds successfully and exits with code 0. An executable is created and by running windeployqt all the required Qt dll's are copied to the directory. However, the windows dll's are missing. Using the dependency walker I can see that a whole list of windows dll's are missing. I do not understand why so many dll's are required for a program that does nothing. I am able to find some of the dll's in the x64ilclibMSCRT directory, but most of the required API-MS-WIN-CORE-xxx-x-x-x.dll's are not available. I have read posts of similar issues but could not relate the proposed solutions to my situation. Any advice is appreciated, it is a work laptop, hence re-installing windows is not an option.DependencyWalker screen.

edited When running the Qt executable.... (links to screen shots below)
First Error message

Second Error message, after including VCRUNTIME140_APP.dll

Output from dependency tool

These DLLs have in their time also caused me some head scratching,
so I take the opportunity to expose this mystery once and for all.

The API-MS-* DLLs are not really missing - the problem is with the dependency walker.
These fake DLLs were added in Windows Vista that dates from 2007, while the
dependency walker dates from 2006 and was never updated since.

Nirsoft
has analyzed these DLLs and has shown that they are very small and basically
contain no useful code.
When Windows loads them, their import entries are replaced by calls to real functions
in the Windows kernel.

The article
On API-MS-WIN-XXXXX.DLL, and Other Dependency Walker Glitches
calls them by the name of "Api Sets" and gives this historical perspective:

Sometime in the Vista dev cycle an effort referred to as MinWin began:
essentially, smart people started moving functionality around in hope
of simplifying the OS architecture. To protect the myriad components
from breaking during a change, the ultimate solution was called in: an
extra layer of indirection. This level is exactly Api Sets.

For example, the API set api-ms-win-core-fibers-l1-1-1.dll is an
‘atom’ of functionality encompassing the 5 APIs FlsAlloc, FlsFree,
FlsGetValue, FlsSetValue and IsThreadAFiber (it is an untypically
small such ‘atom’). All applications that consume fiber functionality
declare dependency on this API set, and thereby become insensitive to
the exact location of implementation (that might change between OS
releases). During load time, the OS searches somewhere and
automatically routes the calls from api-ms-win-core-fibers-l1-1-1.dll
to wherever they happen to be implemented in this OS version.

The actual per-OS-version redirection data lies in a special file called ApiSetSchema.dll. It's technically a DLL (conforms to the PE spec), but not an executable one – the redirection data lies in a specialized section called .apiset, mentioned at the apiset.h macros. Sebastien Renaud did some spectacular reversing work and described the layout of the redirection data it contains.

A more modern version of the dependency walker, also free, can be found in
Github Dependencies,
and does a better job of unmasking these DLLs: