Windows kits что это
Обновлено: 30.06.2024
По умолчанию, когда я устанавливал на свою рабочую систему Windows 10 Pro amd64 (Version 10.0.17134.254) пакет Windows ADK, пакет установил по сути все необходимое за исключением Среда предустановки Windows (WinPE) которая представляет из себя мини операционную систему используемую для установки, развертывания. Возможности WinPE – это
- Среда предустановки Windows (x86)
- Среда предустановки Windows (AMD64)
Win + Windows Kits – Среда средств развертывания и работы с образами и запускаем ее с правами « Администратора ». Проверяю, что утилита теперь имеется:
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools>copype
Creates working directories for WinPE image customization and media creation.
amd64 Copies amd64 boot files and WIM to <workingDirectory>\media.
x86 Copies x86 boot files and WIM to <workingDirectory>\media.
arm Copies arm boot files and WIM to <workingDirectory>\media.
arm64 Copies arm64 boot files and WIM to <workingDirectory>\media.
Note: ARM/ARM64 content may not be present in this ADK.
workingDirectory Creates the working directory at the specified location.
Example: copype amd64 C:\WinPE_amd64
Для архитектуры amd64:
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools>copype amd64 c:\winpe_x64
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools>copy "c:\Program Files\Windows AIK\Tools\PETools\amd64\winpe.wim" c:\winpe_x64\media\sources\boot.wim /Y
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools>copy "c:\Program Files\Windows AIK\Tools\amd64\imagex.exe" c:\winpe_x64\media\
А вот на релиз Windows 10 Pro x64 (10.0.17134.112) когда установил среду предустановки WinPE таких путей не оказалось как выше, а файл winpe.wim располагается по:
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\en-us
А значит с учетом этого команды по подготовке образа winpe_amd64.iso будут следующими:
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools>copype amd64 c:\winpe_x64
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools>cd "..\..\Assessment and Deployment Kit\Windows Preinstallation Environment"
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment>copy amd64\en-us\winpe.wim c:\winpe_x64\media\sources\boot.wim /Y
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment>copy "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\imagex.exe" c:\winpe_x64
Для архитектуры x86:
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools>copype x86 c:\winpe_x86
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools>copy "c:\Program Files\Windows AIK\Tools\PETools\x86\winpe.wim" "c:\winpe_x86\media\sources\boot.wim" /Y
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools>copy "C:\Program Files\Windows AIK\Tools\x86\imagex.exe" c:\winpe_x86\media\
по аналогие с выше указанным для текущей редакции Windows и пути для образа x86 будут другими.
На заметку: Я уже давно не использую Windows 10 Pro x86 так что не особо-то и заостряю на ней внимание.
Так теперь его нужно проверить, а как? К примеру создать VM либо через Virtualbox, либо QEMU+KVM и выставить что первым загрузка должна идти с образа winpe. И если Вы увидите загрузку ниже, как на моем представленном скриншоте, то все у Вас получилось.
Всем привет Сегодня мы поговорим с вами о такой штуке как Windows Kit, которая имеет полное название такое: Windows Automated Installation Kit. Я расскажу что это, для чего используется и все такое. Ну так вот ребята, знаете что это такое? Это коллекция инструментов для развертывания Windows. Вот честно говоря я пока еще точно не могу понять что это. Первая версия Windows Kit была уже в глючной Висте.
Так, стоп ребята, Windows Kit и Windows Kits это одно и тоже или все такие разное? Я думаю что одно и тоже, просто Windows Kits идет в множественном числе, ну то есть тут инструменты именно, а не один инструмент. Ведь если посмотреть в интернете, то там так и написано, что Windows Kit это НАБОР инструментов
Так, вот что я узнал еще ребята, в Windows 8.1 есть пакет разработки SDK, ну вот в этот пакет включена политика комплектов ARM, и потом еще указывается такое как Microsoft-Windows-Kits-Secure-Boot-Policy.p7b, я не знаю что это, но видимо все в ту сторону идет, ну то есть системное что-то, виндовское.. Сразу скажу что это вряд ли грузит винду.
Я также узнал что Windows Kits может стоять в этой папке:
C:\Program Files (x86)\Windows Kits
C:\Program Files\Windows Kits
И узнал что у вас в диспетчере задач может быть запущен какой-то процесс из этой папки, это нормально. И есть такая штука не только в Windows 8, но и в Windows 10, а может даже и в Windows 7. Windows Kits имеет какую-то связь с Visual Studio.
Смотрите, вот окно Welcome to Windows Automated Installation Kit, видимо это окно инсталляции и как я вижу то это для Windows 7:
Но что такое развертывание Windows? Вот и мне стало интересно, я нашел инфу! В общем в этом плане Windows Kit позволяет изменить состав винды, то есть можно и оформление изменить, и настройки сразу задать и программы установить. Это все я имею ввиду работать с ДИСКОМ ВИНДЫ, ну то есть образом! Не с установленной виндой, а именно с установщиком! Ну короче Windows Kit это инструмент чтобы создать винду по себя и потом ее установить. Ладно, напишу еще проще, благодаря Windows Kit можно делать всякие свои сборки
Ну что ребята, более-менее понятно вам? Надеюсь что да, ну а если что не так, то вы уж извините. Удачи вам
В любой известной операционной системе, помимо встроенных пользовательских приложений и настроек имеются определенные службы и инструменты, которые позволяют выполнять определенные действия для тонкой настройки. Начиная с версии Windows Vista, в ОС от компании Майкрософт появился набор инструментов Windows Kits (полное название Windows Automated Installation Kit). Попробуем досконально разобраться в вопросах: что представляет собой этот пакет, его функциональные возможности и где его можно отыскать.
Сразу стоит отметить, что в еще одном инструменте разработки SDK, непосредственно в политике комплектов ARM имеется такая вещь, как Microsoft-Windows-Kits-Secure-Boot-Policy.p7b. Из этого можно сделать определенный вывод: Windows Kits – относится к системным инструментам разработки, то есть с ее помощью можно изменять внутренние функции ОС. Исходя из вышесказанного стоит также отметить, что этот пакет вряд ли слишком много требует ресурсов, что положительно сказывается на производительности.
Windows Kits устанавливается в директорию C:\Program Files (x86)\Windows Kits (для 32-битных версий путь будет C:\Program Files\Windows Kits). При этом, досконально изучая диспетчер задач, а точнее перечень запущенных процессов, можно отыскать несколько, которые также запускаются с этой папки. Данный пакет, судя по назначению связан непосредственно с Visual Studio.
Главное окно установочного пакета выглядит следующим образом.
При этом, помимо Windows Kits здесь имеется масса и других средств разработки.
Изучая тематические форумы и сайт разработчика Майкрософт, можно сделать вывод, что этот инструмент применяется не для установленной операционной системы, а для образа Windows, который впоследствии можно записать на диск или съемный накопитель в виде установочного носителя. Это необходимо для того, чтобы отключить определенные службы, исключить некоторые стандартные приложения, то есть убрать некоторые инструменты непосредственно из установочного пакета Windows. По большому счету, этот набор инструментов пригодится тем, кто занимается созданием собственных сборок операционных систем. Например, в стандартном инсталляционном пакете Windows могут быть в наличии некоторые игры и встроенные приложения, такие, как Paint, калькулятор и т.п. При работе с Windows Kits, их можно исключить из установочного пакета и они не будут инсталлированы.
И если до этого мы говорили лишь о том, чтобы убрать какие-то функции или приложения, то следует помнить, что в образ Windows можно и добавлять те программы, которые по идее будут регулярно использоваться после переустановки. Например, сейчас можно встретить массу сборок, в которую может быть включен пакет программ для последующей установки. Этот шаг невозможно осуществить без Windows Automated Installation Kit.
В старые времена при разработке проекта C ++ для Windows в Visual Studio ваша версия Visual Studio имела бы собственную версию библиотек C и C ++, а ваш проект ссылался на конкретную версию Windows SDK, чтобы получить доступ к заголовкам для доступа. на платформу Win32. Если у вас было установлено несколько версий Windows SDK, существовала сложная система, включающая переменные среды, которая позволяла вам выбрать, какую версию Windows SDK Visual Studio будет использовать по умолчанию.
Это было не здорово, и чтобы заставить его работать должным образом, нужно было немного покопаться, но это было просто работа.
Я только что перешел с VS2012 на VS2015, и мне кажется, что то, чем была заменена эта система, либо полностью сломано, либо я просто не понимаю этого.
Обновление простого консольного приложения VS2012 C ++, которое включает conio.h до VS2015, без ошибок. Зачем? conio.h больше не находится в библиотеках Visual Studio C / C ++ и вместо этого теперь живет в Windows Kit 10, обновление проекта не соответствует используемому SDK (как и следовало ожидать).
Создавая новое приложение 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.
Таким образом, простые обновления проекта завершаются неудачно, и об этом не сообщается об ошибке. Очистите новые консольные проекты, извлекая заголовки из 2 различных установок Windows Kit, и теперь у меня есть записи для 8.1 и 10 в C: \ Program Files (x86) \ Microsoft SDK и 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), скорее всего, воспроизведет либо вариант ошибки разрешения заголовка, описанный в моем исходном вопросе, либо другую ошибку разрешения зависимостей библиотеки.
Щелкните путь, чтобы отобразить раскрывающийся список, и нажмите кнопку «Изменить». Откроется диалоговое окно с тремя разделами сверху вниз, явно определенными путями, оцененными путями и унаследованными путями. В самом низу находится флажок «Наследовать от родительского или проекта по умолчанию», который я всегда находил изначально непроверенным.
Из явно определенных путей включения удалите записи $ (VCInstallDir) \ include; $ (VCInstallDir \ atlmfc \ include; $ (WindowsSDK_IncludePath), описанные выше, и выберите параметр «Наследовать от родителя или по умолчанию проекта». Это должно разрешить любую зависимость файла заголовка проблемы.
Если у вас также есть проблемы со ссылками на библиотеку, сделайте то же самое с записями в каталоге библиотеки, отредактируйте настройки, удалите явные записи платформы и выберите «Наследовать от родительского или проекта по умолчанию». (Это может быть хорошей идеей, даже если вы не видите ошибок компоновщика, в противном случае вы можете использовать опцию компилятора набора инструментов платформы для VS2015 при подключении к библиотекам для VS2012).
Я не знаю, почему это облажалось для меня, когда я не сталкивался с кем-то, кто сталкивался с подобными проблемами, у меня не было проблем с обновлением решений Visual Studio.
Я также не выяснил, почему некоторые версии Windows Kits теперь содержат либо заголовки платформы Windows, либо заголовки библиотеки C ++, когда ранее SDK всегда содержал заголовки платформы, в то время как заголовки C ++ всегда были частью или установкой Visual Studio. Похоже, что подобное изменение должно иметь где-то блог разработчика или какую-то другую документацию. Но пока это работает, мне все равно.
В старые времена при разработке проекта C ++ в Windows в Visual Studio ваша версия Visual Studio имела бы собственную версию библиотек C и C ++, и ваш проект ссылался бы на определенную версию SDK Windows, чтобы получить доступ к заголовкам для доступа на платформу Win32. Если у вас установлено несколько версий Windows SDK, была сложная система с переменными среды, которые позволили вам выбрать, какая версия Windows SDK Visual Studio будет использоваться по умолчанию.
Это было не здорово, и чтобы заставить его работать правильно, потребовалось немного копаться, но это было почти занято.
Только что обновленный от VS2012 до VS2015, и мне кажется, что независимо от того, что эта система была заменена, она либо полностью сломана, либо я просто не понимаю ее.
Создавая новое приложение 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 SDK и C: \ Program Files (x86) \ Windows Kits. Windows Kit 8.1 содержит заголовки Win32 и WinRt, а Windows Kit 10 содержит заголовки C/C ++.
У меня есть неправильно сконфигурированная и поврежденная установка или этот беспорядок, как это должно быть?
Если этот беспорядок - как это должно быть, как это намеревается работать? Я пробовал искать MSDN для информации о наборах Windows, но ничего не видел, кроме материалов о наборе драйверов для Windows, который раньше был чем-то совершенно другим, но я не знаю, все ли это.
Есть ли какая-либо документация, которую я пропустил, которая объясняет обоснование этой конфигурации библиотеки и как она предназначена для использования?
Несколько раз я столкнулся с несколькими различными вариантами этой проблемы: проблемы, разрешающие как файлы заголовков, так и зависимости библиотек от проектов, обновленных с VS2012 до VS2015.
Комментарий Ханса в ответ на мой вопрос действительно исправляет проблему для заголовков, но после того, как вы столкнулись с той же проблемой для зависимостей библиотек, у меня есть то, что может быть более простым решением, которое также работает для разрешения неудачной библиотеки.
On opening a VS2012 project in VS2015 no automatic upgrade is performed. Opening the project properties and changing General -> Platform Toolset to Visual Studio 2015 (v140) will likely reproduce either a variant of the header resolution error described in my original question or a different library dependency resolution error.
The easiest way I've found to fix these is to open project properties and go to VC++ Directories -> Include Directories. In amongst any paths you may have added to your project yourself you will probably find $(VCInstallDir)\include;$(VCInstallDir\atlmfc\include;$(WindowsSDK_IncludePath)
Щелкните путь, чтобы отобразить выпадающий список и нажмите «Редактировать». Появится диалоговое окно с тремя разделами сверху вниз, явно определенными путями, оцененными путями и унаследованными путями. В самом низу находится флажок «Наследовать от родительских или проектов по умолчанию», которые я всегда считал первоначально непроверенными.
Из явно определенных путей include удалите записи $ (VCInstallDir) \ include; $ (VCInstallDir \ atlmfc \ include; $ (WindowsSDK_IncludePath), описанные выше, и выберите параметр «Наследовать от родительского или проекта по умолчанию». Это должно разрешить любую зависимость заголовка вопросы.
Если у вас также есть проблемы с реферированием библиотек, делайте то же самое с элементами каталога библиотеки, отредактируйте настройки, удалите явные записи формы и выберите «Наследовать от родительских или по умолчанию проекта». (Это может быть хорошей идеей сделать это, даже если вы не видите каких-либо ошибок компоновщика, иначе вы могли бы использовать опцию компилятора платформы toolset для VS2015 при связывании с библиотеками для VS2012).
Я не знаю, почему это задевает меня, когда я не сталкивался с кем-либо другим, имеющим похожие проблемы. У меня не было проблем с обновлением решений Visual Studio раньше.
Я также не обнаружил, почему некоторые версии Windows Kits теперь содержат заголовки платформы Windows или заголовки библиотек C ++, когда ранее SDK всегда содержал заголовки плат, в то время как заголовки C ++ всегда были частью или установкой Visual Studio. Кажется, что такое изменение должно иметь об этом блог-разработчик где-то или какую-то другую документацию. Но пока это работает, мне все равно.
Читайте также: