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

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

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

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

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

Исходные положения, используемые при производстве изделий.

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

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

Т_F>T_r,

где Т_F – допуск параметра, устанавливаемый исходя из эксплуатационных требований; T_r – технологический допуск, обеспечиваемый при принятом технологическом процессе.

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

4. Для ответственных деталей необходимо создавать оптимальное качество поверхности.

5. Для обеспечения взаимозаменяемости и высокого качества машин и других изделий необходимо, чтобы технологические и измерительные базы совпадали с конструктивными, т.е. нужно соблюдать принцип единства баз. Кроме того, схема измерения должна соответствовать схеме рабочих движений детали в механизме. Это требование удовлетворяется, например, при однопрофильном контроле зубчатых колес. Исходные положения, используемые при эксплуатации изделий.Важной составной частью осуществления принципа взаимозаменяемости, обусловливающего долговечную и экономичную работу изделий, является определение необходимого комплекта запасных частей (деталей и сборочных единиц), которое обеспечивали бы быстрою замену в процессе эксплуатации износившихся или поломанных деталей или сборочных единиц, сохраняя требуемую работоспособность машины в течении длительного времени. Для этого должен быть проведен анализ и выявлены «слабые места» изделия, т.е. найдены детали и сборочные единицы, в наибольшей мере подверженные износу и влияющие на эксплуатационные показатели. В процессе эксплуатации необходимо тщательно контролировать работу машины и особое внимание уделять наиболее «слабым» элементам.

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

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

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

Рис. 1 Иерархическая модель операционной системы

Каждый слой, или уровень, в структуре может использовать функции, предоставляемые ему более низким уровнем, как если бы они являлись частью реальной машины. Так уровень 0, часто называемый ядром ОС, имеет дело непосредственно с аппаратурой; уровень 1 имеет дело с интерфейсом, представленным уровнем 0 и т.д. Программы пользователя имеют дело с интерфейсом самого высокого уровня (в данном случае уровня 3), который представляет собой интерфейс пользователя.

Расположение уровней определяется взаимоотношением между выполнением или операциями. В общем случае функции каждого уровня могут обращаться лишь к функциям того же или более низкого уровня; таким образом, не должно быть внешних вызовов. В данной структуре программы управления файлами (уровень 3) для распределения буферов должны использовать менеджер памяти (уровень 2), а для чтения и записи блоков – супервизор ввода – вывода (уровень 1). Если управление памятью производится при помощи размещения страниц по запросу, то менеджер памяти для передачи страниц между реальной памятью и вспомогательной тоже должен вызвать супервизор ввода – вывода. Все уровни системы используют предоставляемые уровнем 0 функции планирования процессов и управления ресурсами.

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

Различные системы могут существенно отличаться друг от друга. Рассмотрим, например, программы обработку прерываний. Во многих системах обработки прерываний первого уровня (ОППУ) размещены ядре (уровень 0). После начальной обработки прерываний ОППУ может передать управление программе более высокого уровня; это исключение из правил, согласно которым внешнее вызовы недоступны. Так, например, ОППУ в случае прерывания по отсутствию страницы может сохранить информацию о состоянии, разрешить другие прерывания, а затем передать управления программе уровня 2.

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

Иерархические системы различаются также правилами передачи управления с одного уровня на другой. В строгой иерархии каждый уровень может обращаться только к уровню, находящемуся непосредственно под ним. Так, уровень 3 может связаться только с уровнем 2. Если программе управления файлами в нашем примере необходимо вызвать супервизор ввода – вывода, то этот запрос будет передан с уровня 2 на уровень 1. Преимущества этого подхода заключается в простоте использования: каждый уровень взаимодействует только с одним интерфейсом. Однако такое ограничение может привести к потере эффективности, т.к. возрастает число вызовов, которые нужно сделать для достижения внутреннего уровня. В прозрачной иерархии каждый уровень может связываться непосредственно с интерфейсом любого более низкого уровня. Так, например, программа пользователя может обращаться к программам управления файлами уровня 3 или непосредственно вызывать функции супервизора ввода – вывода Уровня 1.

Чтобы перед пользователями (программами, процессами) создать иллюзию того, что она работает на автономных виртуальных машинах, концепцию иерархической структуры, только что рассматриваемую, можно расширить. Подход, связанный с применением виртуальных машин (рис. 2), делает возможной одновременную работу различных программ на одной и той же реальной машине. Таким образом, виртуальные машины можно рассматривать как перенесение принципов мультипрограммирования на самый низкий уровень ОС.

Под операционной системой ОС 1 работает три программы (протекает три процесса), под ОС 2 – один процесс, программа под ОС 3 – тестируется. Есть также программа пользователя 4, предназначенная для работы в режиме супервизора в качестве автономной программы, находящейся под собственным управлением. Все разновидности программ плюс автономная программа фактически работают на одной реальной машине. Однако они имеют дело не с ней, а с монитором виртуальной машины (МВМ), благодаря которому у каждой программы создается впечатление, что он работает на автономной машине. Таким образом, в то время как обычные пользователь обслуживаются традиционным способом (Р1…Р4), имеется возможность отлаживать новые программы, а также разрешить специальной программе в особых случаях работать в режиме супервизора.

Рис. 2 Общий принцип организации виртуальных машин в ОС

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

На рисунке 3 показана, каким образом создается подобная иллюзия.

Рис. 3 Иерархическая модель ОС с виртуальной машиной

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

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

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

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

Мультипроцессорные ОС.

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

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

На рисунке 4 показана простейшая форма мультипроцессорной организации. Каждый процессор имеет свою собственную память, УВВ и другие ресурсы. Вдобавок на каждом процессоре функционирует его собственная ОС. Процессоры соединяются линиями связи. Посылка по ним запроса является единственным способом получения доступа одного процессора к ресурсам другого.

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

Рис. 4 Мультипроцессорной системой со слабосвязанными процессами

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

Рис. 5 Мультипроцессорной системой с сильно связанными процессорами

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

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

Рис. 6 Симметричная мультипроцессорная обработка

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

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

Монолитные и микроядерные операционные системы

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

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

При поддержке монолитных ОС возникает ряд проблем, связанных с тем, что все функции макроядра работают в едином адресном пространстве. Во-первых, это опасность возникновения конфликта между различными частями ядра; во-вторых – сложность подключения к ядру новых драйверов. Противоположностью монолитной является мик­роядерная архитектура в которой каждый ком­понент системы представляет собой самостоятельный процесс, а запуск или оста­новка процесса не отражается на работоспособности остальных процессов.

Микроядро – это минимальная стержневая часть операционной системы, служащая основой модульных и переносимых расширений.

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

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

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

§ управление виртуальной памятью;

§ задания и потоки;

§ межпроцессные коммуникации;

§ управление поддержкой ввода/вывода и прерываниями;

§ сервисы набора хоста и процессора.

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

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

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

Наиболее ярким представителем микроядерных ОС является ОС реального вре­мени QNX. Микроядро QNX поддерживает только планирование и диспетчери­зацию процессов, взаимодействие процессов, обработку прерываний и сетевые службы нижнего уровня. Микроядро обеспечивает всего лишь пару десятков системных вызовов, но благодаря этому оно может быть целиком размещено во внутреннем кэше даже таких процессо­ров, как Intel 486. Как известно, разные версии этой ОС имели и различные объ­емы ядер — от 8 до 46 Кбайт.

Чтобы построить минимальную систему QNX, требуется добавить к микроядру менеджер процессов, который создает процессы, управляет процессами и памя­тью процессов. Чтобы ОС QNX была применима не только во встроенных и без­дисковых системах, нужно добавить файловую систему и менеджер устройств. Эти менеджеры исполняются вне пространства ядра, так что ядро остается не­большим.

Архитектура ОС Unix

Первая версия UNIX была написана Кеном Томпсоном (Ken Thompson) на ассемблере для мини-компьютера PDP-7 в 1970 году. Затем появилась вторая версия для компьютера PDP-11, уже на языке С. Ее автором был Деннис Ритчи (Dennis Ritchie).

В табл. 1 перечислены категории системных вызовов Solaris. Системные вы­зовы управления файлами и каталогами – это самая важная и объемная катего­рия. Большинство из них относятся к стандарту Р 1003.1, остальные берут нача­ло в System V.

Таблица 1.

Системные вызовы UNIX

Существует много разных версий UNIX, и каждая из них чем-то отличается от всех остальных, поэтому структуру этой операционной системы описать трудно. Тем не менее, схема, изображенная на рис. 7, применима к большинству из них. Внизу показаны драйверы устройств, которые изолируют файловую систему от аппаратного обеспечения. Изначально каждый драйвер устройства писался без учета всех остальных и представлял собой независимую единицу. Это привело к многочисленным дублированиям, поскольку многие драйверы должны под­держивать управление потоками, исправление ошибок, приоритеты, отделение данных от команд и т. д. По этой причине Деннис Ритчи, для использования принципа модульности при написании драйверов, придумал структуру под на­званием поток ввода-вывода (stream). При наличии потока ввода-вывода можно установить двухстороннее соединение между пользовательским процессом и устройством и вставить между ними один или несколько модулей. Пользова­тельский процесс передает данные в поток ввода-вывода, затем эти данные обра­батываются или просто передаются дальше каждым модулем до тех пор, пока не дойдут до устройства. При передаче данных от устройства процессу все происхо­дит аналогично.

Рис 7. Структура типичной системы UNIX

Над драйверами устройств находится файловая система. Она управляет фай­лами, каталогами, размещением дисковых блоков, защитой и выполняет многие другие функции. В системе файлов имеется так называемый кэш блоков (block cache), предназначенный для хранения недавно считанных с диска блоков на случай, если они понадобятся еще раз. Некоторые файловые системы использовались многие годы.

Еще одна часть ядра системы UNIX – механизм управления процессами. Он выполняет различные функции, в том числе поддерживает взаимодействие между процессами (InterProcess Communication, IPC) и их синхронизацию, что позволяет избежать состояния гонок. Код управления процессами также занимается планированием процессов на основе их приоритетов. Кроме того, он обрабатывает сигналы, которые представляют собой особую (асинхронную) форму программных прерываний. Наконец, он управляет памятью. Большинство систем UNIX поддерживают виртуальную память с подкачкой страниц по требованию, иногда с некоторыми дополнительными особенностями (например, несколько процес­сов могут совместно использовать общие области адресного пространства).

Архитектура Windows NT, Windows XP

ОС архитектуры Windows NT впервые стали продаваться на рынке с середины 1993 г.

Windows NT Server может выступать как:

- файл-сервер;

- сервер печати;

- контроллер домена;

- сервер приложений;

- сервер удаленного доступа;

- сервер баз данных;

- сервер обеспечения безопасности данных;

- сервер резервирования данных;

- сервер связи.

Одновременно поддерживается Windows NT до 256 сессий удаленного доступа. Служба удаленного доступа (RAS) поддерживает протоколы PPP и SLIP.

На схеме (рис. 8) представлены основные элементы архитектуры Windows NT.

Рис. 8 Архитектура Windows NT

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

Архитектура Windows NT состоит из двух основных уровней – режима поль­зователя и режима ядра.

Режим ядра – содержит код ОС (ядро), работающий в защищенном режиме процессора. Ядро имеет доступ к системным данным и оборудованию.

Режим пользователя – содержит подсистемы среды Windows NT и исполняющиеся в них приложения. Компоненты этого уровня формируют операционные окружения для всех пользовательских программ.

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

При разработке Windows NT одной из основных задач была защита ОС от ошибок, исполняющихся в ней приложений.

Компоненты режима ядра разделены на три уровня исполнительной системы Windows NT:

службы исполнительной системы (исполнительные службы) – формирует структуру процесса и отвечает за взаимодей­ствие между процессами, управление памятью, управление объектами, управле­ние очередностью выполнения потоков, обработку прерываний, операции ввода/ вывода, защиту объектов и сетевую безопасность. Для защиты своих компонентов от воздействия приложений и подсистем исполнительная система Windows NT работает в режиме ядра. Исполнительные службы формируют интерфейс между работающими в режиме пользователя защищенными подсистемами и компонентами режима ядра. Для по­вышения производительности ОС, более экономного расходования памяти и упро­щения программного кода Windows NT Диспетчер окон (модуль User) и Интерфейс графических устройств (GDI) расположены в адресном пространстве ядра;

микро­ядро – основа исполнительной системы Windows NT – координирует рабо­ту всех функций ввода/вывода и синхронизирует работу исполнительных служб;

слой абстрагирования от оборудования (HAL) скрывает (абстрагирует) особенно­сти аппаратуры от вышележащих уровней ОС. HAL предоставляет ОС программ­ные абстракции общих устройств: таймера, контроллеров памяти и кэша, перифе­рийных адаптеров, схем симметричной мультипроцессорной обработки и систем­ных шин.

Особенности архитектуры Windows 2000

В Windows 2000 ядро реализовано в виде совокупности специальных процессов – модулей.

Системные процессы имеют непосредственный доступ к аппаратным ресурсам и делятся на классы:

· исполнительный модуль (Executive), обеспечивающий базовые операции системы, необходимые для работы остальных её компонентов (процессов);

· расширение привилегированного режима – процессы, тесно взаимодействующие с аппаратно-зависимыми компонентами ОС;

· защищенные подсистемы различных пользовательских интерфейсов;

· прикладные программы пользователей.

Разделение процессов на типы и классы тесно связаны с аппаратными возможностями микропроцессора, называемых кольцами защиты.

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

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

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

Основа исполнительного модуля – машинно-зависимое микроядро (объемом приблизительно 50 байт). Именно оно может потребовать изменения при переносе на другую компьютерную платформу.

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

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

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

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

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

Файловая система построена по принципу драйвера высокого уровня, что позволяет в рамках одной ОС поддерживать разные способы организации файлов на внешних устройствах, например CD-ROM; DOS – совместную FAT – таблицу; совместимую с OS\2 высокоскоростную файловую систему HPFS и собственную файловую систему NTFS.

Важным компонентом Windows 2000 является защищенные пользовательские подсистемы, выполняемые в непривилегированном пользовательском режиме. В виде таких подсистем реализованы интерфейсы прикладных программ, причем одновременно поддерживается три типа интерфейсов: собственный 32 – разрядный, совместимый с 16 – разрядным интерфейсом DOS и Win 3.х; интерфейс совместимый с OS\2, POSIX – платформено-независимый интерфейс.

Новыми средствами управления ресурсами в Win NT являются семафоры, разделяемая память, именованные программные каналы. Среди дополнительных графических возможностей – поддержка кривых Безье и различных геометрических преобразований, средства аппаратно-независимого управления цветом.

Модель памяти Windows 2000 представляет собой 32 – разрядную линейную адресацию (без сегментов), разделение и защиту как пользовательских, так и системных процессов. Применение страничной подкачки файлов позволяет загрузить на исполнение файл, размер которого превосходит размер ОЗУ ПК. Процессы, находящиеся в ОЗУ, но не выполняющиеся в данный момент, могут быть перемещены на диск в область подкачки, в качестве которой используется специальный файл pegefile.sys. причем в системе предусматривается возможность размещения этого файла на нескольких дисках. Критерий размещения – на каждом физическом диске должен быть свей файл подкачки.

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

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

Windows 2000 не только контролирует доступ к любым ресурсам, но и протоколирует: в различных журналах все действия администратора и пользователей, направленные на нарушение защиты. Система удовлетворяет требованиям американского стандарта безопасности С2, рекомендованного для банковских и финансовых применений.

Составной частью Windows NT Server является Microsoft LAN Manager, который позволяет с помощью разнообразных сетевых транспортных протоколов связываться с приложениями, работающих в средах DOS, Windows, OS\2, Unix.

Центральные службы ОС, используемые для планирования потоков, мультипроцессорной синхронизации и других низкоуровневых задач, реализованы в микроядре. Управление виртуальной памятью и процессами, а также другие службы ОС реализованы в отдельном слое, расположенном поверх микроядра, а само микроядро изолировано от физических характеристик таймеров контроллеров прерываний и прочих аппаратных устройств, службами уровня аппаратной абстракции (НАL). Вместе эти модули образуют исполнительный механизм Windows NT Executive.

В современных процессорах исполнительные истоки – пути, избираемые программой через хранящийся в памяти двоичный код, – могут работать на различных уровнях привилегий, может обращаться к данным на низких уровнях привилегий, однако программа с низким уровнем привилегий не может получить доступ к данным в областях памяти, отмеченных более высокими уровнями привилегий. Модуль NT Executive работает в режиме ядра, который соответствует самому высокому уровню привилегий, обеспечиваемому процессором. Режим ядра – склоним кольца «0». Прикладные программы выполняются в пользовательском режиме, – кольцо «3». Так защитные механизмы, встроенные в процессор, защищают модуль NT Executive от прикладных программ.

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

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

Подсистемы Posix и OS\2 делают доступными функции API для программ OS\2 и Posix, работающих в символьном режиме. Прикладные программы и подсистемы взаимодействуют в соответствии с моделью «клиент-сервер», в которой прикладные программы играют роль клиентов, а подсистемы – серверов. Одно из достоинств такой архитектуры возможность работать в Windows 2000 с другими такими прикладных программам, просто добавив новые подсистемы.

Чтобы увеличить производительность и снизить требования к памяти, службы API операционной системы помещены в ядро.

В модуле Win 32K Executive (рис. 9) располагаются три данных элемента: диспетчер окон, интерфейс графических устройств (GDI) и драйверы графических устройств, передающие результаты работы GDI на экран и на принтер.

Рис. 9 Архитектура модуля Win 32K Executive

Это обеспечивает повышение производительности при работе с графикой, т.к. GDI является частью ядра, и прикладные программы непосредственно обращаются к функциям GDI, избегая сопряженных с большими накладными расходами переключений контекста, а видео драйверы могут быстрее получать доступ к аппаратным средствам, а службы Win 32 API – обращаться к службам в модуле Windows NT Executive, не проходя через границы колец.

Система Windows XP появилась как последовательница Windows 2000 и стала лишь усовершенствованным вариантом Windows 2000.

Windows XP продается в двух версиях: для серверов и для клиентов. Эти две версии практически идентичны и построены на базе одного исходного кода.

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

Windows XP имеет модульную структуру. Она состоит из небольшого ядра, которое работает в привилегированном режиме, и нескольких серверных процессов, работающих в пользовательском режиме. Пользовательские процессы взаимодействуют с серверными процессами в соответствии с моделью клиент-сервер: клиент посылает запрос серверу, а сервер выполняет требуемую работу и отправляет результат клиенту. Модульная структура позволяет переносить Windows XP на некоторые компьютеры, не относящиеся к семейству Intel (DEC Alpha, IBM Power PC и SGI MIPS).

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

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

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

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

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

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

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

Самый нижний уровень содержит файловые системы и диспетчер объектов. Файловые системы управляют файлами и каталогами. Диспетчер объектов управляет объектами, известными ядру, в том числе процессами, программными потоками (их еще называют легковесными процессами, действующими внутри адресного пространства), каталогами, семафорами, устройствами ввода-вывода, тактовыми генераторами и т. п. Диспетчер объектов управляет также простран­ством имен, куда можно помещать новые объекты, потом при необходимости к этим объектам можно обращаться.

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

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

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

Диспетчер процессов и потоков управляет процессами и программными потоками, в том числе их созданием и удалением. Акцент делается не на политику применения процессов и потоков, а на механизмы управления ими.

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

Интерфейс графических устройств управляет выводом изображений на мониторе и принтерах. Он предоставляет системные вызовы, которые позволяют пользовательским программам записывать информацию на монитор или принтеры независимо от типов этих устройств. Он также предоставляет драйверы устройств для вывода графики. В первых версиях Windows XP интерфейс графических устройств был реализован в пользовательском пространстве, однако производительность в этом случае оставляла желать лучшего, поэтому программисты компании Microsoft перенесли его в ядро. Многими системными вызовами управляет также модуль Win32. Изначально он тоже располагался в пользовательском пространстве, но позднее с целью повышения производительности был перемещен в ядро.

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

Вне ядра находятся пользовательские программы и подсистема окружения. Потребность в подсистеме окружения объясняется тем, что пользовательские программы не ориентированы на самостоятельное выполнение системных вызовов (хотя технически такая возможность у них есть). Поэтому подсистема окружения экспортирует определенную группу вызовов функций, с которыми пользовательские программы могут работать. Изначально существовали три подсистемы окружения: Win32 (для программ Windows NT, Windows 2000, Windows XP и Windows 95/98/ME), POSIX (для переносимых программ UNIX) и OS/2 (для переносимых программ OS/2). Из них на данный момент поддерживается только подсистема Win32. В то же время, существует ряд новых служб модуля UNIX, в некоторой степени обеспечивающих поддержку этой операционной системы.

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

Интерфейс Windows XP – это основное средство связи программиста с системой. Компания Microsoft определила набор функций, известный как Win32 API (Application Programming Interface — прикладной программный интерфейс). Это библиотечные функции, которые выполняют определенные действия либо в системе путем системных вызовов, либо в некоторых случаях непосредственно в библиотечной процедуре пользовательского пространства или подсистеме Win32. Набор Win32 API при создании новых версий Windows XP не меняется. Однако помимо Win32 API существуют процедуры Windows XP API, которые в новых версиях Windows XP могут меняться. Вызовы Win32 API документированы и достаточно стабильны. Когда в Windows была введена поддержка 64-разрядных машин, компания Microsoft изменила название набора с Win32 на Win64.

В системах Win32 API и UNIX применяются совершенно разные подходы. В UNIX все системные вызовы общеизвестны и формируют минимальный интерфейс: удаление хотя бы одного из них изменит функционирование операционной системы. Подсистема Win32 предоставляет избыточный интерфейс. Здесь часто одно и то же действие можно выполнить тремя или четырьмя разными способами. Кроме того, Win32 включает в себя много функций, которые не являются системными вызовами (например, копирование целого файла).

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

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

1. Консоль управление компьютером.

Консоль управления Microsoft Management Console (MMC) — средство для создания, сохранения и открытия средств администрирования (называемых консолями MMC), которые управляют оборудованием, программными и сетевыми компонентами операционной системы Windows. MMC является системным приложением операционной системы Windows 2000. MMC не выполняет административные функции, но на ней размещаются инструменты, выполняющие эти функции. Основной тип инструментов, которые можно добавить на консоль называется оснасткой. Другими добавляемыми элементами являются элементы управления, ссылки на веб-страницы, папки, виды панели задач и задачи.

Чтобы открыть консоль MMC необходимо выполнить:

o Пуск®Выполнить, ввести mmc и нажмите кнопку OK.

o В командной строке ввести mmc и нажмите клавишу ENTER.

Полный синтаксис командной строки для MMC выглядит следующим образом: mmc путь\имя_файла.msc [/a]

путь\имя_файла.msc – запускает MMC с открытием сохраненной консоли. Необходимо указать полный путь и имя файла для сохраненной консоли. Если файл консоли не указан, MMC открывает новую консоль.

Для создания командных строк и ярлыков, которые не зависят от явного расположения файлов консоли, можно использовать переменные среды. Например, если путь к файлу консоли включает системную папку (например, mmc c:\winnt\system32\console_name.msc), то для указания пути можно использовать переменную %systemroot%: (mmc %systemroot%\system32\ console_name.msc). Это полезно при делегировании заданий пользователям, работающим на разных компьютерах.

Ключ [/a] открывает сохраненную консоль в авторском режиме. Используется для внесения изменений в сохраненные консоли. Когда консоли открываются с этим параметром, они открываются в авторском режиме, независимо от режима, используемого по умолчанию. При этом установки режима по умолчанию для файлов не меняются; при пропуске этого параметра MMC открывает файлы консолей в соответствии с их режимами по умолчанию.

Новая консоль MMC представляет окно, разделенное на две области.

Левая область содержит две вкладки: вкладку Структура и вкладку Избранное. Правая область является областью сведений.

Вкладка Структура, называемая также деревом консоли, показывает элементы, доступные на данной консоли.

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

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

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

Есть два основных способа использования консоли MMC: в режиме пользователя, администрируя систему с помощью готовых консолей MMC, или в авторском режиме, создавая новые или изменяя существующие консоли MMC.

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

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

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

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

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

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

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

· авторский режим

· режим пользователя - полный доступ

· режим пользователя - ограниченный доступ, многооконный

· режим пользователя - ограниченный доступ, однооконный.

Эти параметры могут быть настроены в диалоговом окне Параметры в консоли MMC.

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

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