На коде какого ядра основан код ядра windows 8

Обновлено: 02.07.2024

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

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

Если после включения серии процессоров в этой спецификации ("перечисленный процессор") процессор станет коммерческим доступом, в котором используется то же соглашение об именовании или идентификатор, что и в списке процессоров, но есть дополнительные или другие функции или функции ("новый процессор"), компания не должна использовать новый процессор для систем клиентов без предварительного письменного разрешения Майкрософт. Если компания считает, что в этом списке отсутствует процессор, обратитесь к корпоративному менеджеру Microsoft OEM или ОДМ Account Manager.

процессоры, перечисленные в таблицах ниже, представляют последние версии и модели процессоров, которые поддерживаются в указанном выпуске Windows.

Некоторые выпуски продукта или конфигурации выпуска или процессора, перечисленные ниже, могут не поддерживаться или быть ограниченными. Сведения о поддержке доступны в разделе Служба поддержки Майкрософт политика и вопросы и ответы о жизненном цикле Майкрософт. Сведения о поддержке конкретных устройств см. на веб-узле поставщика вычислительных систем (OEM).

Windows Процессоры выпуска клиента

Выпуск для Windows	Процессоры AMD	Процессоры Intel	Процессоры Qualcomm
Windows 7 и более ранних выпусков	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Недоступно
Windows 8.1	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Н/Д
Windows 10 Корпоративная LTSB 1507	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Н/Д
Windows 10 1511	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Н/Д
Windows 10 1607	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Н/Д
Windows 10 Корпоративная LTSB 1607	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Н/Д
Windows 10 1703	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Н/Д
Windows 10 1709	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Поддерживаемые процессоры Qualcomm
Windows 10 1803	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Поддерживаемые процессоры Qualcomm
Windows 10 1809	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Поддерживаемые процессоры Qualcomm
Windows 10 Корпоративная LTSC 1809	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Н/Д
Windows 10 1903	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Поддерживаемые процессоры Qualcomm
Windows 10 1909	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Поддерживаемые процессоры Qualcomm
Windows 10 2004	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Поддерживаемые процессоры Qualcomm
Windows 10 20H2	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Поддерживаемые процессоры Qualcomm
Windows 10 21H1	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Поддерживаемые процессоры Qualcomm
Windows 11	Поддерживаемые процессоры AMD	Поддерживаемые процессоры Intel	Поддерживаемые процессоры Qualcomm

Windows Процессоры Интернета вещей Core

Выпуск для Windows	Процессоры Intel	Процессор Qualcomm	Broadcom	Процессоры НКСП
Windows 10 1703	До текущих включенных процессоров Intel Жауле, Atom, Celeron и Pentium [3]	Вплоть до текущих включенных процессоров Qualcomm Снапдрагон [3]	Вплоть до включенных в настоящее время процессоров Broadcom [3]	Н/Д
Windows 10 1709	До текущих включенных процессоров Intel Жауле, Atom, Celeron и Pentium [3]	Вплоть до текущих включенных процессоров Qualcomm Снапдрагон [3]	Вплоть до включенных в настоящее время процессоров Broadcom [3]	Н/Д
Windows 10 1803	До текущих включенных процессоров Intel Жауле, Atom, Celeron и Pentium [3]	Вплоть до текущих включенных процессоров Qualcomm Снапдрагон [3]	Вплоть до включенных в настоящее время процессоров Broadcom [3]	Н/Д
Windows 10 IoT Базовая 1809 (SAC)	Вплоть до текущих включенных процессоров Intel Atom, Celeron и Pentium [3]	Вплоть до текущих включенных процессоров Qualcomm Снапдрагон [3]	Вплоть до включенных в настоящее время процессоров Broadcom [3]	Вплоть до текущего включенного НКСП i. мкспроцессорс [3]
Windows 10 IoT Базовая 1809 (LTSC)	Вплоть до текущих включенных процессоров Intel Atom, Celeron и Pentium [3]	Вплоть до текущих включенных процессоров Qualcomm Снапдрагон [3]	Вплоть до включенных в настоящее время процессоров Broadcom [3]	Вплоть до текущего включенного НКСП i. мкспроцессорс [3]

[3] сведения о том, какие процессоры включены в настоящее время, доступны по адресу </Виндовс/ИОТ-коре/леарн-абаут-Хардваре/соксандкустомбоардс>

Windows 10 IoT Корпоративная

дополнительные сведения о Windows 10 IoT Корпоративная см. в описании обработчиков Windows клиентской версии .

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

Windows Процессоры сервера

Выпуск для Windows	Процессоры Intel	Процессоры AMD	Процессоры хигон [6]
Windows Server 2012 R2 [4]	Вплоть до следующих процессоров Intel 7 поколения (Intel Core i3-7xxx/Celeron/Pentium; Xeon E3 версии 6); Xeon SP 32xx, 42xx, 52xx, 62xx и 82xx; Xeon D 15xx; и Atom C33xx	Вплоть до следующих процессоров поколения AMD 7 (серии & E-9xxx & FX-9xxx), семейства AMD РИЗЕН, AMD ЕПИК 7XX1, AMD ЕПИК 7XX2 и AMD ЕПИК 7xx3	Н/Д
Windows Server 2016 [5]	До 9-го поколения процессоров Intel (Core i3-9xxx, Pentium G5xxx, Celeron G49xx); Xeon E22xx; Xeon SP 32xx, 43xx, 53xx, 63xx и 83xx; Xeon D 21xx; и Atom C33xx	Вплоть до следующих процессоров поколения AMD 7 (серии & E-9xxx & FX-9xxx), семейства AMD РИЗЕН, AMD ЕПИК 7XX1, AMD ЕПИК 7XX2 и AMD ЕПИК 7xx3	Н/Д
Windows Server 2019	До 9-го поколения процессоров Intel (Core i3-9xxx, Pentium G5xxx, Celeron G49xx); Xeon E23xx; Xeon SP 32xx, 43xx, 53xx, 63xx и 83xx; Xeon D 21xx; и Atom C33xx	Вплоть до следующих процессоров поколения AMD 7 (серии & E-9xxx & FX-9xxx), семейства AMD РИЗЕН, AMD ЕПИК 7XX1, AMD ЕПИК 7XX2 и AMD ЕПИК 7xx3	Хигон C86 7xxx
Windows Server 2022	До 9-го поколения процессоров Intel (Core i3-9xxx, Pentium G5xxx, Celeron G49xx); Xeon E23xx; Xeon SP 32xx, 43xx, 53xx, 63xx и 83xx; Xeon D 21xx; и Atom C33xx	Вплоть до следующих процессоров поколения AMD 7 (серии & E-9xxx & FX-9xxx), семейства AMD РИЗЕН, AMD ЕПИК 7XX1, AMD ЕПИК 7XX2 и AMD ЕПИК 7xx3	Н/Д

[4] список процессоров для Windows Server 2012 R2 является окончательным. Новые системные отправки больше не принимаются для сертификации.

[6] только на рынке Китая

Примечание. приведенный выше список поддерживаемых процессоров не определяет службу поддержки майкрософт для Windows Server. Список является необходимым условием для сертификации системы. только системы, основанные на указанных выше одобренных процессорах, могут быть сертифицированы для Windows Server. Если не указано иное, корпорация Майкрософт будет по-прежнему оценивать список процессоров для определенного выпуска ОС и обновлять список, так как новые соответствующие процессоры доступны на рынке.

Windows – одна из наиболее многогранных и гибких ОС, она работает на совершенно разных архитектурах и доступна в разных вариантах. На сегодня она поддерживает архитектуры x86, x64, ARM и ARM64. Windows в своё время поддерживала Itanium, PowerPC, DEC Alpha и MIPS. Кроме того, Windows поддерживает целый набор SKU, работающих в различных условиях; от дата-центров, ноутбуков, Xbox и телефонов до встраиваемых версий для интернета вещей, например, в банкоматах.

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

В этой статье я расскажу об эволюции ключевых частей ядра Windows, которые позволяют ему прозрачно масштабироваться от чипа NVidia Tegra низкого потребления, работающего на Surface RT 2012 года, до гигантских монстров, работающих в дата-центрах Azure.

Менеджер задач Windows, работающий на пререлизной машине класса Windows DataCenter, с 896 ядрами, поддерживающими 1792 логических процессора и 2 Тб памяти

Эволюция единого ядра

Перед тем, как обсудить детали ядра Windows, сделаем небольшое отступление в сторону рефакторинга. Рефакторинг играет ключевую роль в увеличении случаев повторного использования компонентов ОС на различных SKU и платформах (к примеру, клиент, сервер и телефон). Базовая идея рефакторинга – позволить повторно использовать одни и тем же DLL на разных SKU, поддерживая небольшие модификации, сделанные специально под нужный SKU, не переименовывая DLL и не ломая работу приложений.

Базовая технология рефакторинга Windows – мало документированная технология под названием "наборы API". Наборы API – это механизм, позволяющий ОС разъединять DLL и место их применения. К примеру, набор API позволяет приложениям для win32 продолжать пользоваться kernel32.dll, притом, что реализация всех API прописана в другой DLL. Эти DLL с реализацией также могут отличаться у разных SKU. Посмотреть наборы API в деле можно, запустив обход зависимостей на традиционной Windows DLL, например, kernel32.dll.

Закончив это отступление по поводу строения Windows, позволяющего системе максимизировать повторное и совместное использование кода, перейдём к техническим глубинам запуска ядра по планировщику, являющегося ключом к масштабированию ОС.

Компоненты ядра

Windows NT – это, по сути, микроядро, в том смысле, что у него есть своё core Kernel (KE) с ограниченным набором функций, использующее исполняемый уровень (Executive layer, Ex) для выполнения всех политик высокого уровня. EX всё ещё является режимом ядра, так что это не совсем микроядро. Ядро отвечает за диспетчеризацию потоков, синхронизацию между процессорами, обработку исключений аппаратного уровня и реализацию низкоуровневых функций, зависящих от железа. Слой EX содержит различные подсистемы, обеспечивающие набор функциональности, который обычно считается ядром – IO, Object Manager, Memory Manager, Process Subsystem, и т.д.

Чтобы лучше представить себе размер компонентов, вот примерное разбиение по количеству строк кода в нескольких ключевых каталогах дерева исходников ядра (включая комментарии). В таблицу не вошло ещё много всего, относящегося к ядру.

Подсистемы ядра	Строк кода
Memory Manager	501, 000
Registry	211,000
Power	238,000
Executive	157,000
Security	135,000
Kernel	339,000
Process sub-system	116,000

Более подробная информация об архитектуре Windows содержится в серии книг “Windows Internals”.

Планировщик

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

Поток – это базовая единица, исполняющая программный код, и именно её работу планирует планировщик Windows. Решая, какой из потоков запустить, планировщик использует их приоритеты, и в теории, поток с наивысшим приоритетом должен запускаться на системе, даже если это означает, что потокам с более низким приоритетам времени не останется.

У планировщика Windows изначально была одна очередь готовности, из которой он выбирал следующий, наивысший по приоритету поток для запуска. Однако с началом поддержки всё большего количества процессоров, единственная очередь превратилась в узкое место, и примерно в районе выхода Windows Server 2003 планировщик поменял работу и организовал по одной очереди готовности на процессор. При переходе на поддержку нескольких запросов на один процессор единую глобальную блокировку, защищающую все очереди, делать не стали, и разрешили планировщику принимать решения на основе локальных оптимумов. Это означает, что в любой момент в системе работает один поток с наивысшим приоритетом, но не обязательно означает, что N самых приоритетных потоков в списке (где N – число процессоров) работают в системе. Такой подход оправдывал себя, пока Windows не начала переходить на CPU с низким энергопотреблением, например, на ноутбуки и планшеты. Когда на таких системах поток с наивысшим приоритетам не работал (например, поток переднего плана интерфейса пользователя), это приводило к заметным глюкам интерфейса. Поэтому в Windows 8.1 планировщик перевели на гибридную модель, с очередями для каждого процессора для потоков, связанных с этим процессором, и разделяемой очередью готовых процессов для всех процессоров. Это не сказалось на быстродействии заметным образом благодаря другим изменениям в архитектуре планировщика, например, рефакторингу блокировки базы данных диспетчера.

В Windows 7 ввели такую вещь, как динамический планировщик со справедливыми долями (Dynamic Fair Share Scheduler, DFSS); это в первую очередь касалось терминальных серверов. Эта особенность пыталась решить проблему, связанную с тем, что одна терминальная сессия с высокой загрузкой CPU могла повлиять на потоки в других терминальных сессиях. Поскольку планировщик не учитывал сессии и просто использовал приоритет для распределения потоков, пользователи в разных сессиях могли повлиять на работу пользователей в других сессиях, задушивая их потоки. Также это давало несправедливое преимущество сессиям (и пользователям) с большим количеством потоков, поскольку у сессии с большим количеством потоков было больше возможностей получить процессорное время. Была сделана попытка добавить в планировщик правило, по которому каждую сессию рассматривали на равных с другими по количеству процессорного времени. Подобная функциональность есть и в ОС Linux с их абсолютно честным планировщиком (Completely Fair Scheduler). В Windows 8 эту концепцию обобщили в виде группы планировщика и добавили в планировщик, в результате чего каждая сессия попадала в независимую группу. Кроме приоритетов для потоков, планировщик использует группы планировщика как индекс второго уровня, принимая решение по поводу того, какой поток запускать следующим. В терминальном сервере все группы планировщика имеют одинаковый вес, поэтому все сессии получают одинаковое количество процессорного времени вне зависимости от количества или приоритетов потоков внутри групп планировщика. Кроме того, такие группы также используют для более точного контроля над процессами. В Windows 8 рабочие объекты (Job) были дополнены так, чтобы поддерживать управление процессорным временем. При помощи специального API можно решать, какую часть процессорного времени может использовать процесс, должно это быть мягкое или жёсткое ограничение, и получать уведомления, когда процесс достигает этих ограничений. Это похоже на управление ресурсами в cgroups на Linux.

Начиная с Windows 7, в Windows Server появилась поддержка более 64 логических процессоров на одном компьютере. Чтобы добавить поддержку такому большому количеству процессоров, в системе ввели новую категорию, «процессорная группа». Группа – неизменный набор логических процессоров количеством не более 64 штук, которые рассматриваются планировщиком как вычислительная единица. Ядро при загрузке определяет, какой процессор к какой группе отнести, и у машин с количеством процессорных ядер менее 64 этот подход практически невозможно заметить. Один процесс может разделяться на несколько групп (например, экземпляр SQL-сервера), единственный поток в один момент времени может выполняться только в рамках одной группы.

Но на машинах, где число ядер CPU превышает 64, Windows начала демонстрировать новые узкие места, не дававшие таким требовательным приложениям, как SQL-сервер, масштабироваться линейно с ростом количества ядер процессора. Поэтому, даже при добавлении новых ядер и памяти, замеры скорости не показывали её существенного увеличения. Одной из главных проблем, связанных с этим, был спор по поводу блокировки базы диспетчера. Блокировка базы диспетчера защищала доступ к объектам, работу которых необходимо было запланировать. Среди этих объектов – потоки, таймеры, порты ввода/вывода, другие объекты ядра, подверженные ожиданию (события, семафоры, мьютексы). Под давлением необходимости разрешения таких проблем, в Windows 7 была проделана работа по устранению блокировки базы диспетчера и замене её на более точные подстройки, например, пообъектную блокировку. Это позволило таким замерам производительности, как SQL TPC-C, продемонстрировать рост скорости на 290% по сравнению с предыдущей схемой на некоторых конфигурациях. Это был один из крупнейших взлётов производительности в истории Windows, случившихся благодаря изменению единственной особенности.

Windows 10 принесло другую инновацию, внедрив наборы процессоров (CPU Sets). CPU Sets позволяют процессу разделять систему так, что процесс может распределиться на несколько групп процессоров, не позволяя другим процессам пользоваться ими. Ядро Windows даже не даёт прерываниям устройств пользоваться процессорами, входящими в ваш набор. Это гарантирует, что даже устройства не смогут исполнять свой код на процессорах, выданных группе вашего приложения. Это похоже на низкотехнологичную виртуальную машину. Понятно, что это мощная возможность, поэтому в неё встроено множество мер безопасности, чтобы разработчик приложения не допустил больших ошибок, работая с API. Функциональность наборов CPU используется в игровом режиме (Game Mode).

Наконец, мы приходим к поддержке ARM64, появившейся у Windows 10. Архитектура ARM поддерживает архитектуру big.LITTLE, гетерогенную по своей природе – «большое» ядро работает быстро и потребляет много энергии, а «малое» ядро работает медленно и потребляет меньше. Идея в том, что малозначительные задачи можно выполнять на малом ядре, экономя таким образом батарею. Для поддержки архитектуры big.LITTLE и увеличения времени работы от батареи при работе Windows 10 на ARM, в планировщик добавили поддержку гетерогенной планировки, учитывающую пожелания приложения, работающего с архитектурой big.LITTLE.

Под пожеланиями я имею в виду то, что Windows старается качественно обслуживать приложения, отслеживая потоки, выполняющиеся на переднем плане (или те, которым не хватает процессорного времени), и гарантируя их выполнение на «большом» ядре. Все фоновые задачи, сервисы, другие вспомогательные потоки выполняются на малых ядрах. Также в программе можно принудительно отметить маловажность потока, чтобы заставить его работать на малом ядре.

Работа от чужого имени [Work on Behalf]: в Windows довольно много работы на переднем плане осуществляется другими сервисами, работающими в фоне. К примеру, при поиске в Outlook сам поиск проводится фоновым сервисом Indexer. Если мы просто запустим все сервисы на малом ядре, пострадает качество и скорость работы приложений на переднем плане. Чтобы при таких сценариях работы она не замедлялась на архитектурах big.LITTLE, Windows отслеживает вызовы приложения, поступающие к другим процессам, чтобы выполнять работу от их имени. В таком случае мы выдаём приоритет переднего плана потоку, относящемуся к сервису, и заставляем его выполняться на большом ядре.

На этом позвольте закончить первую статью о ядре Windows, дающую обзор работы планировщика. Статьи со сходными техническими подробностями о внутренней работе ОС последуют позже.

Windows 8 – новейшая операционная система от корпорации Microsoft, предназначенная для использования на персональных компьютерах, в том числе с сенсорными дисплеями.

Разработка Windows 8 началась в 2009 году и впервые система была анонсирована в январе 2011 года, а в сентябре того же года представлена предварительная версия для разработчиков Windows 8 Developer Preview . В феврале 2012 года выпускается предварительная версия Windows 8 Consumer Preview , в мае – Windows 8 Release Preview . В августе 2012 становится доступной окончательная версия Windows 8 для подписчиков MSDN и TechNet. Официальная дата начала продаж назначена на 26 октября 2012 года.

Ядро Windows 8 имеет номер версии 6.2 и его код основан на коде ядра Windows 7 (имеющего номер версии 6.1) с небольшими изменениями.

Основные особенности

Интерфейс

Самым заметным отличием новой системы от Windows 7 является, конечно, интерфейс Modern UI, который используется при старте системы вместо привычного рабочего стола (рис.3.1).

Впервые Modern UI появился в Windows Phone 7 в 2010 году. Принцип, используемый в этом интерфейсе, – на первом месте содержание, а не графическое оформление. Поэтому в Modern UI минимизировано использование элементов интерфейса – кнопок и меню; вместо иконок используются плитки (tiles), внутри которых текст выводится при помощи легко читаемых шрифтов, а для динамичного отображения информации широко используется анимация.

Традиционный рабочий стол также присутствует – его можно вызвать, щелкнув на плитку Desktop. Обратно к интерфейсу Modern UI можно вернуться, подведя указатель мыши в левый нижний угол экрана (один из четырех "активных углов") или нажав кнопку Windows на клавиатуре.

Другим изменением в интерфейсе стало использование Ribbon Interface (Ленточный интерфейс) в Проводнике Windows (рис.3.2).

Учетные записи

С помощью использования Live ID доступна функция семейной безопасности и родительского контроля (Microsoft Family Safety).

Безопасность

Программа Защитник Windows (Windows Defender), которая ранее обладала только антишпионскими функциями, теперь стала ещё и антивирусом.

Поддерживается механизм безопасной загрузки на системах с UEFI (Unified Extensible Firmware Interface – унифицированный расширенный интерфейс для встроенного программного обеспечения; стандарт, предназначенный для замены BIOS), путем проверки целостности загрузчика Windows. Таким образом, предотвращаются попытки вредоносных программ перехватить управление до загрузки системы.

Диспетчер задач

Диспетчер задач (Task Manager) существенно изменен по сравнению с предыдущими версиями: добавлены подробности по текущему использованию ресурсов, добавлена вкладка Автозапуск (Startup), добавлена вкладка истории использования приложениями различных ресурсов (App history) (рис.3.3).

История файлов

Функция История файлов (File history) автоматически сохраняет копии изменяемых файлов, так что при необходимости можно откатить изменения и вернуться к старым версиям файлов.

Восстановление системы

Добавлены две функции по восстановлению системы без использования носителей с дистрибутивом – Обновление (Refresh) и Сброс (Reset). При Обновлении система переустанавливается с сохранением пользовательских файлов и настроек; при Сбросе диск форматируется и система устанавливается с нуля.

Storage Spaces

Функция Storage Spaces позволяет объединять физические диски, построенные по разным технологиям (SATA, USB, SAS), в единый виртуальный диск с автоматическим резервированием информации.

Версии Windows 8

Планируется выпуск четырех версий Windows 8:

Windows 8 – базовая версия для 32 разрядных (x86) и 64 разрядных (x64) платформ;
Windows 8 Pro – версия для продвинутых и бизнес-пользователей. В неё будут добавлены поддержка доменов Windows, групповые политики, шифрование файлов, технологии виртуализации;
Windows 8 Enterprise – версия для корпоративных пользователей. Присутствуют все возможности Windows 8 Pro и добавляются следующие технологии: Windows To Go (возможность загрузки с переносных устройств – внешних жестких дисков и флеш дисков), DirectAccess (простой и безопасный доступ к ресурсам корпоративной сети через Интернет), BranchCache (кэширование файлов корпоративной сети), AppLocker (гибкое управление разрешениями на запуск приложений);
Windows RT – версия, которая будет поддерживать мобильные процессоры ARM. Будет доступна только как предварительно установленная операционная система на компьютерах с ARM процессорами. В состав системы будет входить пакет Microsoft Office Home & Student 2013 RT.

Минимальные системные требования для Windows 8 практически совпадают с требованиями для Windows 7:

процессор не менее 1 ГГц;
оперативная память не менее 1 ГБ для 32 разрядных систем, 2 ГБ для 64 разрядных;
свободное пространство на жестком диске не менее 20 ГБ;
видеокарта с поддержкой DirectX 9 и с WDDM драйвером.

Разработка приложений для Windows 8

Для Windows 8 стала возможной разработка нового типа Windows приложений – приложений в стиле Modern UI (см. раздел на MSDN [MSDN Apps]).

Особенности приложений в стиле Modern UI

У приложений в стиле Modern UI есть ряд особенностей, которые отличают их от традиционных Windows-приложений:

наличие одного окна – приложение имеет одно окно, по умолчанию развернутое на весь экран, лишенное необязательных элементов интерфейса;
поддержка сенсорного ввода – Windows 8 предоставляет приложениям средства для поддержки ввода с разных устройств – клавиатуры, мыши, пера, сенсорной панели;
контракты приложений – приложения могут объявлять поддержку контрактов – соглашений по предоставлению определенных сервисов. В Windows 8 поддерживается несколько контрактов:
- поиск (Search) – соглашение о возможности поиска по содержимому;
- общий доступ (Sharing) – соглашение о предоставлении своего содержимого другим приложениям;
- воспроизведение (Play To) – соглашение о передаче данных из приложения на устройство воспроизведения;
- выбор между приложениями (App to App picking) – соглашение о возможности напрямую выбирать файлы;
- параметры (Settings) – соглашение о доступности параметров приложения;
- печать (Print) – соглашение о возможности печати на любом совместимом принтере;
- строка команд приложения (App bar) – располагается внизу экрана, вызывается как контекстное меню. В этой строке можно размещать основные команды приложения (рис.3.4);
- панель Charms – располагается в правой части экрана и содержит кнопки для поиска, общего доступа, вызова начального экрана, работы с устройствами и работы с параметрами (рис.3.5).
Рис. 3.4. Пример строки команд (App bar) для музыкального проигрывателя

Инструменты

Для интеграции приложения с сервисами Hotmail, Windows Live Messenger, Microsoft SkyDrive и др. применяется Live SDK – набор специализированных API для доступа к информации пользователя этих сервисов.

Для более подробной информации см. [MSDN Apps; Лутай и др.; Techdays].

Резюме

Рассмотрены ключевые особенности и версии новейшей операционной системы Microsoft Windows 8. Приводится также информация о разработке приложений в стиле нового интерфейса Modern UI.

В следующей лекции мы переходим к изучению внутреннего устройства Windows и начинаем с рассмотрения архитектуры системы.

Чтобы разобраться вопросе, насколько может быть сложным программный код «Виндовс» мы обратились к одному из разработчиков команды Windows NT в компании Microsoft — Кену Греггу (Ken Gregg).

Кен Грегг (Ken Gregg), разработчик в составе группы Windows NT

«Могу сказать вам, что у меня был доступ к исходному коду, когда я был в команде Windows NT (NT является основой для всех настольных версий Windows начиная с XP), во время проектов разработки NT 3.1 и NT 3.5. Всё было в рамках стандартов кодирования NT Workbook — эдакой «библии» для всей проектной команды.

. Хотя я и не читал каждую строку кода, но то, с чем мне пришлось работать, было очень:
- чётким,
- модульным,
- многоуровневым,
- обслуживаемым».
Нужно исходить из того, что именно понимается под сложностью кода. Это понимание сугубо субъективное, ведь так? Благо существует множество различных метрик, используемых и комбинируемых для измерения сложности программного обеспечения в тех или иных ситуациях (та же самая модульность, многоуровневость и обслуживаемость).

Насколько сложна Windows в программном коде?

Конечно, чтобы прочитать и понять код, вам нужно было бы иметь представление об общей архитектуре Windows NT.

Вероятно, лучшим источником информации о внутренностях Windows сегодня являются книги Windows Internals 6th Edition (в двух томах).

Некоторые люди просто приравнивают сложность кода к размеру. У этого сравнения тоже есть метрика — строки кода (LOC).

Измерение LOC зависит от используемых инструментов и критериев. Их выбирают для точного определения строк кода на каждом языке программирования.

Кен Грегг (Ken Gregg)

«Существует много споров о методах, используемых для подсчета строк кода (LOC). Если использовать одни и те же критерии от одного выпуска к следующему, то получится относительное изменение размера базы кода.

Сравнивать эти числа с цифрами другой ОС, которая использовала другой метод подсчета строк кода, всё равно что сравнивать яблоки с апельсинами. То есть это некорректный подход».

Как менялся программный код Windows?

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

Как база кода Windows NT развивалась с 1993 года

MLOC — это количество миллионов строк исходного кода. По ним можно определить относительную сложность операционной системы, если опираться на размеры кода (LOC-методика).
- Windows NT 3.1 (1993) - 5,6 MLOC
- Windows NT 3.5 (1994) - 8,4 MLOC
- Windows NT 3.51 (1995) - 10,2 MLOC
- Windows NT 4.0 (1996) - 16 MLOC
- Windows 2000 (2000) - 29 MLOC
- Windows XP (2001) - 35 MLOC
- Windows Vista (2007) - 45 MLOC
- Windows 7 (2009) - 42 MLOC
- Windows 8 (2012) - 50 MLOC
- Windows 10 (2015) - 55 MLOC
Исходный код Windows состоит в основном из C и C++, а также небольшого количества кода на ассемблере.

Некоторые из утилит пользовательского режима и другие подобные службы пишутся на Си Шарп, но это относительно небольшой процент от общей базы кода.

Кен Грегг (Ken Gregg)

«Я намеренно не включил в список 16-битные версии ОС, выпущенные с 1985 по 2000 годы. Windows NT была основой для всех современных 32-бит и 64-бит версий Windows. Количество строк кода в серверных версиях было таким же, как и в несерверных версиях, выпущенных в том же году (то есть они имели одинаковую базу исходного кода)».

Несколько слов про ядро Windows NT

По словам Кена, работа над ядром NT началась в 1988 году. Ядро было создано с нуля в качестве 32-разрядной упреждающей многозадачной ОС.

Ядро NT впервые загрузилось в июле 1989 года на процессоре Intel i860 RISC. С самого начала был сильный толчок к тому, чтобы новая ОС была совместимой с различными архитектурами центральных процессоров и не была привязана только к архитектуре Intel x86 (IA-32).

NT в конечном итоге работал на MIPS, DEC Alpha, PowerPC, Itanium и, конечно, Intel x86 и x64.

Некоторая сложность была добавлена в базу кода на уровне абстрагирования оборудования (HAL). Это было нужно для поддержки неинтеловских архитектур.

А как вы оцениваете перспективы Windows в плане кода? Узнайте, какие версии Windows актуальны сейчас и какие ОС можно рассмотреть в качестве альтернативы.
Компания ZEL-Услуги
Есть проблемы при использовании Windows и непонятен программный код для внедрения новых бизнес-инструментов в ОС от Microsoft? Проконсультируйтесь с экспертами по ИТ-аутсорсингу и получите поддержку по любым техническим вопросам и задачам.

Сегодня я решил показать Вам различия между ядрами операционных систем Windows и Linux.

Начнем с относительно простого ядра Linux.

Обсуждать тут в принципе нечего - любая программа через системные вызовы обращается к ядру ОС через интерфейс системных вызовов. Ядро через архитектурно зависимый код транслирует команды аппаратному обеспечению. Все это очень просто и быстро, единственное что заслуживает внимание - то что программы "видят" себя в едином виртуальном окружении независимо от архитектуры системы. Структура и системные вызовы стандартизированы и едины для любой аппаратной платформы. Графичесая подсистема является одной из внешних программ, поэтому сменить графическую оболочку можно без перезагрузки ОС. Кстати о графических оболочках:

Теперь перейдем к Windows:

Как видим структура ядра намного более сложная. Преимущество это или недостаток? Каждый решает для себя сам. Программа под Windows обращается через документированный Windows API к "своей" библиотеке (например Kernel32.dll, Advapi32.dll, User32.dll, Gdi32.dll), эти библиотеки по внутреннему протоколу (документация для разработчиков не из Microsoft не доступна) обращается по протоколу Native API к Ntdll.dll и далее передается через диспетчер системных сервисов ядру (все это внутри Ntoskrnl.exe).

После обработки в режиме ядра и использованию драйверов данные передаются Hal.dll - библиотеке которая непосредственно управляет оборудованием. Второй системой управляющей оборудованием является графическое ядро (проприетарные функции видеокарт в основном касаются именно этого).

Важно отметить одну особенность пользовательского режима ядра Windows - "Подсистемы окружения". Эта компонента позволяет Windows использовать коды стандартов POSIX, Win16 и т.п. Данный механизм по сути является набором виртуальных ядер сторонних ОС и позволяет быстро адаптировать под Windows любой сторонний код.

Не менее важным является включение графической подсистемы в ядро (в современных серверных ОС данная система отключена или отсутствует), что во-первых не дает сменить графическую оболочку "на ходу", а во-вторых уже не способствует быстродействию.

На анализе архитектур можно сделать вывод, что ядро ОС Linux принципиально обеспечивает наилучшее быстродействие и надежность за счет своей монолитности, а ядро Windows позволяет быстро адаптировать любой стороний код для совместимости с операционной системой, однако такая адаптация имеет свою цену - систему приходится перезагружать по любому мало-мальскому поводу.

Читайте также: