• Windows 7 машина
  • QtCreator 4.8.0
  • Qt 5.12.0
  • MSVC2015 64-разрядная
  • Компилятор MSVC C++ 14.0 (x86_amd64)

Я пытаюсь создать очень простую программу, которой я хотел бы поделиться со своими коллегами. Они не имеют установленного Qt и должны иметь исполняемый файл. Я потерпел неудачу, так как у exe было много зависимостей, которые я не смог найти.

Для устранения проблемы я начал с нуля с приложением Qt Widgets, которое ничего не делает (т.е. только заголовочный файл, main.cpp и mainWindow.cpp). Когда я запускаю программу в QtCreator, она успешно собирается и завершает работу с кодом 0. Создается исполняемый файл, и при запуске windeployqt все необходимые библиотеки Qt копируются в каталог. Тем не менее, Windows DLL отсутствуют. Используя обходчик зависимостей, я вижу, что отсутствует полный список Windows DLL. Я не понимаю, почему так много DLL требуется для программы, которая ничего не делает. Я могу найти некоторые из DLL в каталоге x64\ilc\lib\MSCRT\, но большинство необходимых API-MS-WIN-CORE-xxx-xxx.dll недоступны. Я прочитал сообщения о похожих проблемах, но не смог связать предложенные решения с моей ситуацией. Любой совет приветствуется, это рабочий ноутбук, поэтому переустановка windows не вариант.Экран DependencyWalker.

редактируется При запуске исполняемого файла Qt .... (ссылки на снимки экрана ниже)Первое сообщение об ошибке

Второе сообщение об ошибке, после включения VCRUNTIME140_APP.dll

Выход из инструмента зависимости

1 ответ1

0

Эти библиотеки в свое время также вызвали у меня некоторые царапины, поэтому я пользуюсь возможностью раскрыть эту тайну раз и навсегда.

DLL-библиотеки API-MS-* самом деле не отсутствуют - проблема с обходчиком зависимостей. Эти поддельные библиотеки DLL были добавлены в Windows Vista начиная с 2007 года, а обходчик зависимостей - с 2006 года и с тех пор не обновлялся.

Nirsoft проанализировал эти библиотеки DLL и показал, что они очень маленькие и в основном не содержат полезного кода. Когда Windows загружает их, их записи импорта заменяются вызовами реальных функций в ядре Windows.

В статье « Об API-MS-WIN-XXXXX.DLL и других зависимостях» глюки называют их "Api Sets" и дают такую историческую перспективу:

Когда-то в цикле разработки для Vista началась работа, называемая MinWin : по сути, умные люди начали перемещать функциональность в надежде упростить архитектуру ОС. Чтобы защитить множество компонентов от поломок во время изменений, было названо окончательное решение: дополнительный уровень косвенности. Этот уровень точно Api Sets.

Например, набор API api-ms-win-core-fibers-l1-1-1.dll представляет собой «атом» функциональности, охватывающий 5 API-интерфейсов: FlsAlloc , FlsFree , FlsGetValue , FlsSetValue и IsThreadAFiber (это необычно мало 'атом'). Все приложения, которые используют функциональные возможности оптоволокна, объявляют зависимость от этого набора API и, таким образом, становятся нечувствительными к точному местоположению реализации (которое может изменяться между выпусками ОС). Во время загрузки ОС ищет где-то и автоматически направляет вызовы из api-ms-win-core-fibers-l1-1-1.dll туда, где они реализованы в этой версии ОС.

Фактические данные перенаправления для каждой версии ОС находятся в специальном файле ApiSetSchema.dll . Технически это DLL (соответствует спецификации PE), но не исполняемая - данные перенаправления находятся в специализированном разделе .apiset , упомянутом в макросах apiset.h . Себастьян Рено сделал несколько впечатляющих изменений и описал структуру данных перенаправления, которые он содержит.

Более современная версия обходчика зависимостей, также бесплатная, может быть найдена в Github Dependencies и лучше справляется с демаскировкой этих DLL:

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .