C ++ Windows Исполняемый файл нацелен на Win7 с использованием _WIN32_WINNT, но в результате exe импортирует неверные библиотеки Dll набора API - PullRequest
0 голосов
/ 09 июля 2020

Я разрабатываю настольное приложение на C ++, которое должно поддерживать Windows 7+. Тестирование на Windows Server 2012 Произведенный двоичный файл не работает из-за невозможности найти apiset dll, в частности api-ms-win-core-processingsthreads-l1-1-2.dll. В других ОС это может быть другая dll.

  1. Заголовок targetver.h задается соответствующей директивой препроцессора _WIN32_WINNT 0x0601 перед включением SDKDDKVer.h. Сначала я включаю targetver.h в stdafx.h, поскольку он является стандартным в стандартном шаблоне Visual Studio 2019. Я использую предварительно скомпилированные заголовки и Windows SDK версии 8.1. Для набора инструментов платформы установлено значение v141, но я использую среду IDE Visual Studio 2019. v141 используется для совместимости с пакетами Amazon AWS nuget.
#pragma once

// Including SDKDDKVer.h defines the highest available Windows platform.

// If you wish to build your application for a previous Windows platform, include WinSDKVer.h and
// set the _WIN32_WINNT macro to the platform you wish to support before including SDKDDKVer.h.

#include <Winsdkver.h>

#define _WIN32_WINNT 0x0601

#include <SDKDDKVer.h>
Запуск dumpbin / import для исполняемого файла Я ясно вижу, как он импортирует:
    api-ms-win-core-processthreads-l1-1-2.dll
             141189280 Import Address Table
             14118AEC8 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                          23 GetThreadPriority
                          25 GetThreadTimes
                           C GetCurrentProcessId
                          1A GetProcessTimes
                          31 ResumeThread
                           8 ExitThread
                          29 OpenProcess
                          13 GetExitCodeThread
                          3B SetThreadPriority
                          43 TlsAlloc
                          45 TlsGetValue
                          46 TlsSetValue
                          44 TlsFree
                          10 GetCurrentThreadId
                           F GetCurrentThread
                           B GetCurrentProcess
                           5 CreateThread
                           7 ExitProcess
                          41 TerminateProcess
                          28 IsProcessorFeaturePresent
                          40 SwitchToThread
                          1C GetStartupInfoW
Этот исполняемый файл использует заголовки boost, и я включаю их перед включением Windows .h, но после targetver.h в заголовке stdafx.h. Это связано с тем, что заголовки повышения, по-видимому, должны быть размещены первыми из других поисковых запросов.
#pragma once

#include "targetver.h"
struct IUnknown; // needed for earlier version of Windows


#include <boost/asio/ip/address.hpp>
#include <boost/interprocess/ipc/message_queue.hpp>
#include <boost/archive/text_iarchive.hpp>
#include <boost/algorithm/string.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/program_options.hpp>

#define _WINSOCKAPI_
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
Я также определяю BOOST_USE_WINDOWS_H как определение препроцессора в свойствах решения. Я пробовал с этим определением и без него. Я подтвердил, что _WIN32_WINNT установлен правильно после того, как все ускорение включает в себя оператор в файле cpp точки входа.
#if _WIN32_WINNT == 0x0601
#pragma message("_WIN32_WINNT is set correctly")
#else
#pragma message("ERROR: _WIN32_WINNT is not set correctly")
#endif

У меня есть еще один двоичный файл как часть этого проекта, который настроен так же, как правильно работает в более ранних ОС, и нет импорта dll apiset 'win-core'. Однако он не использует межпроцессное ускорение и не увеличивает адрес asio.

Программа статически связана с '/ MT', а пакеты nuget для AWS установлены на stati c .

Я считаю, что все мои Windows вызовы API должны быть совместимы с Win7 +.

Вопросы:

  • Какие-либо решения для отладки или попытки заставить этот исполняемый файл работать в целевой системе?
  • С макросом _WIN32_WINNT, установленным на 0x0601, и 8.1 SDK, не должна ли ошибка компилятора при вызовах API недоступна для целевой system?
  • Поскольку он не работает на разных библиотеках apiset, я стараюсь не концентрироваться на процессах. Однако, посмотрев на файл processsthreadsapi.h, я вижу, где установлено следующее; однако я не знаю, что устанавливает _APISET_PROCESSTHREADS_VER в заголовках Windows. Есть ли какие-либо другие определения препроцессора, которые мне нужно установить или проверить, чтобы получить соответствующий apiset?
#ifndef _APISET_PROCESSTHREADS_VER
#ifdef _APISET_MINWIN_VERSION
#if _APISET_MINWIN_VERSION >= 0x0102
#define _APISET_PROCESSTHREADS_VER 0x0102
#elif _APISET_MINWIN_VERSION == 0x0101
#define _APISET_PROCESSTHREADS_VER 0x0101
#elif _APISET_MINWIN_VERSION == 0x0100
#define _APISET_PROCESSTHREADS_VER 0x0100
#endif
#endif
#endif
  • Есть ли способ заставить компилятор не использовать apiset? Работающий исполняемый файл по-прежнему вызывает вызовы API, такие как OpenProcess, но не требует: api-ms-win-core -cesses-l1-1-2.dll.

1 Ответ

0 голосов
/ 09 июля 2020

Я решил это. У меня был Mincore.lib, включенный в компоновщик. Он предоставлял все эти ms-core * .dll. Удален Mincore.lib и проблема устранена. Проверено также с помощью dumpbin / import.

...