Какой тип ядра используется в Windows XP?

Windows – одна из наиболее многогранных и гибких ОС, она работает на совершенно разных архитектурах и доступна в разных вариантах. На сегодня она поддерживает архитектуры x86, x64, ARM и ARM64....

Какой тип ядра используется в Windows XP?

Единое ядро Windows

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. Решая, какой из потоков запустить, планировщик использует их приоритеты, и в теории, поток с наивысшим приоритетом должен запускаться на системе, даже если это означает, что потокам с более низким приоритетам времени не останется.

Проработав квантовое время (минимальное количество времени, которое может работать поток), поток испытывает уменьшение динамического приоритета, чтобы потоки с высоким приоритетом не могли работать вечно, душа всех остальных. Когда для работы пробуждается другой поток, ему повышают приоритет, рассчитанный на основе важности события, из-за которого произошло ожидание ( например, приоритет сильно повышается для находящегося на переднем плане интерфейса пользователя, и несильно – для завершения операций ввода/вывода). Поэтому поток работает с высоким приоритетом, пока он остаётся интерактивным. Когда он становится связанным преимущественно с вычислениями (CPU-bound), его приоритет падает, и к нему возвращаются уже после того, как другие потоки с высоким приоритетом получат своё процессорное время. Кроме того, ядро произвольным образом увеличивает приоритет готовых потоков, не получивших процессорного времени за определённый промежуток, чтобы предотвратить их вычислительное голодание и подправить инверсию приоритетов.

У планировщика 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 XP?

Структура операционной системы.

Архитектура операционных систем Windows XP и Windows Server 2003 является модульной. Структурно ее можно разделить на две части.
Первая часть работает в режиме ядра (kernel mode) и называется исполнительной системой Windows (Windows executive). Компоненты режима ядра обладают следующими функциональными возможностями:

  • имеют доступ к оборудованию;
  • имеют прямой доступ ко всем видам памяти компьютера;
  • не выгружаются на жесткий диск в файл подкачки;
  • имеют более высокий приоритет, нежели процессы режима пользователя.
Читайте также  Где хранится история Internet Explorer Windows 7?

Вторая часть работает в так называемом режиме пользователя (user mode) Эту часть составляют защищенные подсистемы ОС. Особенности процессов пользовательского режима:

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

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

В Windows два типа защищенных подсистем.

1. Подсистемы среды. Под такими подсистемами понимаются программы-серверы пользовательского режима, реализующие программный интерфейс некоторой операционной системы. Главнейшей подсистемой этого типа является Win32. К ее функциям относятся:

  • предоставление приложениям стандартного программного интерфейса к функциям ОС;
  • реализация графического пользовательского интерфейса;
  • управление пользовательским вводом/выводом.

К подсистемам среды относятся также подсистемы POSIX и OS/2.

2. Внутренние подсистемы. К этому типу относятся подсистемы, выполняющие важные функции ОС. Вот основные.

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

Исполнительная система и уровень абстрагирования от оборудования.

В состав исполнительной системы входят следующие элементы.

  • Справочный монитор защиты (Security Reference Monitor, SRM). Гарантирует выполнение политики защиты на локальном компьютере. Оберегает ресурсы ОС, обеспечивая защиту объектов и аудит доступа к ним.
  • Диспетчер процессов (Process Manager). Создает и завершает процессы и потоки. Кроме того, приостанавливает и возобновляет исполнение потоков, хранит и выдает информацию о процессах и потоках NT.
  • Диспетчер межпроцессного взаимодействия (Interprocess Communication Manager, IPC Manager). Обеспечивает взаимодействие между подсистемами режима пользователя и исполнительной подсистемы.
  • Диспетчер виртуальной памяти (Virtual memory manager, VMM). Реализует виртуальную память — схему управления памятью, которая предоставляет каждому процессу большое собственное адресное пространство и защищает это пространство от других процессов.
  • Ядро (Kernel). Реагирует на прерывания и исключения, выполняет межпроцессорную синхронизацию и предоставляет набор элементарных объектов и интерфейсов, используемый остальными частями исполнительной системы для реализации объектов более высокого уровня.
  • Подсистема ввода/вывода (I/O Subsystem). Состоит из группы компонентов, отвечающих за выполнение ввода/вывода на разнообразные устройства. Подробнее подсистема ввода/вывода рассматривается в следующих разделах.
  • Диспетчер объектов (Object manager). Создает, поддерживает и уничтожает объекты исполнительной системы Windows — абстрактные типы данных, представляющие системные ресурсы.
  • Диспетчер электропитания (Advanced Configuration and Power Interface Manager, ACPI-manager). Управляет электропитанием устройств, координирует запросы устройств, связанные с изменением режима электропитания.
  • Диспетчер Plug and Play (PnP-manager). Обеспечивает распознавание PnP-устройств после процесса загрузки ОС, управляет их драйверами, предоставляет интерфейс средствам пользовательского режима для поиска устройств, их установки и удаления, а также остановки и возобновления их работы.
  • Диспетчер окон и интерфейс графических устройств (Graphic Device Interface, GDI). Управляет отображением окон, обеспечивает прием ввода от клавиатуры и мыши, распределяя информацию приложениям.

Компоненты исполнительной системы реализованы как независимые от аппаратной платформы модули. Это обеспечивается наличием уровня абстрагирования от оборудования и делает ОС максимально переносимой.
Уровень абстрагирования от оборудования (Hardware Abstract Level, HAL). Представляет собой программную прослойку между исполнительной системой Windows и аппаратной платформой, на которой работает ОС. HAL скрывает аппаратно-зависимые детали, такие как интерфейсы ввода/вывода, контроллеры прерываний и механизмы межпроцессорных связей. Вместо того чтобы обращаться к аппаратуре непосредственно, исполнительная система Windows вызывает функции HAL.

Системный реестр Windows.

В операционной системе Windows практически вся конфигурационная информация (приложений, служб, параметров оборудования и т. п.) хранится в системном реестре (System Registry).
Эти компоненты реестра наглядно показаны на рисунке.

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

Поддеревья включают разделы. Разделы и подразделы, в свою очередь, могут включать подразделы и параметры. Разделы и параметры могут быть двух типов.

Реестр представляет собой иерархическую структуру, состоящую из поддеревьев, разделов, подразделов и параметров. Для просмотра и редактирования системного реестра Windows предусмотрены две специализированных программы — regedit и regedt32.

Использование реестра компонентами Windows.

Ниже приведены сведения об использовании системного реестра основными компонентами и приложениями Windows.

Организация системного реестра.

Верхний уровень иерархии системного реестра составляют поддеревья. Поддеревья включают разделы. Разделы и подразделы, в свою очередь, могут включать подразделы и параметры.

Реестр Windows содержит два поддерева: HKEY_LOCAL_MACHINE (хранящее параметры настройки компьютера и общие параметры настройки ПО и ОС) и HKEY_CURRENT_USER (хранящее параметры настройки ПО и ОС текущего пользователя). Однако, чтобы облегчить поиск сведений в реестре, программы редактирования реестра выводят пять поддеревьев, которые перечислены ниже.

Поддерево реестра Описание
HKEY_LOCAL_MACHINE Содержит информацию о конфигурации оборудования компьютера, ОС и ПО. Параметры конфигурации ПО являются общими для всех пользователей компьютера
HKEY_CLASSES_ROOT Содержит информацию о конфигурации COM-компонентов и OLE-объектов. Является ссылкой на разделы HKEY_LOCAL_MACHINESOFTWAREClasses и HKEY_CURRENT_USERSOFTWAREClasses . Если какое-либо значение существует в обоих разделах, то значение из поддерева HKEY_CURRENT_USER перекрывает значение из поддерева HKEY_LOCAL_MACHINE
HKEY_CURRENT_USER Содержит информацию о конфигурации ОС и ПО для пользователя, работающего в системе в данный момент. Является ссылкой на раздел HKEY_USERS идентификатор_безопасности_пользователя
HKEY_USERS Содержит информацию о конфигурации ОС и ПО для пользователей, работающих в системе в данный момент, а также информацию о конфигурации для профиля пользователя по умолчанию
HKEY_CURRENT_CONFIG Содержит информацию о текущей аппаратной конфигурации компьютера. Является ссылкой на раздел HKEY_LOCAL_MACHINESYSTEMCurrentControlSetHardware ProfilesCurrent

Поведение поддерева HKEY_CLASSES_ROOT различается в Windows 2000 и более ранних версиях. В Windows 2000 поддерево HKEY_CLASSES_ROOT ссылается на раздел HKEY_CURRENT_USERSOFTWAREClasses конкретного пользователя, что позволяет пользователям иметь индивидуально зарегистрированные или настроенные COM-компоненты. Изменения, вносимые в это поддерево, будут фиксироваться в разделе реестра соответствующего пользователя. В предыдущих версиях Windows изменения вносились в раздел HKEY_LOCAL_MACHINESOFTWAREClasses, что позволяло одному пользователю системы изменять параметры компонентов, зарегистрированных другими пользователями.

Кусты и файлы реестра

Куст описывает древовидную структуру непрерывного связанного набора разделов, подразделов и параметров, выходящую из вершины иерархии реестра. Куст хранится на диске в виде отдельного файла и имеет отдельный журнал. Файлы реестра хранятся в папках %systemroot%system32Config (системная часть) и %userprofile% (пользовательская часть).
Каждый куст реестра представлен на диске в виде двух стандартных файлов, перечисленных в таблице.

Куст реестра

Файлы

Каждый раздел реестра содержит элементы данных, называемые параметрами. Некоторые параметры хранят сведения, характерные для отдельного пользователя, другие — применимые ко всем пользователям компьютера.

Каждый параметр имеет три характеристики:

  • имя параметра — используется приложениями для обращения к конкретному параметру;
  • тип данных параметра — описывает, данные какого типа хранит параметр;
  • значение параметра — непосредственно данные, которые могут быть получены при обращении к параметру.

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

Тип данных

Описание

Данные в двоичном формате. Обычно этот тип используется для хранения больших объемов данных, например параметров оборудования

Целое число без знака. На хранение отводится 4 байта, чем определяется минимальное (0) и максимальное (4 294 967 296) хранимое значение. Обычно этот тип используется для хранения числовых величин и значений различных флагов

Строка с символами подстановки. Используется для хранения строковых значений, при считывании которых осуществляется преобразование символов подстановки. Например, при считывании значения %homedrive% Users and Settings%username% возвращается c:Documents and SettingsUser1

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

Строка символов. Используется для хранения различных простых неинтерпретируемых строковых значений

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

Архитектура UNIX и Windows

Архитектура UNIX

Виртуальная память была изобретена в 1962 году, в Англии при создании суперкомпьютера Atlas. В большинстве современных компьютеров оперативная память не так велика, как используемое процессором адресное пространство. Размер ОЗУ типичного персонального компьютера варьируется от десятков до сотен мегабайт. При запуске программа загружается с какого-либо накопителя в оперативную память. Если же программа не помещается в ОЗУ, то те её части, которые в данный момент не выполняются, хранятся во вторичном запоминающем устройстве, чаще всего винчестере, и такая память называется виртуальной. Безусловно, перед выполнением необходимая часть программы должна быть перемещена в оперативную память. Данные функции выполняет ядро операционной системы (диспетчер виртуальной памяти, находящийся в микроядре). И для программы и для пользователя эти действия прозрачны. Естественно, на запросы к виртуальной памяти уходит гораздо большее время, нежели к ОЗУ.

Windows 2000/XP построены на архитектуре микроядра (microkernel architecture). ОС Windows 95/98 используют монолитное (monolithic) ядро. Микроядра являются сравнительно небольшими и модульными. Благодаря последнему новые устройства зачастую добавляются как модули, которые можно загружать/выгружать на этапе исполнения без перекомпиляции ядра. На архитектуре микроядра построены также FreeBSD и Mac OS X. Монолитные же ядра используются еще и в Linux. Они оптимизированы для более высокой производительности с минимальными контекстными переключениями. Такая архитектура упрощает поддержку кода ядра для разработчиков, но требует перекомпиляции ядра при добавлении новых устройств. Следует отметить, что описанные здесь различия являются «классическими», на практике монолитные ядра могут поддерживать модульность (что зачастую и происходит), а микроядра могут требовать перекомпиляции.

Архитектура Windows

Ядро UNIX/Linux имеет два вида исключений, которые обычно называют «oops» и «panic». Почти в каждой операционной системе паника происходит в тех случаях, когда ядро обнаруживает серьезную неисправность. Если система каким-либо образом повредила сама себя, ей требуется остановиться немедленно, пока она не произведет необратимых критических изменений (типа уничтожения файловой системы). Везде, где только возможно, UNIX/Linux пытается детектировать проблему и справиться с ней без остановки всей системы. Например, многие ситуации типа «oops» приводят к завершению процесса, который нормально запустился, но потом зациклил систему. Бывают, однако, ситуации, когда все настолько плохо, что полная паника является наилучшим выходом. Считается, что пользователи стабильных версий ядра не должны встречать ни «паник», ни «oops». Но в реальном мире они иногда происходят.

Недавно найденный «TF-баг» (смотрите здесь ) является хорошим примером паники. Процессор пытается передать управление процессу, которого не существует. Это приводит к краху всей системы. В данном случае, у системы нет другой альтернативы, чем запаниковать.

Ядро, поставляемое с Red Hat Linux 7.3 (и некоторыми другими дистрибутивами), содержит баг в файловой системе ext3. Эта ошибка приводит к «oops», завершая время от времени некоторые процессы (также этот баг приводит к замедлению всей системы). Хотя данная ошибка уже исправлена (патч есть и в обновлении от Red Hat), этот случай познакомил многих пользователей с ошибками типа «oops».

Микроядро (Microkernel) — компактный код, можно сказать, сердце системы. В рамках микроядра работают ключевые службы: диспетчер памяти, диспетчер задач и другие.

Слой абстрагирования (Hardware Abstraction Layer, HAL). Полностью абстрагирует код системы от конкретного аппаратного оборудования. Использование HAL позволяет обеспечить переносимость 99% кода системы между различным оборудованием.

Диспетчер Ввода/Вывода (Input/Output Manager). Полностью контролирует потоки обмена между системой и устройствами. Драйверы устройств работают в контексте I/O Manager. Если драйвер написан с ошибками и может привести к сбою — это вызовет фатальный крах ядра и всей системы. 70% случаев фатальных сбоев («синий экран») — есть результат некорректного поведения драйверов устройств.

Windows XP содержит встроенный механизм контроля драйверов: правильно написанный и тщательно протестированный драйвер поставляется с цифровой подписью (Driver Signing). Правильная настройка системы заключается в запрещении установки драйверов без корректной подписи.

Модуль управления объектами (Object Manager), управления виртуальной памятью (Virtual Memory Manager), управления процессами (Process Manager), управления безопасностью (Security Reference Monitor), управления локальными вызовами (Local Procedure Calls Facilities) — важные компоненты ядра системы подробно рассматриваться не будут.

«Операционные системы Unix и Windows достаточно сильно отличаются в реализации различных сервисов и служб. В соответствии с темами, затронутыми в этой статье, можно отметить несколько глобальных различий.

В Unix/Linux графическая система существует отдельно от ядра и функционирует как обычное приложение. В операционных системах Windows графическая система интегрирована в ядро. В случае использования операционной системы на рабочей станции, особенно при запуске графикоемких приложений, возможно, лучше, когда графическая система входит в ядро — в этом случае она может быстрее работать. А при работе на сервере предпочтительней отделение графической системы от ядра ОС, так как она загружает память и процессор. В случае Unix/Linux графическую систему можно просто отключить, к тому же, если системный администратор ее все-таки хочет использовать, в Linux есть несколько графических оболочек на выбор, некоторые из них (например, WindowMaker) достаточно слабо загружают машину. Эта же особенность Unix-образных операционных систем позволяет запускать эти ОС на машинах с весьма скромными объемами ОЗУ и т.п. В случае Windows же графическая система слишком тесно интегрирована в ОС, поэтому она должна запускаться даже на тех серверах, на которых она вовсе не нужна.

Отметим также методику разделения прав доступа в Windows 2000 и Unix/Linux. В первом — разделение прав доступа основано на ACL (access control lists), то есть, к примеру, можно настроить систему таким образом, чтобы администратор не имел возможности управлять файлами пользователей. У Unix/Linux же всегда есть суперпользователь — root, который имеет доступ абсолютно ко всему. То есть теоретически модель безопасности в Windows лучше: чтобы полностью завладеть хорошо настроенной системой Windows, хакеру придется ломать больше, в Unix/Linux же достаточно взломать доступ к root. (В Unix/Linux используются более старые технологии, тем не менее, некоторые дистрибутивы Linux сейчас начинают поддерживать ACL, среди них — ASPLinux 7.3 Server Edition). Но теория несколько смазывается практикой с той стороны, что в Windows не так быстро, как в Linux, заделываются «дыры», что уже относится к плюсам открытой модели разработки. В результате оказывается, что в Windows по статистике больше дыр, через которые злоумышленник может пробраться в систему. Но, опять же, точно о количестве дыр в Linux и Windows можно будет сказать только тогда, когда количество пользователей обоих видов ОС будет примерно одинаковым.

В Linux поддерживаются несколько файловых систем, наиболее продвинутые — это Ext2, Ext3, XFS. ОС Windows завязана по большому счету на одну файловую систему — NTFS или FAT 32. Файловые системы Ext2, Ext3, XFS по оценкам работают быстрее. Принципиальное же отличие в том, что в UNIX/Linux вообще нет понятия диска, физического или логического. Вся работа с устройствами хранения данных организуется через специальные файлы устройств, которые отображают физический носитель (диск, лента и т. п ) или его части (разделы) в файловую систему.

Важное отличие — наличие в Windows технологии ActiveX, нечто подобное в Unix/Linux реализуется с помощью CORBA и Bonobo. Эта технология, с одной стороны, предоставляет пользователю множество удобств, с другой стороны — она же допускала в свое время такие вещи, как автоматический запуск Outlook’ом вируса, пришедшего по почте. Одно из важных отличий этих технологий в том, что элементы ActiveX могут внедряться в текст HTML, что имеет как ряд достоинств, так и недостатков.

Можно перечислить еще ряд отличий Unix-подобных операционных систем от Windows, например, встроенную поддержку удаленного доступа в Unix и отсутствие оной в Windows по умолчанию (она реализуется в серверных версиях Windows, а также с помощью дополнительных средств, например, Citrix). В Unix/Linux и Windows сильно различаются сетевые подсистемы (IP-stack), по ряду оценок сетевая подсистема Unix/Linux эффективнее.

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

Ядро операционной системы

  • определениеядро операционной системы
  • архитектура и типы ядер операционной системы
  • ядро операционной системы WINDOWS

Ядро операционной системы определение

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

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

архитектура и типы ядер операционной системы

Классическая архитектура ядра очень сильно зависит от того какой тип ядра представлен в операционной системе. Типов ядер операционной системы бывает очень много и все различаются лишь по размеру и доступным функциям кроме базовых.

Монолитное ядро

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

Недостаток:

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

Преимущества:

Из положительного момента — быстрая разработка и внедрение новых модулей а также скорость работы такого ядра. всё таки унификация всех элементов берет своё

Примеры ОС построенных на таких ядрах :LINUX, Unix, ms-dos

Модульное ядро

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

Микроядро

Микроядро работает по принципу всё что сложнее элементарных функций — выноситься за пределы его работы. Наибольшая часть работы выполняется с помощью сервисов или по другому пользовательских процессов.

драйверы и модули, всё находиться в серверных процессах. Чтобы было понятно взгляните на картинку

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

Недостатки: увеличенное потребление ресурсов.

Из самых популярных операционных систем которое используют это
ядро операционной системы это MAC OS X.

Экзоядро

Экзоядро представляет всего лишь самые базовые функция взаимодействия между процессами, выгрузка и загрузка памяти и других ресурсов. То есть устроенно это ядро таким образом — ядро операционной системы не взаимодействует с программным обеспечением напрямую, а только через специальные библиотеки которые предоставляют API. Является оптимальным решениям для некоторого вида приложений которые должны очень быстро работать.

Ядро операционной системы WINDOWS

Вы спросите а к какому типу архитектуры тогда относиться операционная система windows?

относиться она к гибридному типу включая в себя как и микроядро так и монолитное
ядро операционной системы

Архитектура Windows XP и ее особенности

Общая характеристика

Windows XP — многопользовательская, многозадачная сетевая ОС с графическим интерфейсом. В ней использовано 3 варианта файловой системы (FAT 16, FAT 32, NTFS). При этом система FAT 16 к настоящему времени устарела, система FAT 32 более приемлема для носителей небольшого объема, NTFS — для больших носителей и хранения файлов большого размера.

С точки зрения архитектуры памяти Windows XP может иметь 32-разрядную или 64-разрядную архитектуру в зависимости от версии. С практической точки зрения это означает следующее. В 32-битных версиях Windows XP объем доступной оперативной памяти ограничен 4Гб. Если пользователь ПК с 32-битной ОС хочет увеличить оперативную память для увеличения быстродействия, то увеличивать стоит только до 4Гб, не более. В 64-битных версиях Windows XP объем доступной оперативной памяти логически ограничен 16Тб. Фактически Microsoft из экономических соображений ограничивает объемы памяти в несколько гигабайт. [7]

Также важен такой фактор, как совместимость программ. Большинство программ, созданных для 32-разрядных версий, будут работать и в 64-разрядных версиях. Исключениями являются драйверы и программы, в состав которых входят собственные драйверы (антивирусы, файерволы и т.д.): 32-х битный драйвер не может работать в 64-битной системе. Также в интернет-сообществе неоднократно замечались проблемы с игровыми программами для 32-битных версий в 64-битных версиях ОС. Программы, созданные для 64-разрядных версий, не работают в 32-разрядных. Также заметим, что 16-разрядные программы обычно без проблем запускаются при 32-разрядных версиях Windows XP, но запуск таких программ не поддерживается 64-разрядными версиями. Тем не менее, операционная система может распознать некоторые 16-битные инсталляторы и автоматически сконвертировать их в 32-битные.

Windows XP поддерживает многозадачность и многопоточность. Как и остальные версии Windows, это система с разделением времени, то есть для выполнения каждой задачи выделяется небольшой промежуток времени, и ни одна задача не занимает процессор надолго. В Windows XP реализована приоритетная (вытесняющая) многозадачность, когда каждая программа имеет свое защищенное адресное пространство, а механизм планирования процессов целиком сосредоточен в операционной системе [2]. Решение о переключении процессора с одного процесса на другой принимается операционной системой.

Если детально рассматривать подсистемы ОС и их взаимодействие, получим схему, приведённую на рис. 2.1.

Рис. 2.1. Структура Windows XP

Почти все современные процессоры позволяют установить режим работы приложения — Kernel (ядро) или User (пользователь). В режиме ядра приложению, кроме прочего, разрешено выделение памяти всем другим приложениям. Режим пользователя предоставляет меньше привилегий, нежели режим ядра, — в частности, он не обеспечивает прямой доступ к аппаратуре и чужим адресным пространствам. Для использования системных сервисов прикладные программы используют интерфейс прикладного программирования Windows — WINAPI.

В Windows XP реализовано правило: ни под каким видом не позволять прикладным программ работать в режиме ядра. [6] Как только приложение пытается обратиться в чужую область, ОС тут же выявляет ошибку доступа к памяти и прекращает работу приложения. К сожалению, при этом ОС не защищает приложение от самого себя. Если приложение случайно перезаписывает собственный блок памяти, то Windows XP, скорее всего, никак не отреагирует на это нарушение.

Рассмотренная система привилегий довольно «грубая». Так, в архитектуре популярного процессора Intel x86 определено 4 уровня привилегий («колец защиты»), приведенных на рис. 2.2. В этих терминах в Windows XP используются только кольцо 0 и кольцо 3. Компоненты, которые теоретически могли бы работать в режимах 1-2, работают в режимах 0 или 3 в зависимости от того, о каких драйверах идёт речь. На некоторых аппаратных платформах, ранее поддерживаемых, было реализовано лишь два уровня привилегий, а разработчики Windows XP стремились добиться совместимости с как можно большим числом ПК. [1]

Рис. 2.2. «Кольца защиты» в Intel x86

В режиме ядра работают следующие компоненты. [4]

  • 1. Уровень абстрагирования от оборудования (hardware abstraction layer, HAL). Его задачей является отделение операционной системы от особенностей конкретных реализаций в аппаратном обеспечении компьютера, то есть различий в модификациях процессоров, наборах микросхем и т.д. Реализован в системном файле Hal.dll.
  • 2. Ядро операционной системы — содержит наиболее часто вызываемые низкоуровневые функции операционной системы: планирование и распределение ресурсов между процессами, их переключение и синхронизацию. В обязанности ядра также входит управление прерываниями и обработка ошибочных ситуаций при функционировании ОС. Код ядра Windows XP находится в системном файле Ntoskrnl.exe.
  • 3. Драйверы устройств — представляют собой подпрограммы, транслирующие вызовы, поступившие от пользовательских программ, в запросы обработки данных для конкретных устройств. Значительное число драйверов входит в состав Windows XP (см. подкаталог drivers папки system32). Для нестандартных периферийных устройств драйверы находится в комплектах поставки. Очевидно, их было бы нерационально включать в состав ОС. Данный компонент характеризуется одной важной проблемой. Обычно драйверы пишут программисты из компаний-производителей оборудования, которые хуже знают ОС, чем ее создатели, и если драйверы работают в режиме ядра, то грубые ошибки в их программном коде могут привести к краху ОС.
  • 4. Исполняющая подсистема (NTExecutive). Модуль NTExecutive состоит из микроядра и подсистем диспетчеризации управления программами с доступом к виртуальной памяти, окнам и графической подсистеме. К исполняющей подсистеме относятся системные файлы Ntkrnlpa.exe, Kernel32.dll, Advapi32.dll, User32.dll, Gdi32.dll.

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

Графическая подсистема предназначена для создания оконного интерфейса, рисования элементов управления, расположенных в окнах.

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

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

Диспетчер ввода-вывода — интегрирует добавляемые в систему драйверы устройств в ОС.

Диспетчер объектов — служит для управления всеми разделяемыми ресурсами компьютера. В момент обращения приложения к некоторому ресурсу диспетчер объектов сопоставляет этому ресурсу объект и выдает приложению дескриптор этого объекта (упрощённого говоря, идентификатор). Приложение взаимодействует с объектом на основе дескриптора.

Диспетчер процессов — предоставляет интерфейс, при помощи которого другие компоненты Windows NT Executive, а также приложения пользовательского режима могут манипулировать процессами и потоками. Во время работы диспетчер процессов сопоставляет каждому процессу и потому идентификатор процесса и идентификатор потока соответственно, а также таблицу адресов и таблицу дескрипторов.

Диспетчер виртуальной памяти — служит для управления организацией подсистемы памяти, позволяет создавать таблицы адресов для процессов и следует за корректностью использования адресного пространства приложениями. Кроме того, диспетчер виртуальной памяти обеспечивает возможность загрузки в оперативную память исполняемых файлов динамических библиотек. Он предоставляет физическую память для пользовательских приложений, выделяя каждому процессу виртуальное адресное пространство. Процессы обмениваются данными через разделяемую память, которая может быть спроецирована на виртуальное адресное пространство нескольких процессов. Главная задача диспетчера виртуальной памяти — организация логической памяти, размер которой больше размера физической, установленной на компьютере. Это достигается путём того, что страницы памяти, к которым долго не было обращений и которые не имеют атрибута неперемещаемых, сохраняются диспетчером в выше упомянутом файла pagefile.sys и удаляются из оперативной памяти. Когда такая страница снова понадобится, она копируется обратно в оперативную память.

Диспетчер кэша — используется для кэшированного чтения и записи и позволяет существенно ускорить работу жестких дисков и других устройств. Наиболее востребованные файлы дублируются диспетчером кэша в оперативной памяти, и при обращении к ним ведётся работа с этими копиями, а не оригиналами. Это даёт рост быстродействия, поскольку работа с оперативной памятью ведётся на порядок быстрее, чем с внешней. Кэш в Windows XP является единым для всех логических дисков, вне зависимости от используемой файловой системы. Диспетчер управляет размерами кэша в зависимости от доступного объёма свободной физической памяти.

Диспетчеры окон и графики выполняют функции, связанные с пересылкой системных сообщений и отображением информации на экране.

Требования к процессору Windows

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

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

для ясности компания должна также отвечать всем процессорам и прочим требованиям, указанным в минимальных требованиях к оборудованию для Windows, расположенного по https://docs.microsoft.com/windows-hardware/design/minimum/minimum-hardware-requirements-overview адресу (или обновленному).

Если после включения серии процессоров в этой спецификации («перечисленный процессор») процессор станет коммерческим доступом, в котором используется то же соглашение об именовании или идентификатор, что и в списке процессоров, но есть дополнительные или другие функции или функции («новый процессор»), компания не должна использовать новый процессор для систем клиентов без предварительного письменного разрешения Майкрософт. Если компания считает, что в этом списке отсутствует процессор, обратитесь к корпоративному менеджеру 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 является окончательным. Новые системные отправки больше не принимаются для сертификации.

[5] список процессоров для Windows Server 2016 является окончательным. компания может отправить запрос на сертификацию (в программе Windows аппаратной совместимости), где работают Windows Server 2016 и выявленные процессоры до 31 декабря 2021; После такой даты новые серверные системы не будут сертифицированы для Windows Server 2016.

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

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

Борис Аладышкин/ автор статьи

Приветствую! Я являюсь руководителем данного проекта и занимаюсь его наполнением. Здесь я стараюсь собирать и публиковать максимально полный и интересный контент на темы связанные с современными технологиями и программным обеспечением. Уверен вы найдете для себя немало полезной информации. С уважением, Борис Аладышкин.

Понравилась статья? Поделиться с друзьями:
Itsovet61.ru
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: