Гордеев А.В. Операционные системы

Подождите немного. Документ загружается.

372 Глава 11. Операционные системы Windows

В операционных системах семейства Windows 9x имеется два модуля для диспет-

черизации потоков выполнения: основной планировщик (primary scheduler) отве-

чает за вычисление приоритетов потоков; планировщик квантования (timeslice

scheduler) занимается расчетами, необходимыми для выделения квантов времени.

По сути дела, модуль квантования решает, какой процент доступного процессор-

ного времени какому потоку выделить. Если некий поток не получает времени на

выполнение, значит, он находится в состоянии ожидания выполнения (suspended)

и не будет работать, пока ситуация не изменится.

Основной планировщик просматривает все потоки выполнения и рассчитывает

для каждого из них приоритет выполнения (execution priority), который представ-

ляет собой целое число, находящееся в пределах от 0 до 31. Далее он переводит в

состояние ожидания выполнения все потоки, приоритет выполнения которых мень-

ше текущего наибольшего значения, имеющегося у одного из потоков. После того

как поток переведен в состояние ожидания выполнения, основной планировщик

более не обращает на него никакого внимания при дальнейших вычислениях при-

оритетов на протяжении данного кванта времени. По умолчанию длительность

кванта времени составляет 20 мс. Затем планировщик квантования рассчитывает

процентную долю кванта времени, которую необходимо выделить каждому пото-

ку. Для этого он использует значения приоритетов и информацию о текущем со-

стоянии виртуальной машины.

После окончания выделенного потоку кванта времени планировщик перемещает

его в конец очереди, состоящей из потоков с равным приоритетом. Этот класси-

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

потокам, обладающим равным наивысшим приоритетом, одинаковый доступ к про-

цессору. Если некоторый поток не занимает весь выделенный ему квант процес-

сорного времени, диспетчер передает процессор в распоряжение следующего по-

тока с таким же приоритетом и позволяет тому использовать остаток данного кванта

времени.

Если в системе одновременно работают только 32-разрядные приложения, то бо-

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

пользователю обеспечивает так называемое упреждающее планирование. Как из-

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

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

события. Сама операционная система также функционирует по этому принципу.

Управляющая (супервизорная) подсистема Windows 9x просматривает направля-

емый ей подсистемой ввода-вывода поток сообщений, из которых она и узнает о но-

вых событиях, таких, например, как щелчки мыши в одном из ее окон, запуск но-

вых программ и т. д. В системах Windows 3.x все сообщения находились в одной

системной очереди, вследствие чего одна некорректно работающая программа могла

заблокировать поток сообщений, предназначенных всем остальным приложени-

ям. Windows 95/98 дает системе возможность помещать сообщения, предназна-

ченные приложениям Win32, в отдельные очереди, что снижает вероятность зави-

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

сообщений должным образом.

Операционные системы Windows 9x

373

Распределение оперативной памяти

Для загрузки операционные системы Windows 95/98 используют операционную

систему MS DOS 7.0 (MS DOS 98), и в случае если в секции [Options] файла MSDOS.SYS

имеется строка BootGUI = 0, процессор работает в обычном реальном режиме (см.

главу 4). Распределение памяти в MS DOS 7.0 такое же, как и в предыдущих версиях

DOS. Однако при загрузке интерфейса GUI перед загрузкой ядра Windows 95/98

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

память уже с помощью страничного механизма.

Приложения и подсистемы Windows 9x (за исключением ядра) никогда не рабо-

тают с физической памятью. Разделение на виртуальную и физическую память

является ключевым аспектом работы системы. Приложения и подсистемы Win-

dows 9х имеют дело с определенными интерфейсами прикладного программиро-

вания и виртуальными адресными пространствами. Базовая система работает как

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

В основе поддержки виртуальных машин и виртуального адресного пространства,

которую обеспечивают операционные системы Windows 9x, лежит работа с реаль-

ной (физической) памятью компьютера, ограниченной в своих размерах. Опера-

ционная система выгружает неактивные страницы памяти виртуальных адресных

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

жает страницу, запрошенную при выполнении текущей команды. Другими слова-

ми, загрузка страницы в оперативную память осуществляется по требованию, как

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

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

тивная память от неактивных страниц группами по нескольку страниц за одну

операцию. Реализованный в операционных системах Windows 9x алгоритм заме-

щения представляет собой стандартную дисциплину LRU (Least Recently Used —

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

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

Многие страницы физической памяти компьютера не участвуют в замещении, они

распределены постоянно. Их занимают, в частности, резидентные компоненты ядра.

На эти цели отводится примерно один мегабайт памяти. За оставшуюся физичес-

кую память конкурируют различные программы: динамически загружаемые ком-

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

приложений, а также динамически размещаемые данные, такие как области кэши-

рования, необходимые для работы файловой системы, и буферы прямого доступа

к памяти (DMA).

В отличие от тех мультитерминальных систем, в которых операционная система

должна заботиться о равноправном совместном использовании ресурсов, в систе-

мах Windows 9x сделано иначе. Поскольку это однопользовательские операцион-

ные системы, они позволяют заполнять память так, как это нужно пользователю и

его программам. Динамически загружаемые компоненты системы конкурируют

за память с прикладными программами. Если пользователь хочет, чтобы его при-

ложение работало быстрее, ему будет позволено занять столько памяти, сколько

вообще возможно. Система накладывает ограничение на максимальный объем па-

374 Глава 11. Операционные системы Windows

мяти, который может быть отдан в распоряжение отдельных приложений, — если

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

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

деление памяти инициирует замещение страниц. Интересным побочным эффек-

том такого подхода является то, что у приложений нет надежного способа опреде-

ления объема памяти, доступного в системе. Функция API GlobalMemorySatusQ

возвращает целый ряд параметров, характеризующих состояние системной памя-

ти, однако это не более чем «мгновенный снимок» текущей обстановки — еще один

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

Страницы поступают в память и уходят из нее по-разному: в большинстве случаев

они либо непосредственно размещаются в выделенной для этого памяти (как ре-

зультат соответствующих запросов), либо загружаются при старте программы из

ЕХЕ-файла приложения. Впоследствии эти страницы начинают перемещаться

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

ся только код 32-разрядных приложений и динамически связываемых библиотек

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

Для того чтобы облегчить управление всем разнообразием типов страниц памяти,

каждая активная страница, то есть каждая страница, которая является частью вы-

полняющегося в данный момент системного модуля или приложения, снабжена хра-

нящимся совместно с ней страничным дескриптором (Page Descriptor, PD). В этом

дескрипторе содержатся адреса процедур, которые занимаются перемещением стра-

ницы из памяти на диск и обратно. Независимо от того, что именно находится в

данной странице, диспетчер физической памяти, чтобы переместить страницу в опе-

ративную память или из нее, просто вызывает соответствующую функцию, адрес

которой определен в поле дескриптора страницы. В случае, если некоторая страни-

ца еще никогда не заполнялась, она называется абсолютно чистой (virgin"). Напри-

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

Win32. После того как с момента размещения страницы в памяти в нее будет в первый

раз произведена запись данных, она считается испорченной (tainted) и может быть

либо грязной (dirty), либо чистой (clean), в зависимости от того, осуществлялась ли в

нее запись с момента последней ее подкачки в физическую память. Если запись в эту

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

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

Для наблюдения за распределением памяти и использованием иных ресурсов ком-

пьютера можно воспользоваться, например, программой SYSMON.EXE (системный

монитор). Эта программа входит в состав утилит операционных систем Windows

9х, поэтому после ее установки команда для ее запуска располагается в подменю

Служебные меню Стандартные. Она позволяет выбрать интересующие нас парамет-

ры и наблюдать за их текущими значениями.

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

использовать только один сегмент кода и один сегмент данных, которые имеют

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

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

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

Операционные с и стемы Windows 9x

375

(small) модель памяти [40]. Каждая прикладная программа определяется 32-раз-

рядными адресами, в которых сегмент кода имеет то же значение, что и сегменты

данных. Единственный сегмент программы отображается непосредственно в об-

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

состоит из 4-килобайтных страниц. Каждая страница может располагаться где угод-

но в оперативной памяти (естественно, в том месте, где ее разместит диспетчер

памяти, который сам находится в невыгружаемой области) или быть «сброшена»

на диск, если не запрещено использовать страничный файл.

В операционных системах Windows 9x младшие адреса виртуального адресного

пространства совместно используются всеми процессами. Это сделано для совме-

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

и некоторыми 16-разрядными программами Windows. Безусловно, это плохое ре-

шение с точки зрения надежности, поскольку оно приводит к тому, что любой про-

цесс может непреднамеренно (или же, наоборот, специально) испортить компо-

ненты, находящиеся в этих адресах.

В Windows 9x каждая 32-разрядная прикладная программа выполняется в соб-

ственном адресном пространстве, но все они используют совместно один и тот же

32-разрядный системный код. Доступ к чужим адресным пространствам в прин-

ципе возможен. Другими словами, виртуальные адресные пространства не задей-

ствуют всех аппаратных средств защиты, заложенных в микропроцессор. В резуль-

тате неправильно написанная 32-разрядная прикладная программа может привести

к аварийному сбою всей системы. Все 16-разрядные прикладные программы Win-

dows разделяют общее адресное пространство, поэтому они так же уязвимы друг

для друга, как и в среде Windows 3.X.

Собственно системный код Windows 9x размещается выше границы 2 Гбайт. В про-

странстве с отметками 2 и 3 Гбайт находятся системные библиотеки DLL, использу-

емые несколькими программами. Напомним, что в 32-разрядных микропроцессорах

семейства i80x86 имеется четыре уровня защиты, именуемые кольцами с номерами

от 0 до 3. Кольцо с номером 0 является наиболее привилегированным, то есть мак-

симально защищенным. Компоненты операционных систем Windows 9x, относя-

щиеся к кольцу 0, отображаются на виртуальное адресное пространство между

3 и 4 Гбайт. К этим компонентам относятся собственно ядро Windows, подсистема

управления виртуальными машинами, модули файловой системы и драйверы вир-

туальных устройств (VxD).

Область памяти между 2 и 4 Гбайт адресного пространства каждой 32-разрядной

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

ными программами. Такая организация позволяет обслуживать вызовы API не-

посредственно в адресном пространстве прикладной программы и ограничивает

размер рабочего множества. Однако за это приходится расплачиваться снижени-

ем надежности. Ничто не может помешать программе, содержащей ошибку, про-

извести запись в адреса, принадлежащие системным библиотекам DLL, и вызвать

крах всей системы.

В области между 2 и 3 Гбайт также находятся все запускаемые 16-разрядные при-

кладные программы Windows. С целью обеспечения совместимости эти програм-

376 Глава 11. Операционные системы Windows

мы выполняются в совместно используемом адресном пространстве, где они мо-

гут испортить друг друга так же, как и в Windows 3.x.

Адреса памяти ниже 4 Мбайт также отображаются в адресное пространство каж-

дой прикладной программы и совместно используются всеми процессами. Благо-

даря этому становится возможной совместимость с существующими драйверами

реального режима, которым необходим доступ к этим адресам. Это делает еще одну

область памяти не защищенной от случайной записи. К самым нижним адресам

(менее 64 Кбайт) этого адресного пространства 32-разрядные прикладные програм-

мы обращаться не могут, что дает возможность перехватывать неверные указате-

ли, но 16-разрядные программы, которые, возможно, содержат ошибки, могут за-

писывать туда данные.

Вышеизложенную модель распределения памяти можно проиллюстрировать с

помощью рис. 11.1.

4 Гбайт

3 Гбайт

2 Гбайт

4 Мбайт

64 Кбайт

Системные компоненты,

относящиеся к кольцу защиты О

- Системные библиотеки DLL

- Прикладные программы Win 16

- Совместно используемые

библиотеки DLL

Прикладные 32-разрядные

программы

Компоненты реального режима

Адреса между 2 и 4 Гбайт

отображаются в адресное пространство

каждой 32-разрядной программы

и используются совместно

В этой области адресного пространства

у каждой прикладной программы

располагается свое собственное

адресное пространство. «Личные» адресные

пространства других программ невидимы

для программы, и, следовательно,

она не может никак изменить

их содержимое

Эта область используется

всеми процессами

Рис. 11.1. Модель памяти операционных систем Windows 95/98

Операционные системы Windows 9x

377

В операционных системах Windows термином модуль (module) называют присут-

ствующую в памяти совокупность кода, данных и других ресурсов (в частности

таких, как битовые массивы). Обычно такая совокупность объектов представляет

собой отдельную прикладную программу или библиотеку DLL. Windows форми-

рует и поддерживает структуру данных под названием база данных модулей (module

database), в которой учитываются все активные в данный момент модули системы.

База данных модулей описывает статическую совокупность объектов в отличие от

той динамической, что поддерживает база данных задач. Учет загруженных в дан-

ный момент модулей необходим, потому что он служит основой поддерживаемого

Windows 9x механизма совместного использования ресурсов. Так, например, ког-

да мы вторично запускаем программу Word или Internet Explorer, операционная

система Windows обнаруживает, что сегменты кода и формирующий значок этой

программы — битовый массив — уже загружены, и вместо того чтобы загружать

еще одну копию, которая только отнимет память, она попросту заводит дополни-

тельные ссылки на уже используемые ресурсы.

На протяжении всего времени работы системы Windows 9x для каждого ресурса

поддерживают счетчик обращений к нему. По мере того как приложения исполь-

зуют тот или иной ресурс, Windows 9x увеличивают значение соответствующего

счетчика, а по завершении работы приложения уменьшают его. Значение счет-

чика, равное нулю, свидетельствует о том, что ресурс больше не используется,

а значит, система может удалить ресурс и освободить память, которую он зани-

мал.

Минимально допустимый объем оперативной памяти, начиная с которого эти

операционные системы могут функционировать, равен 4 Мбайт для Windows 95

и 8 Мбайт для Windows 98. Однако при таких маленьких объемах физической па-

мяти пробуксовка столь велика, что быстродействие системы становится слиш-

ком малым, и практически работать нельзя.

Страничный файл, с помощью которого реализуется механизм виртуальной памя-

ти, по умолчанию располагается в каталоге самой системы Windows и имеет пере-

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

файл при необходимости. Вместе с фрагментацией файла подкачки это приводит

к тому, что быстродействие системы становится меньше, чем если бы этот файл

был фиксированного размера и располагался в смежных кластерах (был бы де-

фрагментирован). Создать файл подкачки заданного размера можно либо через

специально разработанный для этого апплет (Панель управления • Система • Быс-

тродействие • Файловая система), либо просто прописав в секции [386Enh] файла

SYSTEM.INI строки с указанием диска и имени файла подкачки, например:

PagingDrive=C:

Pagi ngFi1е=С:\PageFiIe.sys

Mi nPagingFi1eSi ze=65536

MaxPagi ngFi1eSi ze=262144

Здесь первая и вторая строки описывают размещение страничного файла и его

имя, а две последних — начальный и предельный размеры страничного файла

(значения указываются в килобайтах). Для определения необходимого минималь-

ного размера можно рекомендовать запустить уже упомянутую выше программу

378

Глава 11. Операционные системы Windows

SYSMON.EXE

(системный монитор) и, выбрав в качестве наблюдаемых параметров

размер файла подкачки и объем свободной памяти, оценить потребности в памя-

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

Большое влияние на использование оперативной памяти и общую производитель-

ность системы оказывает драйвер виртуального устройства VCache, занимающийся

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

запрашивая и освобождая области памяти, которые впоследствии могут быть вы-

делены отдельным драйверам файловой системы для выполнения операций кэ-

ширования. Этот драйвер работает по методу агрессивного кэширования, в резуль-

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

странно, это не всегда приводит к увеличению скорости работы с файлами, по-

скольку поиск нужных блоков данных среди блоков, находящихся в кэше, осуще-

ствляется простым последовательным перебором, а количество просматриваемых

блоков в этом случае существенно больше. Поэтому в ряде случаев имеет смысл

ограничивать «аппетит» драйвера VCache. Сделать это можно путем редактирова-

ния все того же файла SYSTEM.INI. Только теперь нужно найти другую секцию фай-

ла — [VCache]. В эту секцию следует добавить строки и прописать значения для

максимального и минимально объемов оперативной памяти, которую операцион-

ная система будет предоставлять подсистеме кэширования. Выглядеть эти новые

строки могут, например, так:

MinFileCache=16384

MaxFileCache=65536

ChunkSize=2048

NameCache=4096

DirectoryCache=128

Назначение первой и второй строк представляется очевидным. Третья строка опи-

сывает размер блока, четвертая строка — количество хранимых в кэше имен фай-

лов, а последняя — количество каталогов. Прописанные в приведенных строках

значения, естественно, зависят от объема оперативной памяти, имеющейся в ком-

пьютере. В данном случае компьютер имеет 512 Мбайт оперативной памяти. Кста-

ти, если персональный компьютер имеет более 256 Мбайт памяти, то наличие пер-

вых двух строк в секции [VCache] файла SYSTEM.INI обязательно. В противном случае

из-за недальновидности разработчиков драйвера виртуального устройства VCache

он может запросить у системы более 256 Мбайт памяти, причем она может выде-

лить ему эту память. Это неминуемо приведет к критической ошибке в его даль-

нейшей работе и краху вычислительного процесса.

Операционные системы Windows NT/2000/XP

Краткая историческая справка

Компания Microsoft в 1990 году объявила о начале работ по созданию принципи-

ально новой операционной системы для персональных IBM PC-совместимых ком-

Программа SYSMON.EXE входит в состав штатного программного обеспечения систем Windows 9x,

но при обычной установке она не устанавливается — требуется выборочная установка.

Операционные системы Windows NT/2000/XP

379

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

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

качествами, как:

О микроядерная архитектура — сказалось влияние идей проекта Mach 3, выпол-

ненного в университете Карнеги Меллон (Carnegie Mellone University), кото-

рое в то время было очень велико;

• аппаратная независимость (platform independent), что должно было обеспечить

легкую переносимость системы;

Q мультипроцессорная обработка и масштабируемость (в то время операцион-

ные системы семейства UNIX обеспечивали работу на мультипроцессорных

компьютерах и фактически доминировали как мощные корпоративные сервер-

ные системы);

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

систем, в частности приложений для UNIX и 16-разрядных программ OS/2;

• защита информации и вычислений от несанкционированного доступа;

Q наличие высокопроизводительной и надежной файловой системы и возмож-

ность работать с несколькими файловыми системами;

Q встроенные сетевые функции и поддержка распределенных вычислений.

Этот проект изначально имел название OS/2 version 3.0, однако впоследствии

Microsoft назвала его Windows NT. Аббревиатура NT означала «New Technology»,

что подчеркивало принципиальную новизну этой операционной системы. Опера-

ционная система вышла в 1993 г. в двух вариантах и имела название Windows NT

3.1 и Windows NT Advanced Server 3.1. Эти системы обладали большими возмож-

ностями. Однако Windows NT 3.1 в качестве рабочей станции уступала системе

OS/2, поскольку требовала существенно больше оперативной памяти и имела от-

носительно низкое быстродействие. Кроме этого, при работе с дисками, отформа-

тированными под файловую систему FAT, она не поддерживала длинные имена.

Основным конкурентом серверной системы был сервер Novell Netware 3.x. После

выхода первой версии Windows NT Microsoft выпустила Windows NT 3.5 для ра-

бочих станций и одноименную серверную операционную систему. Последняя имела

встроенное программное обеспечение для связи с серверами от Novell, поддержи-

вала длинные имена при работе с дисками FAT, и много других усовершенствова-

ний. В те годы в качестве серверов для локальных вычислительных сетей пре-

имущественно использовалась операционная система Netware 3.x компании

Novell. В последующем эта сетевая операционная система была заменена суще-

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

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

лизованного хранения информации о сетевых ресурсах. Она имела продуман-

ные механизмы администрирования и была высокоэффективной. Завершилось

поколение операционных систем Windows NT 3.x версиями под номером 3.5.1.

Системы Windows NT 3.x не смогли тогда завоевать признание ни в качестве сер-

верных, ни в качестве обычных настольных систем, поскольку требовали очень

больших (по меркам того времени) вычислительных ресурсов.

380 Глава 11, Операционные системы Windows

Как ни странно, но еще одним недостатком этих первых систем Windows NT было

строгое следование идеям микроядерной архитектуры. Согласно идеологии кли-

ент-сервер, которой придерживались разработчики Windows NT 3.x, только ядро

и низкоуровневые драйверы работали в нулевом кольце привилегий. А драйверы

графической подсистемы, модули GDI, менеджер окон (Window Manager) и дру-

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

вательском режиме работы процессора. Такое решение обеспечивало высокую

надежность системы, но отрицательно сказывалось на ее производительности, по-

скольку приходилось многократно переключаться из режима ядра в пользователь-

ский режим и обратно. Полезно напомнить, что сделать это можно только через

механизм шлюзования. К тому же интерфейс этих первых операционных систем

класса NT соответствовал обычной 16-разрядной системе Windows 3.x, быстро

уходившей в прошлое, и заметно отличался от интерфейса Windows 95. Желая

исправить эти недочеты, Microsoft запустила проект Cairo и в 1996 г. выпустила

операционные системы Windows NT 4.0 Sever и Windows NT 4.0 Workstation.

Операционные системы Windows NT 4.0 оказались на редкость удачными. К мо-

менту их выхода вычислительные ресурсы среднего персонального компьютера уже

были достаточными для эффективной работы. Эти операционные системы в каче-

стве основного ресурса требовали оперативную память. Официально серверная си-

стема требовала 16 Мбайт, а рабочая станция — 12 Мбайт, в то время как для реаль-

ной работы памяти нужно было иметь раза в четаре больше. И поскольку стоимость

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

заметно снизилась, организации и отдельные пользователи стали массово осваивать

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

работу графической подсистемы, в привилегированный режим работы процессора

существенно увеличил быстродействие при обработке графики и позволил в после-

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

К сожалению, в своей новой операционной системе компания Microsoft отказа-

лась от поддержки высокопроизводительной файловой системы HPFS, с которой

работают операционные системы OS/2, хотя при желании пользователь мог сам до-

бавить соответствующие драйверы из дистрибутива предыдущей Windows NT 3.x.

Это был один из тех мелких уколов, которые в совокупности помогали компании

Microsoft «уводить» пользователей от операционных систем OS/2.

Желая противопоставить свою серверную операционную систему известным се-

тевым операционным системам корпоративного уровня Novell Netware 4.x и Net-

ware 5.x, компания Microsoft разработала новое семейство операционных систем

класса NT, которое должно было изначально называться Windows NT 5.0, однако

из маркетинговых соображений было переименовано в Windows 2000. В семей-

ство этих систем вошли четыре операционные системы.

Q Windows 2000 Professional — для использования в качестве рабочей станции

вместо Windows NT.40 Workstation или Windows 98. Эта операционная систе-

ма может работать на 2-процессорных компьютерах.

• Windows 2000 Server — для использования в качестве контроллера домена и/или

сервера (файлов, приложений, баз данных, web и/или FTP, печати и т. д.) в от-

Операционные системы Windows NT/2000/XP 381

носительно небольшой сети, которую могут себе позволить иметь предприятия

малого и среднего бизнеса. Эта операционная система поддерживает 4-процес-

сорные конфигурации.

• Windows 2000 Advanced Server — для тех же целей, что и Windows 2000 Server,

но с упором на выполнение функций сервера приложений и сервера баз дан-

ных. Обладает возможностью работать на компьютере с восемью процессора-

ми и, самое главное, организовать кластер из двух машин.

a Windows 2000 Datacenter Server — специальная версия операционной систе-

мы, предназначенная для работы в вычислительных сетях крупных предприя-

тий. Система хорошо масштабируется, позволяет построить 4-узловой кластер,

причем каждая из машин может иметь вплоть до 16 процессоров

Наверное, самыми главными особенностями этих операционных систем (по сравне-

нию с предыдущими Windows NT 4.0) следует назвать поддержку механизма Plug

and Play (как и в системах Windows 9x) и использование службы каталогов как ос-

новы для построения сетей клиент-сервер. Служба каталогов Microsoft получила

наименование Active Directory. Принципиальной особенностью этой технологии яв-

ляется ее глубокая интеграция с TCP/IP. Кроме этого, нельзя не отметить, что но-

вые операционные системы получили переработанную систему управления файла-

ми, которая получила наименование NTFS5

. Интересно отметить, что были удалены

все остатки кода, до этого позволявшие устанавливать файловую систему HPFS.

Для этого поколения операционных систем Microsoft сочла нецелесообразным

переносить их на платформы Alpha (DEC), PowerPC, MIPS.

Осенью 2001 года Microsoft обновила операционную систему Windows 2000 Pro-

fessional до Windows XP (eXPerience). При этом она выпустила две редакции. Одна

из них представляла собой «облегченный» вариант системы для домашнего при-

менения. Она получила название Windows XP Home Edition. Эту операционную

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

ра. Вторая — полноценная система с предназначением работать в качестве рабо-

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

сети с выходом в Интернет. Эти операционные системы, прежде всего, получили

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

функций Win32 API: и для Windows 9x, и для систем класса NT. Системы Windows

ХР в еще большей мере стали мультимедийными и ориентированными на Интер-

нет. Интересным новшеством для систем Windows стала возможность организо-

вать одновременную работу с компьютером двух пользователей: для одного непо-

средственно (локально), а для второго удаленно с другого компьютера. В принципе,

в этом нет ничего особенного. Например, операционная система UNIX позволяет

без проблем организовать не только такое взаимодействие, но и полноценную муль-

титерминальную работу. Но для систем Windows — это явно новая возможность.

Наконец, весной 2003 года на замену семейству Windows 2000 вышли несколько сер-

верных операционных систем, которые получили в название число 2003. Это сле-

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

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

Подробней об этой файловой системе см. в главе 6.