Что такое комплекты Windows и как они работают?

Раньше при разработке проекта C ++ в Windows в Visual Studio ваша версия Visual Studio имела свою собственную версию библиотек C и C ++, и ваш проект ссылался на конкретную версию Windows SDK, чтобы для доступа к заголовкам для доступа к платформе Win32. Если у вас было установлено несколько версий Windows SDK, существовала сложная система, включающая переменные среды, которая позволяла вам выбирать, какую версию Windows SDK Visual Studio будет использовать по умолчанию.

Это было не очень хорошо. , и чтобы заставить его работать должным образом, потребовалось немного покопаться, но это почти сработало.

После того, как я только что обновился с VS2012 до VS2015, мне кажется, что эта система была заменена на либо прямо сломан, либо я просто не понимаю этого.

  1. Обновление простого консольного приложения VS2012 C ++, которое включает conio.h, до VS2015 прерывается без сообщена ошибка. Почему? conio.h больше не входит в библиотеки Visual Studio C/C ++, а теперь живет в Windows Kit 10, при обновлении проекта не происходит повторная установка используемого SDK (как и следовало ожидать).

  2. Создание нового приложения Hello World C ++ в VS2015, каталоги включения проекта C ++ наследуют $ (VC_IncludePath) и $ (WindowsSDK_IncludePath). $ (WindowsSDK_IncludePath) извлекает заголовки из C: Program Files (x86) Windows Kits 8.1, а $ (VC_IncludePath) извлекает заголовки из C: Program Files (x86) Windows Kits 10.

Таким образом, простые обновления проекта завершаются неудачно, и при обновлении не сообщается об ошибке. Чистые новые консольные проекты извлекают заголовки из двух разных установок Windows Kit одновременно, и теперь у меня есть записи для 8.1 и 10 в C: Program Files (x86) Microsoft SDKs и C: Program Files (x86) Windows Kits. Windows Kit 8.1 содержит заголовки Win32 и WinRt, тогда как Windows Kit 10 содержит заголовки C/C ++.

У меня неправильно настроенная и поврежденная установка, или это беспорядок, как и должно быть?

Если этот беспорядок такой, каким он должен быть, как он должен работать? Я пробовал искать в MSDN информацию о наборах Windows Kits, но ничего не нашел, кроме материала о Windows Driver Kit, который раньше был чем-то совершенно другим, но я не знаю, есть ли он до сих пор.

Есть ли какая-то документация, которую я пропустил, которая объясняет обоснование этой конфигурации библиотеки и то, как она предназначена для использования?


Я столкнулся с несколькими различными вариантами эта проблема уже несколько раз, с проблемами разрешения как файлов заголовков, так и зависимостей библиотек в проектах, обновленных с VS2012 до VS2015.

Комментарий Ханса в ответ на мой вопрос действительно устраняет проблему для заголовков, но после того, как я столкнулся с той же проблемой для зависимостей библиотек, у меня есть более простое решение, которое работает и для неудачного разрешения зависимостей библиотеки.

При открытии проекта VS2012 в VS2015 автоматическое обновление не выполняется. Открытие свойств проекта и изменение General -> Platform Toolset на Visual Studio 2015 (v140), скорее всего, воспроизведет либо вариант ошибки разрешения заголовка, описанный в моем исходном вопросе, либо другую ошибку разрешения зависимостей библиотеки.

Самый простой способ исправить это — открыть свойства проекта и перейти в Каталоги VC ++ -> Включить каталоги. Среди любых путей, которые вы могли добавить в свой проект самостоятельно, вы, вероятно, найдете $ (VCInstallDir) include; $ (VCInstallDir atlmfc include; $ (WindowsSDK_IncludePath)

Щелкните путь, чтобы отобразить раскрывающийся список и нажмите кнопку «Изменить», откроется диалоговое окно с тремя разделами, сверху вниз, явно заданными путями, оцененными путями и унаследованными путями. В самом низу находится флажок «Наследовать от родительских или проектных значений по умолчанию», который я всегда находил должен быть изначально снят.

Из явно определенных путей включения удалите записи $ (VCInstallDir) include; $ (VCInstallDir atlmfc include; $ (WindowsSDK_IncludePath), описанные выше, и выберите ‘Наследовать от родительский или проект по умолчанию. Это должно решить любые проблемы с зависимостями файла заголовка.

Если у вас также есть проблемы со ссылками на библиотеки, сделайте то же самое с записями каталога библиотеки, отредактируйте настройки, удалите явную платформу записей и выберите «Наследовать от родительских или проектных значений по умолчанию» (это может e хорошая идея сделать это, даже если вы не видите никаких ошибок компоновщика, иначе вы можете в конечном итоге использовать параметр компилятора набора инструментов платформы для VS2015 при связывании с библиотеками для VS2012).

Я не знаю почему это для меня облажалось, когда я не встречал никого, у кого были бы подобные проблемы, у меня раньше не было проблем с обновлением решений Visual Studio.

Я также не обнаружил, почему некоторые версии комплектов Windows теперь содержат заголовки платформы Windows или заголовки библиотеки C ++, тогда как ранее SDK всегда содержал заголовки платформы, в то время как заголовки C ++ всегда были частью установки Visual Studio. Похоже, что такое изменение должно иметь где-нибудь в блоге разработчиков или какую-то другую документацию. Но пока это работает, мне все равно.

Надеюсь, это кому-то поможет.



Windows проблема с установкой ROOT версии 618/02


_ROOT Version: 6.18.02
_Platform: Window 10 Home версии 1903 процессор на базе x64
Компилятор: Не предоставлено
Установлено Visual Studio Community 2019 версии 16.2.29215.179


У меня возникают проблемы, аналогичные описанным ранее. закрытая тема
«Проблемы с установкой Root 6.14.04 в Windows 10»

Установка root 6.18.02 с использованием самораспаковывающегося файла * .exe, представленного на странице загрузки, кажется действовать без проблем. Но при двойном щелчке по приложению ROOT на короткое время открывается окно командной строки, отображается ошибка, а затем закрывается..

Когда ‘root’ вызывается в командной строке вручную, можно увидеть эту ошибку:

  RegOpenKeyEx (HKEY_LOCAL_MACHINE  SOFTWARE  Microsoft  Microsoft  SDKs  Windows  $ VERSION  InstallationFolder): возвращается 2: системе не удается найти указанный файл. RegOpenKeyEx (HKEY_LOCAL_MACHINE  SOFTWARE  Microsoft  Windows Kits  Installed Roots  KitsRoot10): возвращается 2: системе не удается найти указанный файл. Input_line_1  : 1: 10: фатальная ошибка: 'новый' файл не найден # include  ^ ~~~~ Ошибка утверждения: OldBuilder-> DeferredDeclsToEmit.empty () && «Должны были сгенерированы все отложенные для отправки decl.», Файл C  :  build  ws  BUILDTYPE  Release  LABEL  windows10  V  6-18  root  интерпретатор  llvm  src  tools  clang  lib  CodeGen  ModuleBuilder.cpp, строка 139  

Я просмотрел предыдущие проблемы, которые кажутся похожими на эту, и похоже, что эта проблема никогда не была решена или исправлена. Я бы предпочел не компилировать код с нуля на моем ПК, но если это потребуется, я был бы очень признателен за инструкции о том, что делать.

Перед загрузкой root 6.18.02 я уже предварительно загружено сообщество Visual Studio 2019 (которое, казалось, загружалось и работало нормально), поэтому отсутствие визуальной студии, похоже, не является проблемой.

Любые советы приветствуются!


Нашего эксперта по Windows (@bellenot) пока нет. Он может помочь тебе с этим, когда вернется. Между тем у @amadio могут быть некоторые идеи по этому поводу.


Для работы ROOT требуется очень специфическая версия Visual Studio. Если версия не совпадает, возникает эта ошибка.


Хорошо, вот страница, на которой можно получить версию root, описанную в этом потоке.
https://d35c7d8c.web.cern.ch/content/release-61802

Есть ли на этой странице место, где это объясняется, а также указывается, какая именно версия Visual Studio требуется? Если нет, то я был бы признателен, если бы кто-нибудь сообщил мне, какая это версия, чтобы я мог попробовать ее сам. Это Visual Studio 16?

В верхней части моего исходного сообщения указан полный номер версии Visual Studio, которую я установил до того, как я попытался установить root 6.18.02.


В этом посте есть дополнительная информация:

Я не знаю, что я делал неправильно, так как ничего не сработало для меня, но, возможно, вам повезет больше


Я попробую (имеется в виду еще одна деинсталляция-переустановка Vis. Stud. 2019 и ROOT) и сообщить об успехе или неудаче.


Way Hey!
Похоже, у меня есть в основном успешный результат!
root действительно запускается сейчас, и он выдает мне подсказку, но есть довольно много ошибок, которые появляются до того, как он дойдет до этой точки.
Вот что происходит, когда я вызываю root 6.18.02, когда мне кажется, что я загрузил Visual Studio Community с правильной версией Windows 10 SDK:

  Microsoft Windows [Version 10.0.18362. 295] (c) Корпорация Майкрософт, 2019 г.  Все права защищены. C:  Users  Todd Huffman> root В файле, включенном из input_line_3: 39: В файле, включенном в C:  Program Files (x86)  Microsoft Visual Studio  2019NEW  VC  Tools  MSVC  14.22.27905  include   cassert: 5: В файле, включенном из C:  Program Files (x86)  Windows Kits  10  Include  10.0.18362.0  ucrt  assert.h: 12: C:  Program Files (x86)  Windows Kits  10   Include  10.0.18362.0  ucrt  corecrt.h: 142: 12: error: переопределение структуры '_CrtEnableIf ' struct _CrtEnableIf  ^ ~~~~~~~~~~~~~~  ~~~~~~~~~ C:  Program Files (x86)  Windows Kits  10  Include  10.0.17763.0  ucrt  corecrt.h: 142: 12: примечание: предыдущее определение находится здесь struct _CrtEnableIf  ^ В файле, включенном из input_line_3: 39: В файле, включенном из C:  Program Files (x86)  Microsoft Visual Studio  2019NEW  VC  Tools  MSVC  14.22.27905  include  cassert: 5: В файле, включенном из  C:  Program Files (x86)  Windows Kits  10  Include  10.0.18362.0  ucrt  assert.h: 12: C:  Program Files (x86)  Windows Kits  10  Include  10.0.18362.0  ucrt   corecrt.h: 517: 16: ошибка: переопределение  of '__crt_locale_data_public'typedef struct __crt_locale_data_public ^ C:  Program Files (x86)  Windows Kits  10  Include  10.0.17763.0  ucrt  corecrt.h: 516: 16: примечание: здесь приведено предыдущее определение typedefublic struct __crt_locale_data_data включено  from input_line_3: 39: В файле, включенном из C:  Program Files (x86)  Microsoft Visual Studio  2019NEW  VC  Tools  MSVC  14.22.27905  include  cassert: 5: В файле, включенном из C:  Program Files (  x86)  Windows Kits  10  Include  10.0.18362.0  ucrt  assert.h: 12: C:  Program Files (x86)  Windows Kits  10  Include  10.0.18362.0  ucrt  corecrt.h: 524:  16: ошибка: переопределение '__crt_locale_pointers'typedef struct __crt_locale_pointers ^ C:  Program Files (x86)  Windows Kits  10  Include  10.0.17763.0  ucrt  corecrt.h: 523: 16: примечание: предыдущее определение - heretypedef struct  __crt_locale_pointers ^ В файле, включенном из input_line_3: 39: В файле, включенном из C:  Program Files (x86)  Microsoft Visual Studio  2019NEW  VC  Tools  MSVC  14.22.27905  include  cassert: 5: В файле, включенном из C  :  Program Fi  файлы (x86)  Windows Kits  10  Include  10.0.18362.0  ucrt  assert.h: 12: C:  Program Files (x86)  Windows Kits  10  Include  10.0.18362.0  ucrt  corecrt.h:  532: 16: ошибка: переопределение '_Mbstatet'typedef struct _Mbstatet ^ C:  Program Files (x86)  Windows Kits  10  Include  10.0.17763.0  ucrt  corecrt.h: 531: 16: примечание: предыдущее определение  здесьtypedef struct _Mbstatet ^ ----------------------------------------------  -------------- |  Добро пожаловать в ROOT 6.18/02 https://root.cern |  |  (c) 1995-2019, Команда ROOT |  |  Создан для win32 23 августа 2019, 20:56:50 |  |  Из тегов/v6-18-02 @ v6-18-02 |  |  Попробуйте '.help', '.demo', '.license', '.credits', '.quit'/'. q '|  --------------------------------------------------  ---------- root [0]  

Вызывает ли беспокойство эти ошибки? Есть ли способ удалить их?
Ура,
Тодд


Бинарные файлы Windows сами по себе не требуют специального компилятора, просто ROOT предпочитает отправлять предварительно скомпилированный заголовок с двоичными файлами, что приводит к конфликтам. В частности, имена макросов менялись между версиями, поэтому вы получаете эти переопределения, потому что ваши локальные заголовки имеют другую защиту, чем те, что в предварительно скомпилированном заголовке.

Чтобы обойти это, вам нужно чтобы стереть PCH (найдите его в % ROOTSYS%/etc , с именем allDict.cxx.pch ), затем перестройте его в среде разработки компилятора в который вы собираетесь использовать ROOT. Что-то вроде (при условии 32b и опечаток по модулю):

 % cd% ROOTSYS %%.  Bin  rootcling -rootbuild -1 -f allDict.cxx -noDictSelection -c  -D__CLING__ -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DROOT_PCH -fsigned-char -I.  Include -I.  Etc -I.  Etc  dictpch -I.  Etc  cling -I% ROOTSYS%  include -FIw32praghma.h.  h -MD -D_WINDOWS -DWIN32 -D_X86_ -D_XKEYCHECK_H -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -DNOMINMAX -D_CRT_SECURE_NO_WARNINGS -DSYSTEM_TYPict_SECURE_NO_WARNINGS -DSYSTEM_TYPICT_PINCHS. все  и т. д.  использование скрипта makepch.py, который находится в % ROOTSYS%  etc  dictpch , что может быть проще (загрузите его  allHeaders.h  и  allLinkDefs.h  с флагами из  allCppFlags.txt , все в % ROOTSYS%  etc  dictpch ).   

Обратите внимание, что это проблема не только Windows, просто в ROOT есть несколько уловок для работы на большинстве Linux (например, несколько стандартных заголовков, таких как wchar.h, ar e поставляется с ROOT, найдите их в $ ROOTSYS/etc/cling в Linux), а Mac более консервативен в своих изменениях.

Но на самом деле ROOT должен делать часть создания PCH установки двоичных файлов вместо их сборки. Расскажите об этом…


Спасибо за этот ответ.

Мне понадобится немного свободного времени, чтобы попробовать это, и, возможно, больше времени, чтобы понять это и заставить его работать.
Я как бы надеялся остаться блаженно невежественным пользователем ROOT, вместо того, чтобы научиться перекомпилировать его для моей платформы (которая однажды снова столкнется с проблемами поддержки, когда я забыли все заклинания, которые я изучаю сейчас, и требуют другого выпуска или в конечном итоге останутся с другой версией ОС).

Что касается вашего последнего предложения, мы определенно согласны с ним.


Эта тема была автоматически закрыта через 14 дней после последнего ответа. Новые ответы больше не допускаются.

Оцените статью
clickpad.ru
Добавить комментарий