• 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 x64\ilc\lib\MSCRT\ 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

2

1 Answer

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.

Nirsofthas 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 articleOn API-MS-WIN-XXXXX.DLL, and Other Dependency Walker Glitchescalls 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 inGithub Dependencies, and does a better job of unmasking these DLLs:

11

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy