Архитектура oc windows имеет модульную структуру

ОС семейства
Windows
NT
обладают модульной структурой, что
обеспечивает гибкость и позволяет
работать на различных аппаратных
платформах (Intel, Dec) и поддерживает
приложения, написанные для различных
ОС. Windows различает прикладные программы
и программы ОС, к последним, относятся:
исполняющая система, микроядро, драйверы
устройств и уровень аппаратных абстракций,
которые выполняются в режиме ядра
(рис.21). Эти программы имеют доступ к
системным данным и аппаратному
обеспечению.

Остальные программы,
работающие в пользовательском режиме,
имеют ограниченный доступ к системным
данным, а для доступа к аппаратному
обеспечению могут использоваться только
API [6].
Для обеспечения переносимости большая
часть исполняющей системы рассматривает
аппаратное обеспечение в виде следующих
уровней (рис.21):

Рис.21.
Структурная схема Windows
XP

1. Уровень аппаратных
абстракций: на нём формируется отображение
между общими каналами ОС и ответными
сигналами аппаратного обеспечения для
конкретной платформыю. Этот уровень
отделяет ОС от особенностей аппаратной
платформы, благодаря чему системная
шина, контроллер прямого доступа в
память (ПДП), контроллер прерываний,
системные таймеры и память выглядят с
точки зрения ядра одинаково. Кроме того,
на этом уровне поддерживается симметричная
многопроцессорность (SMP).

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

3. Драйверы устройств:
к ним относятся как ФС, так и драйверы
аппаратных устройств, которые преобразуют
поступающие от пользователя вызовы
функций ввода/вывода в запросы для
конкретных устройств.

4 .Исполняющая
система включает модули, обеспечивающие
поддержку её функций и предоставляющие
работающим в пользовательском режиме
программам соответствующие API.

Исполняющая
система:

Диспетчер
ввода/вывода: поддерживает доступность
для приложений ввода/вывода, отвечает
за координацию работы драйверов
устройств, выполняющих дальнейшую
обработку и реализует все API I/O ОС с
помощью диспетчера объектов следит за
безопасностью, именованием устройств
и ФС.

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

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

Диспетчер процессов
и потоков: создаёт и удаляет объекты, а
так же следит за процессами и потоками.

Средства локального
вызова процедуры: устанавливает
взаимосвязь между приложением и
исполняющей подсистемой по модели
«клиент-сервер» при распределённой
обработке данных.

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

Диспетчер
кеша: повышает производительность
файлового I/O путём хранения в ОП тех
данных с диска, к которым недавно
проводилось обращение, кроме того, он
обеспечивает отложенную запись на диск,
при которой некоторое время информация
для обновления дисковых файлов хранится
в памяти.

Диспетчер окон:
создаёт оконный (экранный) интерфейс и
управляет графическими устройствами.

5. Пользовательские
процессы:

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

Сервисные процессы.

Приложения
пользователя: Win32, POSIX, Os/2, Win 3.1, MS-DOS.

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

Наиболее важной
из подсистем является Win32 – это API,
который реализован для данной ОС
(семейство Windows
NT),
его основные функции:

1. Ввод с клавиатуры
   и мыши, вывод на печать, динамические
   библиотеки (DLL),
   коммуникации, консоли, операции с
   буфером обмена, сервисы, системная
   информация, управление окнами, реестром,
   безопасность, время, графические
   фильтры, журнал регистра событий,
   конвейеры и т. д.

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

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

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

Интегрированная
среда разработки (англ.
IDE, Integrated development environment — система
программных средств) Microsoft
Visual
Studio
используется для разработки приложений
для операционной системы Windows.
Microsoft Visual Studio — линейка продуктов
компании Майкрософт,
включающих интегрированную
среду разработки программного
обеспечения и ряд других инструментальных
средств [1].
Visual Studio включает один или несколько
компонентов из следующих: Visual
Basic .NET, а до его появления — Visual
Basic; Visual
C++ ; Visual
C#. Многие варианты поставки также
включают Microsoft
SQL Server либо Microsoft
SQL Server Express

Обычно среда
разработки включает в себя текстовый
редактор, компилятор
и/или интерпретатор,
средства автоматизации сборки и отладчик.
Иногда также содержит средства для
интеграции с системами
управления версиями и разнообразные
инструменты для упрощения конструирования
графического
интерфейса пользователя [7,8].
Многие современные среды разработки
также включают браузер классов, инспектор
объектов и диаграмму иерархии
классов — для использования при
объектно-ориентированной разработке
ПО. Хотя и существуют среды разработки,
предназначенные для нескольких языков
— такие как Eclipse,
NetBeans или
Microsoft
Visual Studio, обычно среда разработки
предназначается для одного определённого
языка программирования — как например,
Visual Basic.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Несколько дней назад в сеть просочился образ ранней версии Windows 11. Различные издательства провели тесты по производительности и пришли к неутешительному выводу: Windows 11 в среднем работает хуже, чем Windows 10. Но расстраиваться рано! Проблемы производительности могут быть связаны с «сыростью» слитого образа и нюансами совместимости с текущими программами. Так или иначе, 24 июня состоится официальная презентация нового поколения операционных систем Windows, которая, возможно, даст ответы на многие вопросы. Если сегодня у вас есть настроение для ностальгии, предлагаем вам окунуться в мир Windows: познакомиться с историей, как менялась ось и что у нее внутри.

История Windows

В начале 80 годов прошлого века компания IBM работала над персональным компьютером на базе процессора Intel 8088. С середины 70 годов компания Microsoft была основным поставщиком Basic для восьмибитных микрокомпьютеров. Когда IBM обратилась к Microsoft для лицензирования Basic для их нового компьютера IBM PC, Microsoft согласилась, а также посоветовала обратиться к компании Digital Research для лицензирования операционной системы CP/M. Но, получилось так, что глава Digital Research не нашел в своем графике времени для встречи для IBM, и IBM снова обратилась к Microsoft, теперь уже с просьбой решить вопрос операционной системы для IBM PC. Microsoft купила клон ОС CP/M у компании Seattle Computer Products и перенесла её на IBM PC. Итоговым названием получившейся ОС стало MS-DOS 1.0.

IBM PC

Первые продукты с названием «Windows» от Microsoft не были операционными системами. Это были графические среды для MS-DOS. На фоне успеха, в том числе и коммерческого, пользовательского интерфейса на Apple Lisa, компания решила реализовать графический интерфейс на IBM PC с MS-DOS. В отличии от относительно дешевых IBM PC, Apple Lisa стоили дорого (почти 10 тысяч долларов), и немногие покупатели могли позволить купить их. Microsoft решила занять нишу дешевых компьютеров с графическим интерфейсом. При этом низкая стоимость достигалась экономией на комплектующих и более низкая производительность, по сравнению с Lisa, избежать не получилось. Так, в 1985, 1987 и в 1990 выходят первые три версии Windows — 1.0, 2.0 и 3.0. Причем за первые шесть месяцев после релиза Windows 3.0 было продано более 1 миллиона экземпляров. Дальнейшее развитие Windows можно разделить на два направления — Windows на базе MS-DOS и Windows на базе NT.

Windows 1.01

Windows 9x

Windows на базе MS-DOS или Windows 9x не были первыми ОС от Microsoft, но они продолжали «старые традиции» и были построены на основе 16-битного кода MS-DOS. В августе 1995 года была выпущена Windows 95 — первая система семейства Windows 9x. Она уже была полноценной операционной системой с соответствующими возможностями.  Однако у системы были проблемы с безопасностью (например, не было «администратора») и с изоляцией приложений. Зависание 16-битного приложения приводило к блокировке всей системы. Проблемы со стабильностью достались и Windows 98 и Windows ME, которые отличались от выпуска 95 года рядом небольших обновлений.

Windows 95

Windows NT

В целом, к концу 80-х годов в Microsoft появилось понимание о необходимости разработки операционной системы не на базе MS-DOS. Параллельно с разработкой софта, связанного с MS-DOS, Microsoft наняла команду инженеров из компании DEC для разработки новой 32-битной операционной системы. Главой группы стал Дэйв Катлер — один из главных разработчиков ОС VMS. Новая система была названа NT — от сокращения New Technology. Основной упор при разработке NT делался на безопасность и надежность системы, а также на совместимость с Windows на MS-DOS. Так получилось, что опыт при разработке VMS повлиял на NT и сходство между ними стало причиной спора между DEC и Microsoft. По итогу спор был решен во внесудебном порядке. 

Дэйв Катлер

Первая система Windows называлась Windows NT 3.1 и была выпущена в 1993 году. Это была первая ОС от Microsoft. Индекс 3.1 был выбран для соответствия Windows 3.1 на MS-DOS. Эта версия не имела особого успеха. Для NT требовалось больше памяти, 32-разрядных приложений на рынке было мало, возникали проблемы с совместимостью драйвером. Достичь поставленных целей смогли в NT 3.5. А первым серьезным обновлением для NT стала версия 4.0 в 96 году. Теперь эта система была мощна, надежна и безопасна, а также обеспечивала тот же интерфейс, что и Windows 95 (которая к тому моменту была чрезвычайно популярной). 

Windows NT 3.1

В 2000 году вышла новая версия Windows — Windows 2000. Она развивала идеи, заложенные в системы NT. Был добавлена технология Plug-and-Play, управление электропитанием и улучшен интерфейс пользователя. 

Windows 2000

Успех Windows 2000 задал вектор развития для следующего поколения — Windows XP. В «хрюшке» Microsoft улучшила совместимость, интерфейс стал более дружелюбным. Стратегия Microsoft завоевывать аудиторию уже знакомыми системами дала плоды — за несколько лет Windows XP была установлена на сотнях миллионах ПК. Эпоха MS-DOS подошла к концу.

Windows XP

Следующий проект Microsoft пал жертвой собственных амбиций. Через пять лет после Windows XP, в 2006 году на свет вышла Windows Vista. В ней был переделан графический интерфейс, переработаны и добавлены функциональные возможности в плане безопасности. Была улучшена производительность, надежность.

Первоначальные планы Microsoft по поводу Vista были настолько обширны, что через несколько лет после начала разработки проект пришлось сильно ограничить. Vista включала в себе 70 миллионов строк кода, часть которого составлял «причесанный» код XP. Неудача Vista отчасти с тем, что она вышла не в то время. На 2006 год пришелся бум недорогих компьютеров, которые не могли обеспечить достаточную для Vista производительность. 

Windows Vista

Проблемы Vista были учтены при разработке Windows 7. Microsoft уделила большее внимание тестированию и производительности новой системы. Windows 7 быстро вытеснила Vista, а затем и XP, став самой популярной версией Windows до появления Windows 10 (сейчас Windows 7 на втором месте по популярности).

Windows 7

Бум смартфонов в начале 2010-х подтолкнул Microsoft к созданию операционной системы, которую можно было бы развернуть на разных устройствах: на телефонах, планшетах, приставках и т. д. В результате этой работы мир узрел Windows 8. «Восьмерка» построена на модульном подходе MinWin для получения небольшого ядра ОС, которое можно было бы расширить на линейку других типов устройств. Но аудитория встретила холодно такой подход. Многие люди критиковали «смартфоноподобный» интерфейс на ПК, отсутствие кнопки пуск. Для решения многих проблем Microsoft выпустила обновление под названием Windows 8.1, которая, помимо исправления имеющихся ошибок, добавила новые функции. 

Windows 8.1

И вот, к 2015 году Microsoft выпускает Windows 10. При разработке Microsoft продолжала развитие идеи единой системы для разных устройств. В «десятке» появилась голосовая помощница Кортана, вернули меню «Пуск», улучшена системная безопасность. 

Технические аспекты

Чтобы осветить все технические аспекты и тонкости операционной системы Windows понадобится не менее 1000 страниц. Для особо любопытных советуем 7-е издание «Внутреннего устройства Windows« Марка Руссиновича, специалиста по внутреннему устройству Windows. Также можно почитать «Современные операционные системы« Эндрю Таненбаума и «Operating System Concepts«: в обеих книгах есть главы, посвященные Windows. Здесь же ограничимся рассмотрением инструментов взаимодействия приложений пользователя с операционной системой (Windows API) и архитектуры «оси». 

Архитектура 

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

Windows считается операционной системой с гибридным ядром. С одной стороны компоненты ядра Windows располагаются в вытесняемой памяти и взаимодействуют друг с другом путем передачи сообщений, как в микроядерных системах. С другой стороны ядро слишком велико (более 1 Мбайт), а большая часть кода ОС и кода драйверов устройств использует одно защищенное пространство памяти защищенного режима, что свойственно монолитным ОС. Это означает, что в теории любой компонент ОС или драйвер устройства может повредить данные, используемые другими системными компонентами. В Windows эта проблема решается за счет повышения качества и контроля происхождения сторонних драйверов через такие программы, как WHQL или KMCS. Одновременно применяются дополнительные технологии защиты ядра, такие как безопасность на базе виртуализации, функции Device Guard.

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

Упрощенная схема архитектуры Windows

Вторая линия разделяет компоненты режима ядра и гипервизор (Hyper-V). Гипервизор перехватывает многие привилегированные операции, выполняемые ядром, и эмулирует их таким образом, чтобы позволить на одной и той же машине одновременно работать нескольким операционными системам. Гипервизор работает на том же уровне привилегий процессора (0), что и ядро. Но из-за использования специализированных команд процессора (VT-x у процессоров Intel, SVM у АMD) он может изолироваться от ядра с сохранением контроля над ним и приложениями. Поэтому некоторые иногда применяют термин «кольцо -1».

Четыре базовых типа процессов пользовательского режима:

• Пользовательские процессы. Эти процессы относятся к одному из следующих типов: 32- или 64-разрядные приложения Windows (приложения Windows Apps, работающие на базе среды Windows Runtime в Windows 8 и выше, включаются в эту категорию), 16-разрядные приложения Windows 3.1, 16-разрядные приложения MS-DOS, 32- и 64-разрядные приложения POSIX. Заметим, что 16-разрядные приложения могут выполняться только в 32-разрядных версиях Windows, а приложения POSIX в Windows 8 уже не поддерживаются. 
• Процессы служб. В эту категорию входят процессы, являющиеся хостами для служб Windows (например, службы планировщика задач и диспетчер печати). Обычно к службам предъявляется требование независимости выполнения от входа пользователя. Многие серверные приложения Windows (например, Microsoft SQL Server и Microsoft Exchange Server) также включают компоненты, выполняемые как службы.
• Системные процессы. Фиксированные процессы, такие как процесс входа или диспетчер сеансов, не являются службами Windows. Другими словами, они не запускаются диспетчером служб.
• Серверные процессы подсистем среды. Такие процессы реализуют часть поддержки среды ОС, предоставляемой пользователю и программисту. Изначально в Windows NT было три подсистемы среды: Windows, POSIX и OS/2. Подсистема OS/2 включалась только до Windows 2000, подсистема POSIX в последний раз была включена в Windows XP.Ultimate- и Enterprise-выпуски клиента Windows 7. Все серверные версии Windows 2008 R2 включают поддержку расширенной подсистемы POSIX, называемой SUA (Subsystem for UNIX-based Applications). Сейчас подсистема SUA не поддерживается и уже не включается как необязательное часть в версии Windows (Windows 10 версии 1607 включает подсистему Windows для Linux — WSL, Windows Subsystem for Linux).

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

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

• Исполнительная система. Она содержит базовые сервисные функции ОС: управление памятью, управление процессами и потоками, безопасность, ввод/вывод, сетевая поддержка и межпроцессные коммуникации.
• Ядро Windows. Низкоуровневые функции ОС: планирование потоков, диспетчеризация прерываний и исключений и многопроцессорная синхронизация. Также ядро предоставляет набор функций и базовых объектов, которые используются исполнительной системой для реализации высокоуровневых конструкций.
• Драйверы устройств. Сюда входят как драйверы физических устройств, преобразующие вызовы пользовательских функций ввода/вывода в конкретные запросы ввода/вывода к устройству, так и драйверы устройств, не относящихся к физическому оборудованию, например драйверы файловой системы или сетевые драйверы. 
• Слой абстрагирования оборудования (HAL). Прослойка кода, изолирующее ядро, драйверы устройств и прочий исполняемый код Windows от платформенно-зависимых различий в работе оборудования, например различий между системными платами.
• Оконная и графическая система. Реализация функций графического интерфейса (GUI), также известных как функции GDI: работа с окнами, элементы пользовательского интерфейса и графический вывод.
• Уровень гипервизора. Включает всего-навсего один компонент: сам гипервизор. В этой среде нет ни драйверов, ни других модулей. При этом сам гипервизор состоит из нескольких внутренних уровней и служб: собственный диспетчер памяти, планировщик виртуальных процессов, управление прерываниями и таймером, функции синхронизации, разделы (экземпляры виртуальных машин) и внутрипроцессные коммуникации (IPC, Inter-Process Communication) и многие другие.

В таблице ниже представлены некоторые файлы некоторых базовых компонентов Windows:

Windows API

Windows API (Application Programming Interface) — это программный интерфейс пользовательского режима для Windows. До появления 64-разрядной версии операционной системы программный интерфейс 32-разрядных версий Windows назывался Win32 API в отличие от исходного 16-разрядного Windows API (программный интерфейс для исходных 16-разрядных версий Windows). На данный момент термин Windows API или Win32 API относят как к 32-разрядным, так и к 64-разрядным версиям.

В «доисторические времена» Windows API состоял только из функций в стиле C. Выбор языка C был обусловлен тем, что написанный на нем код также мог использоваться из других языков. Он являлся достаточно низкоуровневым для предоставления сервиса ОС. Но огромное количество функций в сочетании с недостаточной последовательностью выбора имен и отсутствием логических группировок (вроде пространств имен C++) привели к тому, что в некоторых новых API используется другой механизм — модель COM.

COM базируется на двух основных принципах. Во-первых, клиенты взаимодействуют с объектами (серверные объекты COM) через интерфейсы — четко определенные контракты с набором логически связанных методов, сгруппированных посредством механизма диспетчеризации по виртуальным таблицам. Такой же механизм, к слову, обычно применяется компиляторами C++ для реализации диспетчеризации виртуальных функций. Таким образом обеспечивается двоичная совместимость и снимаются проблемы с декорированием имен компилятором. Поэтому, такие методы могут вызываться из многих других языков и компиляторов, включая C, C++, VB, языки .NET, Delphi и т. д. Вторым принципом является динамическая загрузка компонентов (вместо статической компоновки с клиентом).

WinRT

В Windows 8 появился новый API и исполнительная среда поддержки Windows Runtime (WinRT). WinRT состоит из платформенных сервисов, предназначенных для разработчиков приложений Windows Apps (приложения Windows Apps подходят для устройств, начиная от миниатюрных IoT-устройств до телефонов, планшетов, десктопных систем, ноутбуков и даже Xbox One и Microsoft HoloLens).

С точки зрения API платформа WinRT строится на базе COM, добавляя в базовую инфраструктуру COM различные расширения. С архитектурной точки зрения она обладает намного большей целостностью: в ней реализованы иерархии пространств имен, последовательная схема назначения имен и паттерны программирования. На базовом двоичном уровне WinRT API все равно строится на основе унаследованных двоичных файлов и API Windows. Это не новый «машинный» API для системы: ситуация немного напоминает то, как .NET строится на основе традиционного Windows API. 

.NET Framework

.NET Framework является частью Windows. Он состоит из двух основных компонентов:

• CLR (Common Language Runtime). Исполнительная среда .NET, включает JIT-компилятор для преобразования инструкций языка CIL в низкоуровневый язык машинных команд процессора, сборщик мусора, систему проверки типов, безопасность обращения к коду и т. д. Среда реализована в виде внутрипроцессного сервера COM (DLL) и использует различные средства, предоставляемые Windows API.
• .NET Framework Class Library (FCL). Обширная подборка типов, реализующих функциональность, часто используемую в клиентских и серверных приложениях, — средства пользовательского интерфейса, поддержка сети, работа с базами данных и т. д.

На схеме представлены отношения между .NET Framework и ОС Windows:

Отношение между .NET и ОС Windows. Термин «сервер COM» обычно относится к DLL библиотеке или исполняемому файлу (EXE), в котором реализованы классы COM.

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

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

Чтобы лучше понять архитектуру Windows я подготовил такой рисунок:

При запуске Windows приложения идет обращение к “Подсистеме Windows“, а уже от туда идет обращение к “Исполнительной системе“, которая запустит процесс для этого приложения.

Microsoft также разработали “Подсистему для Linux” (WSL). Для этого в режим ядра поместили два драйвера: Lxss.sys и Lxcore.sys. Эти драйвера эмулируют ядро Linux. А также, в пользовательском режиме работает специальный менеджер – LX Manager. Этот менеджер обрабатывает приложения для Linux.

Когда вы запускаете Linux приложение, например bash.exe, то идет обращение через LX Manager к драйверам эмулирующим ядро Linux. И уже это ядро запускает и обслуживает данный процесс.

То-есть для Windows приложений существует “Подсистема Windows” в пользовательском режиме и “Исполнительная система” в режиме ядра. А для Linux приложений существует LX Manager в пользовательском режиме и специальные драйвера в режиме ядра.

Помимо “Исполнительной системы” и драйверов эмулирующих работу ядра Linux в режиме ядра работают:

• драйвера устройств или приложений, которые являются исполняемыми файлами с расширением .sys;
• ядро операционной системы;
• HAL – прослойка между ядром (или драйверами) и оборудованием (системной платой).

Ядро

В системе Windows ядро не выполняет все задачи, которые выполняются в режиме ядра. Ядру помогает “Исполнительная система“. Подробнее про неё будет написано в следующей статье. А пока посмотрим чем занимается само ядро.

Ядро состоит из набора функций Ntoskrnl.exe, которые являются фундаментальными в операционной системе. Эти функции используются компонентами исполнительной системы.

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

С другим оборудованием ядро работает через HAL.

HAL

HAL – слой абстрагирования от оборудования. Он представляет собой загружаемый модуль режима ядра hal.dll, и является прослойкой между ядром и оборудованием. Под оборудованием я подразумеваю системную плату или платы расширения, а не периферию. Так драйвера принтеров работают напрямую с принтерами, а не через HAL.

Таким образом ядро и драйвера не работают напрямую с материнской платой, а вызывают функции HAL.

Для Windows x86 включена пара библиотек HAL, но загружается одна в зависимости от типа системной платы:

• halacpi.dll — платы с поддержкой acpi, но без поддержки apic;
• halmacpi.dll — платы с поддержкой acpi и apic.

Для Windows x64 существует только один образ hal:

• hal.dll — платы с поддержкой x64 всегда поддерживают acpi и apic.

Windows поддерживает расширения hal — это дополнительные библиотеки, которые могут загружаться при наличии конкретного оборудования, запрашивающего эти библиотеки. Например:

• HalExtPL080.dll — расширение для контроллера DMA PL080;
• HalExtIntcLpioDMA.dll — для некоторых платформ intel с пониженным энергопотреблением.

Создание расширений HAL требует сотрудничества с компанией MicroSoft. В связи с этим расширения снабжаются цифровой подписью.

Вернуться к оглавлению