20. Управление памятью в реальном режиме на примере консоли

Windows XP и MS DOS.

Вопрос на стадии разработки ))) по ходу это первая лаба

21. Задачи подсистемы управления внешними устройствами.

Подсистема ввода-вывода (Input-Output Subsystem) мультипрограммной ОС при обмене данными с внешними устройствами компьютера должна решать ряд общих задач, из которых наиболее важными являются следующие:

• организация параллельной работы устройств ввода-вывода и процессора;

• согласование скоростей обмена и кэширование данных;

• разделение устройств и данных между процессами;

• обеспечение удобного логического интерфейса между устройствами и остальной частью системы;

• поддержка широкого спектра драйверов с возможностью простого включения в систему нового драйвера;

• динамическая загрузка и выгрузка драйверов;

• поддержка нескольких файловых систем;

• поддержка синхронных и асинхронных операций ввода-вывода.

Организация параллельной работы устройств ввода-вывода и процессора

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

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

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

Согласование скоростей обмена и кэширование данных

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

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

Другим решением этой проблемы является использование большой буферной памяти в контроллерах внешних устройств. Такой подход особенно полезен в тех случаях, когда помещение данных на диск слишком замедляет обмен (или когда данные выводятся на сам диск). Например, в контроллерах графических дисплеев применяется буферная память, соизмеримая по объему с оперативной, и это существенно ускоряет вывод графики на экран.

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

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

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

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

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

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

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

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

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

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

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

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

Драйвер взаимодействует, с одной стороны, с модулями ядра ОС (модулями подсистемы ввода-вывода, модулями системных вызовов, модулями подсистем управления процессами и памятью и т. д.), а с другой стороны — с контроллерами внешних устройств. Поэтому существуют два типа интерфейсов: интерфейс «драйвер-ядро» (Driver Kernel Interface, DKI) и интерфейс «драйвер-устройство» {Driver Device Interface, DDF). Интерфейс «драйвер-ядро» должен быть стандартизован в любом случае, а интерфейс «драйвер-устройство» имеет смысл стандартизировать тогда, когда подсистема ввода-вывода не разрешает драйверу непосредственно взаимодействовать с аппаратурой контроллера, а выполняет эти операции самостоятельно. Экранирование драйвера от аппаратуры является весьма полезной функцией, так как драйвер в этом случае становится независимым от аппаратной платформы. Подсистема ввода-вывода может поддерживать несколько различных типов интерфейсов DKI/DDI, предоставляя специфический интерфейс для устройств определенного класса. Так, в ОС Windows NT для драйверов сетевых адаптеров существует интерфейс стандарта NDIS (Network Driver Interface Specification), в то время как драйверы сетевых транспортных протоколов взаимодействуют с верхними слоями сетевого программного обеспечения по интерфейсу TDI (Transport Driver Interface).

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

Для поддержки процесса разработки драйверов операционной системы обычно выпускается так называемый пакет DDK (Driver Development Kit), представляющий собой набор соответствующих инструментальных средств — библиотек, компиляторов и отладчиков.

Динамическая загрузка и выгрузка драйверов

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

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

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

Поддержка нескольких файловых систем

Диски представляют особый род периферийных устройств, так как именно на них хранится большая часть как пользовательских, так и системных данных. Данные на дисках организуются в файловые системы, и свойства файловой системы во многом определяют свойства самой ОС — ее отказоустойчивость, быстродействие, максимальный объем хранимых данных. Популярность файловой системы часто приводит к ее миграции из «родной» ОС в другие операционные системы — например, файловая система FAT появилась первоначально в MS-DOS, но затем была реализована в OS/2, семействе MS Windows и многих реализациях UNIX. Ввиду этого поддержка нескольких популярных файловых систем для подсистемы ввода-вывода также важна, как и поддержка широкого спектра периферийных устройств. Важно также, чтобы архитектура подсистемы ввода-вывода позволяла достаточно просто включать в ее состав новые типы файловых систем, без необходимости переписывания кода. Обычно в операционной системе имеется специальный слой программного обеспечения, отвечающий за решение данной задачи, например слой VFS ( Virtual File System) в версиях UNIX на основе кода System V Release 4.

Поддержка синхронных и асинхронных операций ввода-вывода

Операция ввода-вывода может выполняться по отношению к программному модулю, запросившему операцию, в синхронном или асинхронном режимах. Смысл этих режимов тот же, что и для рассмотренных выше системных вызовов, — синхронный режим означает, что программный модуль приостанавливает свою работу до тех пор, пока операция ввода-вывода не будет завершена (рис. 7.1, а), а при асинхронном режиме программный модуль продолжает выполняться в мультипрограммном режиме одновременно с операцией ввода-вывода (рис. 7Л, б). Отличие же заключается в том, что операция ввода-вывода может быть инициирована не только пользовательским процессом — в этом случае операция выполняется в рамках системного вызова, но и кодом ядра, например кодом подсистемы виртуальной памяти для считывания отсутствующей в памяти страницы.

Рис. 7.1. Два режима выполнения операций ввода-вывода

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

22. Подсистема управления файлами. Задачи ОС по управлению файлами.

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

Стандартные файлы ввода и вывода, перенаправление ввода-вывода.

Файловые системы Unix (s5 и ufs), FAT, NTFS.

Контроль доступа к файлам в системах Unix и в Windows NT/2000/XP

Управление файлами и внешними устройствами осуществляется совместной работой двух подсистем – файловой системы и подсистемы ввода-вывода.

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

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

Подсистема ввода-вывода (Input-Output Subsystem) мультипрограммной ОС при обмене данными с внешними устройствами компьютера должна решать ряд общих задач, из которых наиболее важными являются следующие:

• организация параллельной работы устройств ввода-вывода и процессора;

• согласование скоростей обмена и кэширование данных;

• разделение устройств и данных между процессами;

• обеспечение удобного логического интерфейса между устройствами и остальной частью системы;

• поддержка широкого спектра драйверов с возможностью простого включения в систему нового драйвера;

• динамическая загрузка и выгрузка драйверов;

• поддержка нескольких файловых систем;

• поддержка синхронных и асинхронных операций ввода-вывода.

Логическая организация файловой системы

Одной из основных задач операционной системы является предоставление удобств пользователю при работе с данными, хранящимися на дисках. Для этого ОС подменяет физическую структуру хранящихся данных некоторой удобной для пользователя логической моделью. Логическая модель файловой системы материализуется в виде дерева каталогов, выводимого на экран такими утилитами, как Norton Commander или Windows Explorer, в символьных составных именах файлов, в командах работы с файлами. Базовым элементом этой модели является файл, который так же, как и файловая система в целом, может характеризоваться как логической, так и физической структурой.

Цели и задачи файловой системы

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

Основные цели использования файла перечислены ниже.

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

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

Файловая система (ФС) — это часть операционной системы, включающая:

• совокупность всех файлов на диске;

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

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

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

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

Задачи, решаемые ФС, зависят от способа организации вычислительного процесса в целом. Самый простой тип — это ФС в однопользовательских и однопрограммных ОС, к числу которых относится, например, MS-DOS. Основные функции в такой ФС нацелены на решение следующих задач:

• именование файлов;

• программный интерфейс для приложений;

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

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

Задачи ФС усложняются в операционных однопользовательских мультипрограммных ОС, которые, хотя и предназначены для работы одного пользователя, но дают ему возможность запускать одновременно несколько процессов. Одной из первых ОС этого типа стала OS/2. К перечисленным выше задачам добавляется новая задача совместного доступа к файлу из нескольких процессов. Файл в этом случае является разделяемым ресурсом, а значит, файловая система должна решать весь комплекс проблем, связанных с такими ресурсами. В частности, в ФС должны быть предусмотрены средства блокировки файла и его частей, предотвращения гонок, исключение тупиков, согласование копий и т. п.

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

Еще более сложными становятся функции ФС, которая работает в составе сетевой ОС. Эта тема рассматривается в последней главе книги, посвященной управлению сетевыми ресурсами.

Физическая организация и адресация файла

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

• скорость доступа к данным;

• объем адресной информации файла;

• степень фрагментированности дискового пространства;

• максимально возможный размер файла.

Непрерывное размещение — простейший вариант физической организации (рис. 7.11, а), при котором файлу предоставляется последовательность кластеров диска, образующих непрерывный участок дисковой памяти. Основным достоинством этого метода является высокая скорость доступа, так как затраты на поиск и считывание кластеров файла минимальны. Также минимален объем адресной информации — достаточно хранить только номер первого кластера и объем файла. Данная физическая организация максимально возможный размер файла не ограничивает. Однако этот вариант имеет существенные недостатки, которые затрудняют его применимость на практике, несмотря на всю его логическую простоту. При более пристальном рассмотрении оказывается, что реализовать эту схему не так уж просто. Действительно, какого размера должна быть непрерывная область, выделяемая файлу, если файл при каждой модификации может увеличить свой размер? Еще более серьезной проблемой является фрагментация. Спустя некоторое время после создания файловой системы в результате выполнения многочисленных операций создания и удаления файлов пространство диска неминуемо превращается в «лоскутное одеяло», включающее большое число свободных областей небольшого размера. Как всегда бывает при фрагментации, суммарный объем свободной памяти может быть очень большим, а выбрать место для размещения файла целиком невозможно. Поэтому на практике используются методы, в которых файл размещается в нескольких, в общем случае несмежных областях диска.

Рис. 7.11. Физическая организация файла: непрерывное размещение (а); связанный список кластеров (б);

связанный список индексов (в); перечень номеров кластеров (г)

Следующий способ физической организации — размещение файла в виде связанного списка кластеров дисковой памяти (рис. 7.11, б). При таком способе в начале каждого кластера содержится указатель на следующий кластер. В этом случае адресная информация минимальна: расположение файла может быть задано одним числом — номером первого кластера. В отличие от предыдущего способа каждый кластер может быть присоединен к цепочке кластеров какого-либо файла, следовательно, фрагментация на уровне кластеров отсутствует. Файл может изменять свой размер во время своего существования, наращивая число кластеров. Недостатком является сложность реализации доступа к произвольно заданному месту файла — чтобы прочитать пятый по порядку кластер файла, необходимо последовательно прочитать четыре первых кластера, прослеживая цепочку номеров кластеров. Кроме того, при этом способе количество данных файла, содержащихся в одном кластере, не равно степени двойки (одно слово израсходовано на номер следующего кластера), а многие программы читают данные кластерами, размер которых равен степени двойки.

Популярным способом, применяемым, например, в файловой системе FAT, является использование связанного списка индексов (рис. 7.11, в). Этот способ является некоторой модификацией предыдущего. Файлу также выделяется память в виде связанного списка кластеров. Номер первого кластера запоминается в записи каталога, где хранятся характеристики этого файла. Остальная адресная информация отделена от кластеров файла. С каждым кластером диска связывается некоторый элемент — индекс. Индексы располагаются в отдельной области диска — в MS-DOS это таблица FAT (File Allocation Table), занимающая один кластер. Когда память свободна, все индексы имеют нулевое значение. Если некоторый кластер N назначен некоторому файлу, то индекс этого кластера становится равным либо номеру М следующего кластера данного файла, либо принимает специальное значение, являющееся признаком того, что этот кластер является для файла последним. Индекс же предыдущего кластера файла принимает значение N, указывая на вновь назначенный кластер.

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

Еще один способ задания физического расположения файла заключается в простом перечислении номеров кластеров, занимаемых этим файлом (рис. 7.11, г). Этот перечень и служит адресом файла. Недостаток данного способа очевиден: длина адреса зависит от размера файла и для большого файла может составить значительную величину. Достоинством же является высокая скорость доступа к произвольному кластеру файла, так как здесь применяется прямая адресация, которая исключает просмотр цепочки указателей при поиске адреса произвольного кластера файла. Фрагментация на уровне кластеров в этом способе также отсутствует.

Последний подход с некоторыми модификациями используется в традиционных файловых системах ОС UNIX s5 и ufs. Для сокращения объема адресной информации прямой способ адресации сочетается с косвенным.

В стандартной на сегодняшний день для UNIX файловой системе ufs используется следующая схема адресации кластеров файла. Для хранения адреса файла выделено 15 полей, каждое из которых состоит из 4 байт (рис. 7.12). Если размер файла меньше или равен 12 кластерам, то номера этих кластеров непосредственно перечисляются в первых двенадцати полях адреса. Если кластер имеет размер 8 Кбайт (максимальный размер кластера, поддерживаемого в ufs), то таким образом можно адресовать файл размером до 8192x12 - 98 304 байт.

Рис. 7.12. Схема адресации файловой системы ufs

Если размер файла превышает 12 кластеров, то следующее 13-е поле содержит адрес кластера, в котором могут быть расположены номера следующих кластеров файла. Таким образом, 13-й элемент адреса используется для косвенной адресации. При размере в 8 Кбайт кластер, на который указывает 13-й элемент, может содержать 2048 номеров следующих кластеров данных файла и размер файла может возрасти до 8192х(12+2048)=16 875 520 байт.

Если размер файла превышает 12+2048— 2060 кластеров, то используется 14-е поле, в котором находится номер кластера, содержащего 2048 номеров кластеров, каждый из которых хранят 2048 номеров кластеров данных файла. Здесь применяется уже двойная косвенная адресация. С ее помощью можно адресовать кластеры в файлах, содержащих до 8192х(12+2048+20482) = 3,43766x10'° байт.

И наконец, если файл включает более 12+2048+20482 = 4 196 364 кластеров, то используется последнее 15-е поле для тройной косвенной адресации, что позволяет задать адрес файла, имеющего следующий максимальный размер:

8192х(12+2048+20482+20483)=7,0403х1013 байт.

Таким образом, файловая система ufs при размере кластера в 8 Кбайт поддерживает файлы, состоящие максимум из 70 триллионов байт данных, хранящихся в 8 миллиардах кластеров. Как видно на рис. 7.12, для задания адресной информации о максимально большом файле требуется: 15 элементов по 4 байта (60 байт) в центральной части адреса плюс 1+(1+2048)+(1+2048+20482) = 4 198403 кластера в косвенной части адреса. Несмотря на огромную величину, это число составляет всего около 0,05 % от объема адресуемых данных.

Файловая система ufs поддерживает дисковые кластеры и меньших размеров, при этом максимальный размер файла будет другим. Используемая в более ранних версиях UNIX файловая система s5 имеет аналогичную схему адресации, но она рассчитана на файлы меньших размеров, поэтому в ней используется 13 адресных элементов вместо 15.

Метод перечисления адресов кластеров файла задействован и в файловой системе NTFS, используемой в ОС Windows NT/2000. Здесь он дополнен достаточно естественным приемом, сокращающим объем адресной информации: адресуются не кластеры файла, а непрерывные области, состоящие из смежных кластеров диска. Каждая такая область, называемая отрезком (run), или экстентом (extent), описывается с помощью двух чисел: начального номера кластера и количества кластеров в отрезке. Так как для сокращения времени операции обмена ОС старается разместить файл в последовательных кластерах диска, то в большинстве случаев количество последовательных областей файла будет меньше количества кластеров файла и объем служебной адресной информации в NTFS сокращается по сравнению со схемой адресации файловых систем ufs/s5.

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

Файловые операции

Файловая система ОС должна предоставлять пользователям набор операций работы с файлами, оформленный в виде системных вызовов. Этот набор обычно состоит из таких системных вызовов, как creat (создать файл), read (читать из файла), write (записать в файл) и некоторых других.

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

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

1. По символьному имени файла найти его характеристики, которые хранятся в файловой системе на диске.

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

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

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

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

Операционная система может выполнять последовательность действий над файлом двумя способами (рис. 7.26):

• Для каждой операции выполняются как универсальные, так и уникальные действия. Такая схема иногда называется схемой без запоминания состояния операций (stateless).

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

Подавляющее большинство файловых систем поддерживает второй способ организации файловых операций как более экономичный и быстрый. Первый способ обладает одним преимуществом — он более устойчив к сбоям в работе системы, так как каждая операция является самодостаточной и не зависит от результата предыдущей. Поэтому первый способ иногда применяется в распределенных сетевых файловых системах (например, в Network File System, NFS компании Sun), когда сбои из-за потерь пакетов или отказов одного из сетевых узлов более вероятны, чем при локальном доступе к файлам.

Рис. 7.26. Два способа выполнения файловых операций

При втором способе в файловой системе вводятся два специальных системных вызова: open — открытие файла, и close — закрытие файла.

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

Операции открытия и закрытия файла в той или иной форме утвердились в операционных системах очень давно. Даже в такой «старой» операционной системе, как OS/360, существовала макрокоманда OPEN, по которой в специальном буфере, называемом DCB (Data Control Block), собирались из различных источников все нужные характеристики набора данных (понятие, близкое к современному понятию файла), используемые затем при выполнении операций чтения и записи.

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

Открытие файла

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

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

По номеру индексного дескриптора inode файловая система находит нужную запись на диске и копирует из нее характеристики файла в оперативную память.

Для хранения копии индексного дескриптора используются буферные области системного виртуального пространства. Характеристики индексного дескриптора, перенесенные в оперативную память, помещаются в структуру так называемого виртуального дескриптора vnode (virtual node). Структура vnode включает поля индексного дескриптора файла inode, а также несколько перечисленных ниже дополнительных полей, полезных при выполнении операций с файлом.

• Состояние индексного дескриптора в памяти, отражающее:

• заблокирован ли файл;

• ждет ли снятия блокировки с файла какой-либо процесс;

• отличается ли представление характеристик файла в памяти от своей дисковой копии в результате изменения содержимого индексного дескриптора;

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

• является ли файл точкой монтирования.

• Логический номер устройства файловой системы, содержащей файл.

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

• Счетчик ссылок на данную структуру vnode.

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

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

При каждом открытии процессом файла ОС проверяет права пользовательского процесса на выполнение запрошенной операции с файлом и, если проверка прошла успешно, создает в системной области памяти новую структуру f i I e, которая описывает как открытый файл, так и операции, которые процесс собирается производить с файлом (например, чтение).

Структура file содержит такие поля, как:

• признак режима открытия (только для чтения, для чтения и записи и т. п.);

• указатель на структуру vnode;

• текущее смещение в файле (переменная offset) при операциях чтения/записи; О счетчик ссылок на данную структуру;

• указатель на структуру, содержащую права процесса, открывшего файл (эта структура находится в дескрипторе процесса);

• указатели на предыдущую и последующую структуры file, связывающие все такие структуры в двойной список.

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

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

После создания структуры file операционная система помещает указатель на нее в таблицу открытых файлов процесса, которая находится в контексте процесса. Если процесс несколько раз открывает один и тот же файл, то структура file создается для каждой операции открытия. Так как контекст процесса-родителя в UNIX наследуется процессом-потомком, то потомок наследует и указатели на все открытые родителем файлы, получая возможность выполнять над ними операции.

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

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

Для открытия файла /bin/prog1.ехе в режиме «только для чтения» прикладной программист может использовать следующее выражение на языке С:

fd =open("'/bin/progl.exe". 0_RDONLY):

Здесь fd — это целочисленная переменная, сохраняющая значение дескриптора открытого файла. Ее значение должно использоваться в операциях обмена данными с файлом /bin/prog1 .exe. При неудачной попытке открытия файла (нет прав для выполнения затребованной операции, неверное имя файла) переменной fd присваивается значение -1, которое является индикатором ошибки для всех системных вызовов UNIX.

Рис. 7.27. Связь процесса с открытыми файлами

Обмен данными с файлом

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

Системный вызов чтения данных из файла read имеет три аргумента:

read(fd,buffer,nbytes);

Первый аргумент fd является целочисленной переменной, имеющей значение дескриптора открытого файла. Второй аргумент buffer является указателем на область пользовательской памяти, в которую система должна поместить считанные данные. Количество байт этой области памяти задается третьим целочисленным аргументом nbytes. Функция read возвращает действительное количество считанных байт (оно может отличаться от заданного, если, например, была задана область чтения, выходящая за пределы файла) или же код ошибки -1.

Начало дисковой области, которую нужно прочитать с помощью вызова read, явно в этом системном вызове не указывается. Чтение начинается с того байта, на который указывает смещение offset в структуре file. На это смещение указывает запись с номером fd в таблице открытых файлов процесса. После выполнения вызова read смещение offset наращивается на количество прочитанных байт.

Вид системного вызова записи данных write аналогичен вызову read:

write(fd.buffer.nbytes):

Функция write записывает nbytes из буфера оперативной памяти buffer в файл, описываемый дескриптором fd. Функция write, так же как и read, возвращает вызвавшей ее программе значение реально переданных ею байт или код ошибки.

Рассмотрим пример, в котором прикладная программа работает с файлом, состоящем из записей фиксированной длины в 50 байт:

fd =open("/doc/qwery/basel2.txt". 0_RDWR):

readCfd.bufferl.50):

read(fd.buffer2.2500):

lseekCfd,150.0): write (fd.output. 300):

close(fd):

В приведенном фрагменте программы после открытия файла /doc/query/base12.txt для чтения и записи выполняется чтение первой записи файла, а затем читается область файла, включающая еще 50 записей, начиная со 2 по 51. После обработки считанных записей (эти инструкции опущены) производятся перемещение указателя смещения в файле на начало четвертой записи и запись результатов в шесть последовательных записей, начиная с четвертой. Завершается фрагмент закрытием файла с помощью системного вызова close.

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

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

Блокировки файлов

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

Процессы могут иметь соответствующие права доступа к файлу, но одновременное использование этих прав (в особенности права записи) может привести к некорректным результатам. Примером такой ситуации является одновременное редактирование одного и того же документа несколькими пользователями. Если доступ к файлу не управляется блокировками, то каждый пользователь, который имеет право записи в файл, работает со своей копией данных файла. Результат такого редактирования непредсказуем — он зависит от того, в какой последовательности записывали изменения в файл применяемые пользователями приложения-редакторы.

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

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

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

В UNIX существуют два режима действия блокировок — консультативный (advisory) и обязательный (mandatory). Основным рекомендуемым для использования режимом является консультативный. При нем операционная система не занимается блокированием операций с файлом, а только устанавливает признаки блокирования областей в структурах file, поддерживающих операции с файлами. Кооперирующиеся процессы обязательно должны проверять наличие блокировок на файл, чтобы синхронизировать свою работу. Если же блокировки установлены, но процесс не проверяет их, то операционная система не запрещает доступ процесса к файлу, когда процесс делает системные вызовы read или write.

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

Стандартные файлы ввода и вывода, перенаправление вывода

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

read(stdio. bufer. nbytes);

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

Аналогично, так как stdout — предопределенное имя дескриптора стандартного файла вывода, процесс может вывести данные в стандартный файл вывода, применив следующий системный вызов:

write(stout. buffer, nbytes):

За стандартным файлом ошибок закреплено имя stderr.

Фактически при создании нового процесса ОС помещает в его таблицу открытых файлов три записи: с номером 0 — для стандартного файла ввода (следовательно, stdin всегда имеет значение 0), с номером 1 — для стандартного файла вывода (stdout=l), и с номером 2 — для стандартного файла ошибок (stderr=2). Соответственно создаются и три структуры типа file, на которые указывают первые три записи таблицы открытых файлов процесса.

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

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

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

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

Рассмотрим несколько примеров команд UNIX, работающих со стандартными файлами ввода и вывода:

• ls dir2 — читает записи каталога dir2 и выводит их в определенном символьном формате в стандартный файл вывода;

• we — фильтр, который читает последовательность байт из стандартного файла ввода, подсчитывает число слов, строк или символов в считанных данных и выводит результат в стандартный файл вывода;

• who — выводит в стандартный файл информацию о пользователях, работающих в системе.

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

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

Для перенаправления стандартного вывода требуется следующая конструкция: > file

Например, показанная ниже командная строка запишет данные о содержимом каталога dir2 в файл a.txt: ls dir2 > a.txt

Механизм перенаправления ввода-вывода, введенный ОС UNIX, получил широкое распространение в интерпретаторах команд многих операционных систем, например MS-DOS, Windows, OS/2.

Физическая организация s5 и ufs

Файловые системы s5 (получившие название от System V, родового имени нескольких версий ОС UNIX, разработанных в Bell Labs компании AT&T) и ufs (UNIX File System) используют очень близкую физическую модель. Это не удивительно, так как система ufs является развитием системы s5. Файловая система ufs расширяет возможности s5 по поддержке больших дисков и файлов, а также повышает ее надежность.

Расположение файловой системы s5 на диске иллюстрирует рис. 7.15. Раздел диска, где размещается файловая система, делится на четыре области:

• загрузочный блок;

• суперблок (superblock) содержит самую общую информацию о файловой системе: размер файловой системы, размер области индексных дескрипторов, число индексных дескрипторов, список свободных блоков и список свободных индексных дескрипторов, а также другую административную информацию;

• область индексных дескрипторов (inode list), порядок расположения индексных дескрипторов в которой соответствует их номерам;

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

Рис. 7.15. Расположение файловой системы s5 на диске

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

• идентификатор владельца файла;

• тип файла; файл может быть файлом обычного типа, каталогом, специальным файлом, а также конвейером или символьной связью;

• права доступа к файлу;

• временные характеристики: время последней модификации файла, время последнего обращения к файлу, время последней модификации индексного дескриптора;

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

• адресная информация (структура адреса рассмотрена выше в разделе «Физическая организация и адресация файла»);

• размер файла в байтах.

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

Запись о файле в каталоге состоит всего из двух полей: символьного имени файла и номера индексного дескриптора. Например, на рис. 7.16 показана информация, содержащаяся в каталоге /user.

Рис. 7.16. Структура каталога в файловой системе s5

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

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

Рис. 7.17. Поиск адреса файла по его символьному имени

Рассмотрим эту процедуру на примере файла /bin/my_shell/print, входящего в состав файловой системы, изображенной на рис. 7.17. Определение физического адреса этого файла включает следующие этапы.

1. Прежде всего просматривается корневой каталог с целью поиска первой составляющей символьного имени — bin. Определяется номер (в данном примере — 6) индексного дескриптора каталога, входящего в корневой каталог. Адрес корневого каталога известен системе.

2. Из области индексных дескрипторов считывается дескриптор с номером 6. Начальный адрес дескриптора определяется на основании известных системе номера начального сектора области индексных дескрипторов и размера индексного дескриптора. Из индексного дескриптора 6 определяется физический адрес каталога /bin.

3. Просматривается каталог /bin с целью поиска второй составляющей символьного имени my_shell. Определяется номер индексного дескриптора каталога /bin/my_shell (в данном случае — 25).

4. Считывается индексный дескриптор 25, определяется физический адрес /bin/my_shell.

5. Просматривается каталог /bin/my_shell, определяется номер индексного дескриптора файла print (в данном случае — 131).

6. Из индексного дескриптора 131 определяются номера блоков данных, а также другие характеристики файла /bin/my_shell/print.

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

Физическая организация файловой системы ufs отличается от описанной физической организации файловой системы s5 тем, что раздел состоит из повторяющейся несколько раз последовательности областей «загрузчик—суперблок—блок группы цилиндров—область индексных дескрипторов» (рис. 7.18).

Рис. 7.18. Физическая организация файловой системы ufs

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

Кроме того, в ufs имена файлов могут иметь длину до 255 символов (кодировка ASCII, по одному байту на символ), в то время как в s5 длина имени не может превышать 14 символов.

Физическая организация FAT

Логический раздел, отформатированный под файловую систему FAT, состоит из следующих областей (рис. 7.13).

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

• Основная копия FA Т содержит информацию о размещении файлов и каталогов на диске.

• Резервная копия FAT.

• Корневой каталог занимает фиксированную область размером в 32 сектора (16 Кбайт), что позволяет хранить 512 записей о файлах и каталогах, так как каждая запись каталога состоит из 32 байт.

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

Рис. 7.13. Физическая структура файловой системы FAT

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

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

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

• кластер свободен (не используется);

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

• последний кластер файла; О дефектный кластер; а резервный кластер.

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

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

Размер таблицы FAT и разрядность используемых в ней индексных указателей определяется количеством кластеров в области данных. Для уменьшения потерь из-за фрагментации желательно кластеры делать небольшими, а для сокращения объема адресной информации и повышения скорости обмена наоборот — чем больше, тем лучше. При форматировании диска под файловую систему FAT обычно выбирается компромиссное решение и размеры кластеров выбираются из диапазона от 1 до 128 секторов, или от 512 байт до 64 Кбайт.

Очевидно, что разрядность индексного указателя должна быть такой, чтобы в нем можно было задать максимальный номер кластера для диска определенного объема. Существует несколько разновидностей FAT, отличающихся разрядностью индексных указателей, которая и используется в качестве условного обозначения: FAT12, FAT16 и FAT32. В файловой системе FAT12 используются 12-разрядные указатели, что позволяет поддерживать до 4096 кластеров в области данных диска, в FAT16 — 16-разрядные указатели для 65 536 кластеров и в FAT32 — 32-разрядные для более чем 4 миллиардов кластеров.

Рис. 7.14. Списки указателей файлов в FAT

Форматирование FAT 12 обычно характерно только для небольших дисков объемом не более 16 Мбайт, чтобы не использовать кластеры более 4 Кбайт. По этой же причине считается, что FAT 16 целесообразнее для дисков с объемом не более 512 Мбайт, а для больших дисков лучше подходит FAT32, которая способна использовать кластеры 4 Кбайт при работе с дисками объемом до 8 Гбайт и только для дисков большего объема начинает использовать 8, 16 и 32 Кбайт. Максимальный размер раздела FAT 16 ограничен 4 Гбайт, такой объем дает 65 536 кластеров по 64 Кбайт каждый, а максимальный размер раздела FAT32 практически не ограничен — 232 кластеров по 32 Кбайт.

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

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

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

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

Файловые системы FAT12 и FAT16 оперировали с именами файлов, состоящими из 12 символов по схеме «8.3». В версии FAT16 операционной системы Windows NT был введен новый тип записи каталога — «длинное имя», что позволяет использовать имена длиной до 255 символов, причем каждый символ длинного имени хранится в двухбайтном формате Unicode. Имя по схеме «8.3», названное теперь коротким (не нужно путать его с простым именем файла, также называемого иногда коротким), по-прежнему хранится в 12-байтовом поле имени файла в записи каталога, а длинное имя помещается порциями по 13 символов в одну или несколько записей, следующих непосредственно за основной записью каталога. Каждый символ в формате Unicode кодируется двумя байтами, поэтому 13 символов занимают 26 байт, а оставшиеся 6 отведены под служебную информацию. Таким образом у файла появляются два имени — короткое, для совместимости со старыми приложениями, не понимающими длинных имен в Unicode, и длинное, удобное в использовании имя. Файловая система FAT32 также поддерживает короткие и длинные имена.

Файловые системы FAT12 и FAT16 получили большое распространение благодаря их применению в операционных системах MS-DOS и Windows 3.x — самых массовых операционных системах первого десятилетия эры персональных компьютеров. По этой причине эти файловые системы поддерживаются сегодня и другими ОС, такими как UNIX, OS/2, Windows NT/2000 и Windows 95/98. Однако из-за постоянно растущих объемов жестких дисков, а также возрастающих требований к надежности, эти файловые системы быстро вытесняются как системой FAT32, впервые появившейся в Windows 95 OSR2, так и файловыми системами других типов.

Физическая организация NTFS

Файловая система NTFS была разработана в качестве основной файловой системы для ОС Windows NT в начале 90-х годов с учетом опыта разработки файловых систем FAT и HPFS (основная файловая система для OS/2), а также других существовавших в то время файловых систем. Основными отличительными свойствами NTFS являются:

• поддержка больших файлов и больших дисков объемом до 2 байт;

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

• высокая скорость операций, в том числе и для больших дисков;

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

• гибкая структура, допускающая развитие за счет добавления новых типов записей и атрибутов файлов с сохранением совместимости с предыдущими версиями ФС;

• устойчивость к отказам дисковых накопителей;

• поддержка длинных символьных имен;

• контроль доступа к каталогам и отдельным файлам.

Структура тома NTFS

В отличие от разделов FAT и s5/ufs все пространство тома NTFS представляет собой либо файл, либо часть файла. Основой структуры тома NTFS является главная таблица файлов (Master File Table, MFT), которая содержит по крайней мере одну запись для каждого файла тома, включая одну запись для самой себя. Каждая запись MFT имеет фиксированную длину, зависящую от объема диска, — 1,2 или 4 Кбайт. Для большинства дисков, используемых сегодня, размер записи MFT равен 2 Кбайт, который мы далее будет считать размером записи по умолчанию.

Все файлы на томе NTFS идентифицируются номером файла, который определяется позицией файла в MFT. Этот способ идентификации файла близок к способу, используемому в файловых системах s5 и ufs, где файл однозначно идентифицируется номером его записи в области индексных дескрипторов.

Весь том NTFS состоит из последовательности кластеров, что отличает эту файловую систему от рассмотренных ранее, где на кластеры делилась только область данных. Порядковый номер кластера в томе NTFS называется логическим номером кластера {Logical Cluster Number, LCN). Файл NTFS также состоит из последовательности кластеров, при этом порядковый номер кластера внутри файла называется виртуальным номером кластера (Virtual Cluster Number, VCN).

Базовая единица распределения дискового пространства для файловой системы NTFS — непрерывная область кластеров, называемая отрезком. В качестве адреса отрезка NTFS использует логический номер его первого кластера, а также количество кластеров в отрезке k, то есть пара (LCN, k). Таким образом, часть файла, помещенная в отрезок и начинающаяся с виртуального кластера VCN, характеризуется адресом, состоящим из трех чисел: (VCN, LCN, k).

Для хранения номера кластера в NTFS используются 64-разрядные указатели, что дает возможность поддерживать тома и файлы размером до 264 кластеров. При размере кластера в 4 Кбайт это позволяет использовать тома и файлы, состоящие из 64 миллиардов килобайт.

Структура тома NTFS показана на рис. 7.19. Загрузочный блок тома NTFS располагается в начале тома, а его копия — в середине тома. Загрузочный блок содержит стандартный блок параметров BIOS, количество блоков в томе, а также начальный логический номер кластера основной копии MFT и зеркальную копию MFT.

Рис. 7.19. Структура тома NTFS

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

Номер записи	Системный файл	Имя файла	Назначение файла
0	Главная таблица файлов	$Mft	Содержит полный список файлов тома NTFS
1	Копия главной таблицы файлов	SMftMirr	Зеркальная копия первых трех записей MFT
2	Файл журнала	SLogFile	Список транзакций, который используется для восстановления файловой системы после сбоев
3	Том	SVolume	Имя тома, версия NTFS и другая информация о томе
4	Таблица определения атрибутов	SAttrDef	Таблица имен, номеров и описаний атрибутов
5	Индекс корневого каталога	$.	Корневой каталог
6	Битовая карта кластеров	SBitmap	Разметка использованных кластеров тома
7	Загрузочный сектор раздела	SBoot	Адрес загрузочного сектора раздела
8	Файл плохих кластеров	SBadClus	Файл, содержащий список всех обнаруженных на томе плохих кластеров
9	Таблица квот	SQuota	Квоты используемого пространства на диске для каждого пользователя
10	Таблица преобразования регистра символов	SUpcase	Используется для преобразования регистра символов для кодировки Unicode
11-15	Зарезервированы для будущего использования

В NTFS файл целиком размещается в записи таблицы MFT, если это позволяет сделать его размер. В том же случае, когда размер файла больше размера записи MFT, в запись помещаются только некоторые атрибуты файла, а остальная часть файла размещается в отдельном отрезке тома (или нескольких отрезках). Часть файла, размещаемая в записи MFT, называется резидентной частью, а остальные части — нерезидентными. Адресная информация об отрезках, содержащих нерезидентные части файла, размещается в атрибутах резидентной части.

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

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

Структура файлов NTFS

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

Каждый атрибут файла NTFS состоит из полей: тип атрибута, длина атрибута, значение атрибута и, возможно, имя атрибута. Тип атрибута, длина и имя образуют заголовок атрибута.

Имеется системный набор атрибутов, определяемых структурой тома NTFS. Системные атрибуты имеют фиксированные имена и коды их типа, а также определенный формат. Могут применяться также атрибуты, определяемые пользователями. Их имена, типы и форматы задаются исключительно пользователем. Атрибуты файлов упорядочены по убыванию кода атрибута, причем атрибут одного и того же типа может повторяться несколько раз. Существуют два способа хранения атрибутов файла — резидентное хранение в записях таблицы MFT и нерезидентное хранение вне ее, во внешних отрезках. Таким образом, резидентная часть файла состоит из резидентных атрибутов, а нерезидентная — из нерезидентных атрибутов. Сортировка может осуществляться только по резидентным атрибутам.

Системный набор включает следующие атрибуты:

Attribute List (список атрибутов) — список атрибутов, из которых состоит файл; содержит ссылки на номер записи MFT, где расположен каждый атрибут; этот редко используемый атрибут нужен только в том случае, если атрибуты файла не умещаются в основной записи и занимают дополнительные записи MFT;

• File Name (имя файла) — этот атрибут содержит длинное имя файла в формате Unicode, а также номер входа в таблице MFT для родительского каталога; если этот файл содержится в нескольких каталогах, то у него будет несколько атрибутов типа File Name; этот атрибут всегда должен быть резидентным;

• MS-DOS Name (имя MS-DOS) — этот атрибут содержит имя файла в формате 8.3;

• Version (версия) — атрибут содержит номер последней версии файла;

• Security Descriptor (дескриптор безопасности) — этот атрибут содержит информацию о защите файла: список прав доступа ACL (права доступа к файлу рассматриваются ниже в разделе «Контроль доступа к файлам») и поле аудита, которое определяет, какого рода операции над этим файлом нужно регистрировать;

• Volume Version (версия тома) — версия тома, используется только в системных файлах тома;

• Volume Name (имя тома) — имя тома;

• Data (данные) — содержит обычные данные файла;

• MFT bitmap (битовая карта MFT) — этот атрибут содержит карту использования блоков на томе;

• Index Root (корень индекса) — корень В-дерева, используемого для поиска файлов в каталоге;

• Index Allocation (размещение индекса) — нерезидентные части индексного списка В-дерева;

• Standard Information (стандартная информация) — этот атрибут хранит всю остальную стандартную информацию о файле, которую трудно связать с каким-либо из других атрибутов файла, например, время создания файла, время обновления и другие.

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

Небольшие файлы (small). Если файл имеет небольшой размер, то он может целиком располагаться внутри одной записи MFT, имеющей, например, размер 2 Кбайт. Небольшие файлы NTFS состоят по крайней мере из следующих атрибутов (рис. 7.20):

• стандартная информация (SI — standard information);

• имя файла (FN — file name);

• данные (Data);

• дескриптор безопасности (SD — security descriptor).

Из-за того что файл может иметь переменное количество атрибутов, а также из-за переменного размера атрибутов нельзя наверняка утверждать, что файл уместится внутри записи. Однако обычно файлы размером менее 1500 байт помещаются внутри записи MFT (размером 2 Кбайт).

Рис. 7.20. Небольшой файл NTFS

Большие файлы (large). Если данные файла не помещаются в одну запись МЕТ, то этот факт отражается в заголовке атрибута Data, который содержит признак того, что этот атрибут является нерезидентным, то есть находится в отрезках вне таблицы MFT. В этом случае атрибут Data содержит адресную информацию (LCN, VCN, k) каждого отрезка данных (рис. 7.21).

Рис. 7.21. Большой файл

Рис. 7.22. Очень большой файл

Сверхбольшие файлы (extremely huge). Для сверхбольших файлов в атрибуте Attribute List можно указать несколько атрибутов, расположенных в дополнительных записях MFT (рис. 7.23). Кроме того, можно использовать двойную косвенную адресацию, когда нерезидентный атрибут будет ссылаться на другие нерезидентные атрибуты, поэтому в NTFS не может быть атрибутов слишком большой для системы длины.

Очень большие файлы (huge). Если файл настолько велик, что его атрибут данных, хранящий адреса нерезидентных отрезков данных, не помещается в одной записи, то этот атрибут помещается в другую запись MFT, а ссылка на такой атрибут помещается в основную запись файла (рис. 7.22). Эта ссылка содержится в атрибуте Attribute List. Сам атрибут данных по-прежнему содержит адреса нерезидентных отрезков данных.

Рис. 7.23. Сверхбольшой файл

Каталоги NTFS

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

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

Небольшие каталоги (small indexes). Если количество файлов в каталоге невелико, то список файлов может быть резидентным в записи в MFT, являющейся каталогом (рис. 7.24). Для резидентного хранения списка используется единственный атрибут — Index Root. Список файлов содержит значения атрибутов файла. По умолчанию — это имя файла, а также номер записи MTF, содержащей начальную запись файла.

Рис. 7.24. Небольшой каталог

Большие каталоги (large indexes). По мере того как каталог растет, список файлов может потребовать нерезидентной формы хранения. Однако начальная часть списка всегда остается резидентной в корневой записи каталога в таблице MFT (рис. 7.25). Имена файлов резидентной части списка файлов являются узлами так называемого В-дерева (двоичного дерева). Остальные части списка файлов размещаются вне MFT. Для их поиска используется специальный атрибут Index Allocation, представляющий собой адреса отрезков, хранящих остальные части списка файлов каталога. Одни части списков являются листьями дерева, а другие являются промежуточными узлами, то есть содержат наряду с именами файлов атрибут Index Allocation, указывающий на списки файлов более низких уровней.

Узлы двоичного дерева делят весь список файлов на несколько групп. Имя каждого файла-узла является именем последнего файла в соответствующей группе. Считается, что имена файлов сравниваются лексикографически, то есть сначала принимаются во внимание коды первых символов двух сравниваемых имен, при этом имя считается меньшим, если код его первого символа имеет меньшее арифметическое значение, при равенстве кодов первых символов сравниваются коды вторых символов имен и т. д. Например, файл f 1 .ехе, являющийся первым узлом двоичного дерева, показанного на рис. 7.25, имеет имя, лексикографически большее имен avia.exe, az.exe,..., emax.exe, образующих первую группу списка имен каталога. Соответственно файл ltr.exe имеет наибольшее имя среди всех имен второй группы, а все файлы с именами, большими ltr.exe, образуют третью и последнюю группу.

Поиск в каталоге уникального имени файла, которым в NTFS является номер основной записи о файле в MFT, по его символьному имени происходит следующим образом. Сначала искомое символьное имя сравнивается с именем первого узла в резидентной части индекса. Если искомое имя меньше, то это означает, что его нужно искать в первой нерезидентной группе, для чего из атрибута Index Allocation извлекается адрес отрезка (VCNj, LCN^ K!), хранящего имена файлов первой группы. Среди имен этой группы поиск осуществляется прямым перебором имен и сравнением до полного совпадения всех символов искомого имени с хранящимся в каталоге именем. При совпадении из каталога извлекается номер основной записи о файле в MFT и остальные характеристики файла берутся уже оттуда.

Рис. 7.25. Большой каталог

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

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

Если одна из групп каталога становится слишком большой, то ее также делят на группы, последние имена каждой новой группы оставляют в исходном нерезидентном атрибуте Index Root, а все остальные имена новых групп переносят в новые нерезидентные атрибуты типа Index Root (на рисунке этот случай не показан). К исходному нерезидентному атрибуту Index Root добавляется атрибут размещения индекса, указывающий на отрезки индекса новых групп. Если теперь при поиске искомого имени в нерезидентной части индекса первого уровня какое-либо сравнение показывает, что искомое имя оказывается меньше, чем одно из хранящихся там имен, то это говорит о том, что в данном атрибуте точного сравнения имени уже быть не может и нужно перейти к подгруппе имен следующего уровня дерева.

Механизм контроля доступа

Каждый пользователь и каждая группа пользователей обычно имеют символьное имя, а также уникальный числовой идентификатор. При выполнении процедуры логического входа в систему пользователь сообщает свое символьное имя и пароль, а операционная система определяет соответствующие числовые идентификаторы пользователя и групп, в которые он входит. Вся идентификационные данные, в том числе имена и идентификаторы пользователей и групп, пароли пользователей, а также сведения о вхождении пользователя в группы хранятся в специальном файле (файл /etc/passwd в UNIX) или специальной базе данных (в Windows NT).

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

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

• создание файла;

• уничтожение файла;

• открытие файла;

• закрытие файла;

• чтение файла;

• запись в файл;

• дополнение файла;

• поиск в файле;

• получение атрибутов файла;

• установка новых значений атрибутов;

• переименование;

• выполнение файла;

• чтение каталога;

• смена владельца;

• изменение прав доступа.

Набор файловых операций ОС может состоять из большого количества элементарных операций, а может включать всего несколько укрупненных операций. Приведенный выше список является примером первого подхода, который позволяет весьма тонко управлять правами доступа пользователей, но создает значительную нагрузку на администратора. Пример укрупненного подхода демонстрируют операционные системы семейства UNIX, в которых существуют всего три операции с файлами и каталогами: читать (read, г), писать (write, w) и выполнить (execute, x). Хотя в UNIX для операций используется всего три названия, в действительности им соответствует гораздо больше операций. Например, содержание операции выполнить зависит от того, к какому объекту она применяется. Если операция выполнить файл интуитивно понятна, то операция выполнить каталог интерпретируется как поиск в каталоге определенной записи. Поэтому администратор UNIX, по сути, располагает большим списком операций, чем это кажется на первый взгляд.

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

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

Рис. 7.28. Матрица прав доступа

Практически во всех операционных системах матрица прав доступа хранится «по частям», то есть для каждого файла или каталога создается так называемый список управления доступом (Access Control List, ACL), в котором описываются права на выполнение операций пользователей и групп пользователей по отношению к этому файлу или каталогу. Список управления доступа является частью характеристик файла или каталога и хранится на диске в соответствующей области, например в индексном дескрипторе inode файловой системы ufs. He все файловые системы поддерживают списки управления доступом, например, его не поддерживает файловая система FAT, так как она разрабатывалась для однопользовательской однопрограммной операционной системы MS-DOS, для которой задача защиты от несанкционированного доступа не актуальна.

Обобщенно формат списка управления доступом можно представить в виде набора идентификаторов пользователей и групп пользователей, в котором для каждого идентификатора указывается набор разрешенных операций над объектом (рис. 7.29). Говорят, что список ACL состоит из элементов управления доступом (Access Control Element, АСЕ), при этом каждый элемент соответствует одному идентификатору. Список ACL с добавленным к нему идентификатором владельца называют характеристиками безопасности.

Рис. 7.29. Проверка прав доступа

В приведенном на рисунке примере процесс, который выступает от имени пользователя с идентификатором 3 и групп с идентификаторами 14, 52 и 72, пытается выполнить операцию записи (W) в файл. Файлом владеет пользователь с идентификатором 17. Операционная система, получив запрос на запись, находит характеристики безопасности файла (на диске или в буферной системной области) и последовательно сравнивает все идентификаторы процесса с идентификатором владельца файла и идентификаторами пользователей и групп в элементах АСЕ. В данном примере один из идентификаторов группы, от имени которой выступает процесс, а именно 52, совпадает с идентификатором одного из элементов АСЕ. Так как пользователю с идентификатором 52 разрешена операция чтения (признак W имеется в наборе операций этого элемента), то ОС разрешает процессу выполнение операции.

Описанная обобщенная схема хранения информации о правах доступа и процедуры проверки имеет в каждой операционной системе свои особенности, которые рассматриваются далее на примере операционных систем UNIX и Windows NT.

Организация контроля доступа в ОС UNIX

В ОС UNIX права доступа к файлу или каталогу определяются для трех субъектов:

• владельца файла (идентификатор User ID, UID);

• членов группы, к которой принадлежит владелец (Group ID, GID);

• всех остальных пользователей системы.

С учетом того что в UNIX определены всего три операции над файлами и каталогами (чтение, запись, выполнение), характеристики безопасности файла включают девять признаков, задающих возможность выполнения каждой из трех операций для каждого из трех субъектов доступа. Например, если владелец файла разрешил себе выполнение всех трех операций, для членов группы — чтение и выполнение, а для всех остальных пользователей — только выполнение, то девять характеристик безопасности файла выглядят следующим образом:

rwx r-х r--

Здесь г, w и х обозначают операции чтения, записи и выполнения соответственно. Именно в таком виде выводит информацию о правах доступа к файлам команда просмотра содержимого каталога 1 s. Суперпользователю UNIX все виды доступа позволены всегда, поэтому его идентификатор (он имеет значение 0) не фигурирует в списках управления доступом.

С каждым процессом UNIX связаны два идентификатора: пользователя, от имени которого был создан этот процесс, и группы, к которой принадлежит данный пользователь. Эти идентификаторы носят название реальных идентификаторов пользователя: Real User ID, RUID и реальных идентификаторов группы: Real Group ID, RGID. Однако при проверке прав доступа к файлу используются не эти идентификаторы, а так называемые эффективные идентификаторы пользователя: Effective User ID, EUID и эффективные идентификаторы группы: Effective Group ID, EGID (рис. 7.30).

Рис. 7.30. Проверка прав доступа в UNIX

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

Случаи, когда процесс выполняет системный вызов ехес запуска приложения, хранящегося в некотором файле, в UNIX связаны со сменой процессом исполняемого кода. В рамках данного процесса начинает выполняться новый код, и если в характеристиках безопасности этого файла указаны признаки разрешения смены идентификаторов пользователя и группы, то происходит смена эффективных идентификаторов процесса. Файл имеет два признака разрешения смены идентификатора — Set User ID on execution (SUID) и Set Group ID on execution (SGID), которые разрешают смену идентификаторов пользователя и группы при выполнении данного файла.

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

Первоначально процесс А имел эффективные идентификаторы пользователя и группы (12 и 23 соответственно), совпадающие с реальными. На каком-то этапе работы процесс запросил выполнение приложения из файла b.ехе. Процесс может выполнить файл b.ехе, хотя его эффективные идентификаторы не совпадают с идентификатором владельца и группы файла, так как выполнение разрешено всем пользователям.

Рис. 7.31. Смена эффективных идентификаторов процесса

Файл Ь.ехе имеет установленные признаки смены идентификаторов SUID и SGID, поэтому одновременно со сменой кода процесс меняет и значения эффективных идентификаторов (35 и 47). Вследствие этого при последующей попытке записать данные в файл f 1 .doc процессу А это удается, так как его новый эффективный идентификатор группы совпадает с идентификатором группы файла f1.doc. Без смены идентификаторов эта операция для процесса А была бы запрещена.

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

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

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

Организация контроля доступа в ОС Windows NT

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

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

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

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

Для системы безопасности Windows NT характерно наличие большого количества различных предопределенных (встроенных) субъектов доступа — как отдельных пользователей, так и групп. Так, в системе всегда имеются такие пользователи, как Administrator, System и Guest, а также группы Users, Administrators, Account Operators, Server Operators, Everyone и другие. Смысл этих встроенных пользователей и групп состоит в том, что они наделены некоторыми правами, облегчая администратору работу по созданию эффективной системы разграничения доступа. При добавлении нового пользователя администратору остается только решить, к какой группе или группам отнести этого пользователя. Конечно, администратор может создавать новые группы, а также добавлять права к встроенным группам для реализации собственной политики безопасности, но во многих случаях встроенных групп оказывается вполне достаточно.

Windows NT поддерживает три класса операций доступа, которые отличаются типом субъектов и объектов, участвующих в этих операциях.

• Разрешения (permissions) — это множество операций, которые могут быть определены для субъектов всех типов по отношению к объектам любого типа: файлам, каталогам, принтерам, секциям памяти и т. д. Разрешения по своему назначению соответствуют правам доступа к файлам и каталогам в ОС UNIX.

• Права (user rights) — определяются для субъектов типа группа на выполнение некоторых системных операций: установку системного времени, архивирование файлов, выключение компьютера и т. п. В этих операциях участвует особый объект доступа — операционная система в целом. В основном именно права, а не разрешения отличают одну встроенную группу пользователей от другой. Некоторые права у встроенной группы являются также встроенными — их у данной группы нельзя удалить. Остальные права встроенной группы можно удалять (или добавлять из общего списка прав).

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

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

Проверка разрешений доступа процесса к объекту производится в Windows NT в основном в соответствии с общей схемой доступа, представленной на рис. 7.29.

При входе пользователя в систему для него создается так называемый токен доступа (access token), включающий идентификатор пользователя и идентификаторы всех групп, в которые входит пользователь. В токене также имеются: список управления доступом (ACL) по умолчанию, который состоит из разрешений и применяется к создаваемым процессом объектам; список прав пользователя на выполнение системных действий.

Все объекты, включая файлы, потоки, события, даже токены доступа, когда они создаются, снабжаются дескриптором безопасности. Дескриптор безопасности содержит список управления доступом — ACL. Владелец объекта, обычно пользователь, который его создал, обладает правом избирательного управления доступом к объекту и может изменять ACL объекта, чтобы позволить или не позволить другим осуществлять доступ к объекту. Встроенный администратор Windows NT в отличие от суперпользователя UNIX может не иметь некоторых разрешений на доступ к объекту. Для реализации этой возможности идентификаторы администратора и группы администраторов могут входить в ACL, как и идентификаторы рядовых пользователей. Однако администратор все же имеет возможность выполнить любые операции с любыми объектами, так как он всегда может стать владельцем объекта, а затем уже как владелец получить полный набор разрешений. Однако вернуть владение предыдущему владельцу объекта администратор не может, поэтому пользователь всегда может узнать о том, что с его файлом или принтером работал администратор.

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

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

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

В Windows NT однозначно определены правила, по которым вновь создаваемому объекту назначается список ACL. Если вызывающий код во время создания объекта явно задает все права доступа к вновь создаваемому объекту, то система безопасности приписывает этот ACL объекту.

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

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

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

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

Разрешения в Windows NT бывают индивидуальные и стандартные. Индивидуальные разрешения относятся к элементарным операциям над каталогами и файлами, а стандартные разрешения являются объединением нескольких индивидуальных разрешений.

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

Разрешение	Для каталога	Для файла
Read (R)	Чтение имен файлов и каталогов, входящих в данный каталог, а также атрибутов и владельца каталога	Чтение данных, атрибутов, - имени владельца и разрешений файла
Write (W)	Добавление файлов и каталогов, изменение атрибутов каталога, чтение владельца и разрешений каталога	Чтение владельца и разрешений файла, изменение атрибутов файла, изменение и добавление данных файла
Execute (X)	Чтение атрибутов каталога, выполнение изменений в каталогах, входящих в данный каталог, чтение имени владельца и разрешений каталога	Чтение атрибутов файла, имени владельца и разрешений. Выполнение файла, если он хранит код программы
Delete (D)	Удаление каталога	Удаление файла
Change Permission (P)	Изменение разрешений каталога	Изменение разрешений файла
Take Ownership (O)	Стать владельцем каталога	Стать владельцем файла

Для файлов в Windows NT определено четыре стандартных разрешения: No Access, Read, Change и Full Control, которые объединяют индивидуальные разрешения, перечисленные в следующей таблице.

Стандартное разрешение	Индивидуальные разрешения
No Access	Ни одного
Read	RX
Change	RWXD
Full Control	Все

Разрешение Full Control отличается от Change тем, что дает право на изменение разрешений (Change Permission) и вступление во владение файлом (Take Ownership).

Для каталогов в Windows NT определено семь стандартных разрешений: No Access, List, Read, Add, Add&Read, Change и Full Control. В следующей таблице показано соответствие стандартных разрешений индивидуальным разрешениям для каталогов, а также то, каким образом эти стандартные разрешения преобразуются в индивидуальные разрешения для файлов, входящих в каталог в том случае, если файлы наследуют разрешения каталога.

Стандартные разрешения	Индивидуальные разрешения для каталога	Индивидуальные разрешения для файлов каталога при наследовании
No Access	Ни одного	Ни одного
List	RX	Не определены
Read	RX	RX
Add	WX	Не определены
Add & Read	RWX	RX
Change	RWXD	RWXD
Full Control	Все	Все

При создании файла он наследует разрешения от каталога указанным способом только в том случае, если у каталога установлен признак наследования его разрешений. Стандартная оболочка Windows NT — Windows Explorer — не позволяет установить такой признак для каждого разрешения отдельно (то есть задать маску наследования), управляя наследованием по принципу «все или ничего».

Существует ряд правил, которые определяют действие разрешений.

• Пользователи не могут работать с каталогом или файлом, если они не имеют явного разрешения на это или же они не относятся к группе, которая имеет соответствующее разрешение.

• Разрешения имеют накопительный эффект, за исключением разрешения No Access, которое отменяет все остальные имеющиеся разрешения. Например, если группа Engineering имеет разрешение Change для какого-то файла, а группа Finance имеет для этого файла только разрешение Read и Петров является членом обеих групп, то у Петрова будет разрешение Change. Однако если разрешение для группы Finance изменится на No Access, то Петров не сможет использовать этот файл, несмотря на то что он член группы, которая имеет доступ к файлу.

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

Встроенные группы пользователей и их права

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

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

Права	Administrators	Server Operators	Account Operators	Print Operators	Backup Operators	Everyone	Users	Guests
Log on locally (локальный логический вход)	Есть	Есть	Есть	Есть	Есть	Нет	Нет	Нет
Access this computer from network (доступ к данному компьютеру через сеть)	Есть	Нет	Нет	Нет	Нет	Нет	Нет	Нет
Take ownership of files (установление прав собственности на файлы)	Есть	Нет	Нет	Нет	Нет	Нет	Нет	Нет
Manage auditing and security log (управление аудитом и учетом событий, связанных с безопасностью)	Есть	Нет	Нет	Нет	Нет	Есть	Нет	Есть
Change the system time (изменение системного времени)	Есть	Есть	Нет	Нет	Нет	Нет	Нет	Есть
Shutdown the system (останов системы)	Есть	Есть	Нет	Нет	Есть	Нет	Нет	Нет
Force shutdown from remote system (инициирование останова с удаленной системы)	Есть	Есть	Нет	Нет	Нет	Нет	Нет	Нет
Backup files and directories (резервное копирование файлов и каталогов)	Есть	Есть	Есть	Есть	Есть	Нет	Нет	Нет
Restore files and directories (восстановление файлов и каталогов со стримера)	Есть	Есть	Нет	Нет	Есть	Нет	Нет	Нет
Load and unload device drivers (загрузка и выгрузка драйверов устройств)	Есть	Нет	Нет	Нет	Нет	Нет	Нет	Нет
Add workstation to domain (добавление рабочих станций к домену)	Есть	Нет	Нет	Нет	Нет	Нет	Нет	Нет

В следующей таблице представлены встроенные права встроенных групп.

Встроенные права	Administrators	Server Operators	Account Operators	Print Operators	Backup Operators	Everyone	Users	Guests
Create and manage user accounts (создание и управление пользовательской учетной информацией)	Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет
Create and manage global groups (создание и управление глобальными группами)	Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет
Assign user rights (назначение прав для пользователей)	Нет	Нет	Нет	Нет	Нет	Есть	Нет	Нет
Manage auditing of system events (управление аудитом системных событий)	Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет
Lock the server (блокирование сервера)	Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет
Override the lock of the server (преодоление блокировки сервера)	Есть	Есть	Есть	Нет	Нет	Нет	Нет	Нет
Format server's hard disk (форматирование жесткого диска сервера)	Нет	Нет	Нет	Нет	Нет	Есть	Есть	Есть
Create common groups (создание общих групп)	Есть	Есть	Есть	Есть	Есть	Есть	Есть	Есть
Keep local profile (хранение локального профиля)
Share and stop sharing directories (разделение и прекращение разделения каталогов)
Share and stop sharing printers (разделение и прекращение разделения принтеров)

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

23. Обзор семейства операционных систем Microsoft Windows.

Базовая архитектура Windows 2000, программные компоненты системы.

Структура ядра системы, менеджер конфигураций,

инсталлируемые файловые системы.

Компоненты системы Windows 2000 режима пользователя.

Реализация Win API, подсистемы User, GDI, Kernel.

Microsoft Windows - семейство проприетарных операционных систем корпорации Майкрософт (Microsoft), ориентированных на применение графического интерфейса при управлении. Изначально были всего лишь графическими надстройками для MS-DOS.

В настоящее время под управлением операционных систем семейства Windows, по данным ресурса Netmarketshare (Net Applications) на 2009 год, работает около 89 % персональных компьютеров[1].

Операционные системы Windows работают на платформах x86, x86-64, IA-64, ARM. Существовали также версии для DEC Alpha, MIPS, PowerPC и SPARC[2].

Версии Microsoft Windows

Обычно все версии Windows делят на несколько «групп».

Графические интерфейсы и расширения для DOS

Эти версии Windows не были полноценными операционными системами, а являлись надстройками к операционной системе MS-DOS и были по сути многофункциональным расширением, добавляя поддержку новых режимов работы процессора, поддержку многозадачности, обеспечивая стандартизацию интерфейсов аппаратного обеспечения и единообразие для пользовательских интерфейсов программ. Предоставляли встроенные средства (GDI и USER, первые версии Windows вообще состояли из трех модулей — KERNEL, GDI и USER, первый из них предоставлял вызовы управления памятью, запуском EXE файлов и загрузкой DLL файлов, второй — графику, третий — окна) для создания графического интерфейса пользователя. Они работали с процессорами начиная с Intel 8086.

• Windows 1.0 (1985)

• Windows 2.0 (1987)

• Windows 2.1 (Windows 386) (1987) — в системе появилась возможность запуска DOS-приложений в графических окнах, причём каждому приложению предоставлялись полные 640 Кб памяти. Полная поддержка процессора 80286. Появилась поддержка процессоров 80386.

• Windows 3.0 (1990) — улучшена поддержка процессоров 80386 и защищённого режима.

• Windows 3.1 (1992) — серьёзно переработанная Windows 3.0; устранены UAE (Unrecoverable Application Errors — фатальные ошибки прикладных программ), добавлен механизм OLE, печать в режиме WYSIWYG («что видите, то и получите»), шрифты TrueType, изменён Проводник (диспетчер файлов), добавлены мультимедийные функции.

• Windows для рабочих групп (Windows for Workgroups) 3.1/3.11 — первая версия ОС семейства с поддержкой локальных сетей. В WFWG 3.11 также испытывались отдельные усовершенствования ядра, применённые позднее в Windows 95.

Семейство Windows 9x

Включает в себя Windows 95, Windows 98 и Windows Me.

Windows 95 была выпущена в 1995 году. Её отличительными особенностями являются новый пользовательский интерфейс, поддержка длинных имён файлов, автоматическое определение и конфигурация периферийных устройств Plug and Play, способность исполнять 32-битные приложения и наличие поддержки TCP/IP прямо в системе. Windows 95 использует вытесняющую многозадачность и выполняет каждое 32-битное приложение в своём адресном пространстве.

Операционные системы этого семейства не являлись безопасными многопользовательскими системами как Windows NT, поскольку из соображений совместимости вся подсистема пользовательского интерфейса и графики оставалась 16-битной и мало отличалась от той, что в Windows 3.x. Так как этот код не был thread-safe, все вызовы в подсистему оборачивались в мьютекс по имени Win16Lock, который кроме того еще и находился всегда в захваченном состоянии во время исполнения 16битного приложения. Таким образом, «повисание» 16-битного приложения немедленно блокировало всю ОС.

Программный интерфейс был подмножеством Win32 API поддерживаемым Windows NT, но имел поддержку юникода в очень ограниченном объёме[9]. Также в нём не было должного обеспечения безопасности (списков доступа к объектам и понятия «администратор»).

В составе Windows 95 присутствовал MS-DOS 7.0, однако его роль сводилась к обеспечению процесса загрузки и исполнению 16-битных DOS приложений. Исследователи заметили, что ядро Windows 95 — VMM — обращается к DOS под собой, но таких обращений довольно мало, главнейшая функция ядра DOS — файловая система FAT — не использовалась. В целом же интерфейс между VMM и нижележащей DOS никогда не публиковался, и DOS была замечена (тем же Эндрю Шульманом) в наличии недокументированных вызовов только для поддержки VMM.

Семейство Windows NT

Операционные системы этого семейства в настоящее время работают на процессорах с архитектурами x86, x64, и Itanium,ARM. Ранние версии (до 4.0 включительно) также поддерживали некоторые RISC-процессоры: Alpha, MIPS, и Power PC. Все операционные системы этого семейства являются полностью 32- или 64- битными операционными системами, и не нуждаются в MS-DOS даже для загрузки.

Только в этом семействе представлены операционные системы для серверов. До версии Windows 2000 включительно они выпускались под тем же названием, что и аналогичная версия для рабочих станций, но с добавлением суффикса, например «Windows NT 4.0 Server» и «Windows 2000 Datacenter Server». Начиная с Windows Server 2003, серверные операционные системы называются по-другому.

• Windows NT 3.1 (1993)

• Windows NT 3.5 (1994)

• Windows NT 3.51 (1995)

• Windows NT 4.0 (1996)

• Windows 2000 (2000) — Windows NT 5.0

• Windows XP (2001) — Windows NT 5.1

• Windows XP 64-bit Edition (2006) — Windows NT 5.2

• Windows Server 2003 (2003) — Windows NT 5.2

• Windows Vista (2006) — Windows NT 6.0

• Windows Home Server (2007) — Windows NT 5.2

• Windows Server 2008 (2008) — Windows NT 6.0

• Windows Small Business Server (2008) — Windows NT 6.0

• Windows 7 — Windows NT 6.1 (2009)

• Windows Server 2008 R2 — Windows NT 6.1 (2009)

• Windows Home Server 2011 — Windows NT 6.1 (2011)

• Windows 8 — Windows NT 6.2 (2012)

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

Семейство Windows NT относится к операционным системам с вытесняющей многозадачностью. Разделение процессорного времени между потоками происходит по принципу «карусели». Ядро операционной системы выделяет квант времени (в Windows 2000 квант равен примерно 20 мс) каждому из потоков по очереди при условии, что все потоки имеют одинаковый приоритет. Поток может отказаться от выделенного ему кванта времени. В этом случае система перехватывает у него управление (даже если выделенный квант времени не закончен) и передаёт управление другому потоку. При передаче управления другому потоку система сохраняет состояние всех регистров процессора в особой структуре в оперативной памяти. Эта структура называется контекстом потока. Сохранение контекста потока достаточно для последующего возобновления его работы.

Семейство ОС Windows Mobile для карманных компьютеров

Это семейство операционных систем реального времени было специально разработано для встраиваемых систем. Поддерживаются процессоры ARM, MIPS, SuperH и x86. В отличие от остальных операционных систем Windows, операционные системы этого семейства продаются только в составе готовых устройств, таких как смартфоны, карманные компьютеры, GPS навигаторы, MP3 проигрыватели, и другие.

В настоящее время под термином «Windows CE» понимают только ядро операционной системы. Например Windows Mobile 5.0 включает в себя ядро Windows CE 5.0, хотя в некоторых устройствах ядро Windows CE используется и без Windows Mobile.

• Windows CE

• Windows Mobile

Семейство встраиваемых ОС Windows Embedded

Windows Embedded — это семейство операционных систем реального времени, было специально разработано для применения в различных встраиваемых системах. Ядро системы имеет общее с семейством ОС Windows CE и поддерживает процессоры ARM, MIPS, SuperH и x86. Windows Embedded включает дополнительные функции по встраиванию, среди которых фильтр защиты от записи (EWF и FBWF), загрузка с флеш-памяти, CD-ROM, сети, использование собственной оболочки системы и т. п.

В отличие от операционных систем Windows, операционные системы этого семейства продаются только в составе готовых устройств, таких как: банкоматы, медицинские приборы, навигационное оборудование, «тонкие» клиенты, VoIP-терминалы, медиапроигрыватели, цифровые рамки (альбомы), кассовые терминалы, платёжные терминалы, роботы, игровые автоматы, музыкальные автоматы, и другие.

В настоящее время выпускаются следующие варианты ОС Windows Embedded:

• Windows Embedded CE,

• Windows Embedded Standard,

• Windows Embedded POSReady,

• Windows Embedded Enterprise,

• Windows Embedded NavReady,

• Windows Embedded Server.

Microsoft Windows N

Microsoft Windows N — версии Microsoft Windows, из которых корпорацией Microsoft были удалены компоненты, не совместимые с законодательством стран Европейского союза.

Структура Windows 2000/XP не отличается оригинальностью: ядро системы (исполняется на максимально приоритетном уровне процессора) и пользовательские подсистемы (исполняются на минимально приоритетном уровне).

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

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

Ядро Windows 2000/XP состоит из нескольких системных компонентов, каждый из которых отвечает за определенный набор задач. Основные компоненты ядра:

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

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

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

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

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

Наконец, особое по значению и важности место в ядре системы занимает модуль графического интерфейса - Win32k.sys. Фактически - это часть подсистемы Win32, отвечающая за прорисовку и управление графическим интерфейсом. Этот модуль расположен в ядре специально для того, чтобы существенно повысить производительность графических операций ввода/вывода. Однако размещение столь критической части в ядре накладывает чрезвычайно строгие требования к корректности его исполнения. Фактически, ошибка в коде Win32k.sys приведет к краху системы. Разработчики Windows уделяют огромное внимание этому модулю, и именно он наиболее тщательно протестирован. Опыт эксплуатации систем Windows показывает, что код Win32k.sys работает абсолютно корректно и не содержит фатальных ошибок. Однако некорректный драйвер видеосистемы может все испортить.

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

Компоненты пользовательского режима

Подсистема пользовательского интерфейса в Windows NT реализует оконный интерфейс, подобный интерфейсу предыдущих версий Windows. Двумя типами объектов этой подсистемы, отсутствовавшими в 16-битных версиях Windows и в Windows 9x, являются оконные станции и рабочие столы. Оконная станция соответствует одному сеансу пользователя Windows NT — например, при подключении через службу удалённого рабочего стола создаётся новая оконная станция. Каждый запущенный процесс принадлежит одной из оконных станций; службы, кроме помеченных как способные взаимодействовать с рабочим столом, запускаются в отдельных, невидимых оконных станциях.

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

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

Win32 API

Чаще всего прикладными программами для Windows NT используется Win32 API — интерфейс, созданный на основе API ОС Windows 3.1, и позволяющий перекомпилировать существующие программы для 16-битных версий Windows с минимальными изменениями исходного кода. Совместимость Win32 API и 16-битного Windows API настолько велика, что 32-битные и 16-битные приложения могут свободно обмениваться сообщениями, работать с окнами друг друга и т. д. Кроме поддержки функций существовавшего Windows API, в Win32 API был также добавлен ряд новых возможностей, в том числе поддержка консольных программ, многопоточности, и объектов синхронизации, таких как мьютексы и семафоры. Документация на Win32 API входит в состав Microsoft Platform SDK (англ.) и доступна на веб-сайте.[5]

Библиотеки поддержки Win32 API в основном названы так же, как системные библиотеки Windows 3.x, с добавлением суффикса 32: это библиотеки kernel32, advapi32, gdi32, user32, comctl32, comdlg32, shell32 и ряд других. Функции Win32 API могут либо самостоятельно реализовывать требуемую функциональность в пользовательском режиме, либо вызывать описанные выше функции Native API, либо обращаться к подсистеме csrss посредством механизма LPC (англ.), либо осуществлять системный вызов в библиотеку win32k, реализующую необходимую для Win32 API поддержку в режиме ядра. Четыре перечисленных варианта могут также комбинироваться в любом сочетании: например, функция Win32 API WriteFile обращается к функции Native API NtWriteFile для записи в дисковый файл, и вызывает соответствующую функцию csrss для вывода в консоль.

Функции библиотек подсистемы окружения Win32 необходимо разделить на две группы. К первой относятся функции, не требующие перехода в режим ядра, т. е. полностью реализованные в соответствующей DLL (GetCurrentProcess). Вторая группа функций - функции, требующие вызова к Ntdll.dll и как следствие переключения в режим ядра (WriteFile).

В режиме ядра также работают USER и GDI (подсистемы, реализующие GUI-интерфейс). Но в отличие от библиотек Kernel32.dll и Advapi32.dll, библиотеки User32.dll и Gdi32.dll транслируют свои вызовы в драйвер режима ядра Win32k.sys, который также является частью подсистемы Win32.

Исполнительная система и ядро

Ntdll.dll является всего лищь DLL-библиотекой пользовательского режима, для обработки API в режиме ядра она обращается к компонентам операционной системы. В Windows 2000 следует различать исполнительную систему (executive), содержащую базовые сервисы операционной системы и ядро (kernel), содержащего низкоуровневые сервисы операционной системы. Если представлять в виде иерархии, то Executive находится выше ядра, т. к. для реализации той или иной API ей требуется обращения к ядру. Например, планирование потоков происходит в диспетчере потоков в Executive, но сама диспетчеризация (переключение контекста) в ядре. Исполнительная система Executive образует верхний уровень Ntoskrnl.exe, а ядро - нижний. Executive состоит из диспетчеров, таких как диспетчер процессов, потоков, ввода-вывода и др.

Диспетчер системных сервисов

За направление на обработку соответствующему диспетчеру соответствующего системного сервиса отвечает диспетчер системных сервисов - функция KiSystemService в Ntoskrnl.exe. Она осуществляет диспетчеризацию или обработку системного сервиса, используя таблицу диспетчеризации системных сервисов. Вызов (активация) диспетчера системных сервисов происходит в результате программного прерывания int 0x2e (на процессорах х86), эта инструкция располагается в каждом сервисе в Ntdll.dll. Следующая схема иллюстрирует обработку системного сервиса.

KiSystemService принимает номер системного сервиса от Ntdll.dll, находит соответствующий элемент в таблице диспетчеризации системных сервисов и передает системный сервис на обработку исполнительной системе. Ntdll.dll передает в регистре EAX номер системного сервиса, регистр EBX указывает на параметры, передаваемые системному сервису. Затем следует инструкция int 0x2e и по таблице диспетчеризации прерываний, управление передается диспетчеру системных сервисов.

Вызываемые интерфейсы ядра

Как уже было указано, соответствующие библиотеки транслируют API-вызовы в вызовы к Ntdll.dll для переключения в режим ядра. Вызываемые функции Ntdll.dll, называются интерфейсами диспетчера системных сервисов или вызываемыми интерфейсами ядра. Microsoft некоим образом не документирует эти функции, а если и можно встретить в Platform SDK какую-то функцию, экспортируемую из Ntdll.dll, то будет указано, что лучше использовать соответствующие функции Win32 API и не лезть в библиотеку системной поддержки.

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

//Определяем таким образом для Windows XP #define _WIN32_WINNT 0x0501 #include #include #include #define STATUS_SUCCESS (NTSTATUS)0x00000000L void main() { SYSTEM_BASIC_INFORMATION sysinfo; ULONG ReturnLength; NTSTATUS (WINAPI *pNtQuerySystemInformation)(SYSTEM_INFORMATION_CLASS, PVOID,ULONG,PULONG); HMODULE hModule=LoadLibrary("Ntdll.dll"); pNtQuerySystemInformation= (NTSTATUS (WINAPI*)(SYSTEM_INFORMATION_CLASS,PVOID,ULONG,PULONG)) GetProcAddress(hModule,"NtQuerySystemInformation"); if(pNtQuerySystemInformation==NULL) abort(); if(((pNtQuerySystemInformation)(SystemBasicInformation,&sysinfo, sizeof(sysinfo),&ReturnLength))!=STATUS_SUCCESS) abort(); printf("Number of processors: %d\n",sysinfo.NumberOfProcessors); }

Здесь в качестве примера вызывается внутренний сервис NtQuerySystemInformation в Ntdll.dll. Обратите внимание, что Ntdll.dll не проецируется на виртуальное адресное пространство процесса при вызове LoadLibrary, т. к. она проецируется на начальном этапе запуска процесса. Здесь получается лишь ее базовый адрес в виртуальном адресном пространстве процесса.

Обратите особое внимание на файл winternl.h, в котором объявлены многие недокументированные структуры и функции. Наконец-то Microsoft приоткрыла завесу тайны над внутренними сервисами, экспортируемыми Ntdll.dll.

Этот заголовочный файл стал настоящей находкой для системных программистов, т. к. он содержит объявления многих недокументированных сервисов, экспортируемых из Ntdll.dll. Остается только догадываться, почему Microsoft решилась объявить эти функции, хотя они до сих пор относятся к разряду не документированных. К их числу относят: NtCreateFile, NtOpenFile, NtWaitForSingleObject. Например, прототип всем известного внутреннего сервиса NtCreateFile выглядит следующим образом.

NTSTATUS NtCreateFile( PHANDLE FileHandle, ACCESS_MASK DesiredAccess,

POBJECT_ATTRIBUTES ObjectAttributes, PIO_STATUS_BLOCK IoStatusBlock,

PLARGE_INTEGER AllocationSize, ULONG FileAttributes, ULONG ShareAccess, ULONG CreateDisposition, ULONG CreateOptions, PVOID EaBuffer, ULONG EaLength);

Мало того, в Platform SDK Windows Server 2003 можно встретить описание этих недокументированных функций. Последнюю версию можно скачать с сайта Microsoft.

Функции, экспортируемые Ntdll.dll

Просмотреть вызываемые интерфейсы ядра, можно, используя программу dumpbin с ключом /EXPORTS. Она отобразит все экспортируемые Ntdll.dll функции. Как окажется, Ntdll.dll экспортирует множество разнообразных функций, в том числе, такие функции, как strcmp, strcpy для оперирования ANSI-строками и wcscmp, wcscpy для Unicode-строк.

Большинство функций Ntdll.dll начинаются со следующих префиксов. Сс Диспетчер кэша

• Cm Диспетчер конфигурации

• Ex Функции поддержки Executive

• FsRtl Функции библиотеки периода выполения драйвера файловой системы

• Hal Функции HAL

• Функции диспетчера ввода-вывода

• Ke Функции ядра

• Lpc Механизм Lpc

• Lsa Локальная аутентификация

• Mm Функции диспетчера памяти

• Nt Системные сервисы

• Ob Функии диспетчера объектов

• P- Функции диспетчера электропитания

• Pp Функции диспетчера Plug and Play

• Ps Функции поддержки процессов

• Rtl Функции библиотеки периода выполнения

• Se Функции защиты

• Wmi WMI

• Zw Точка входа для системных сервисов (аналогичная префиксу Nt)

GDI (Graphics Device Interface, Graphical Device Interface) — один из трёх основных компонентов или «подсистем», вместе с ядром и Windows API составляющих пользовательский интерфейс (оконный менеджер GDI) Microsoft Windows.

GDI — это интерфейс Windows для представления графических объектов и передачи их на устройства отображения, такие как мониторы и принтеры.

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

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

Простые игры, которые не требуют быстрой графики, могут использовать GDI. Однако GDI не обеспечивает качественной анимации, поскольку в нём нет возможности синхронизации с кадровым буфером. Также, в GDI нет растеризации для отрисовки 3D-графики. Современные игры используют DirectX или OpenGL, что даёт программистам доступ к большему количеству аппаратных возможностей.

Для определения атрибутов текста и изображения, которые выводятся на экран или принтер, используется программный объект под названием «контекст устройства» (Device Context, DC). DC, как и большинство объектов GDI, инкапсулирует подробности реализации и данные в себе и к ним нельзя получить прямой доступ.

Для любого рисования нужен объект HDC (хэндл DC). При выводе на принтер HDC получается вызовом CreateDC, и на нем зовутся специальные функции для перехода на новую страницу печатаемого документа. При выводе на экран также можно использовать CreateDC, но это приведет к рисованию поверх всех окон вне их границ, потому обычно для рисования на экране используются вызовы GetDC и BeginPaint, принадлежащие уже не GDI, а USER, и возвращающие контекст, ссылающийся на регион отсечения окна.

Функционал:

• вывод одними и теми же вызовами на экран, принтер, «экран в памяти» (доступный приложению по указателю и созданный им bitmap в памяти, также возможно выделение bitmapов в памяти видеокарты — CreateCompatibleBitmap — и рисование на них, такие битовые карты не доступны по указателю, но дальнейшая перерисовка с них на физический экран происходит очень быстро без нагрузки процессора и шины, и особенно быстро в случае Remote Desktop).

• вывод в метафайл — запоминание последовательности команд рисования в файле, можно проиграть заново, векторный графический файл .wmf есть именно этот метафайл с небольшим дополнительным заголовком в начале.

• вывод текста различными шрифтами, в т. ч. TrueType и OpenType, а также шрифтами, вшитыми в принтер (при изображении документа на экране используется ближайший похожий программно реализованный шрифт). Буквы всегда заливаются одним цветом («текущий цвет»), промежутки между ними либо остаются прозрачными, либо же заливаются другим цветом («текущий цвет фона»). Не поддерживается расположение букв по кривой.

• богатый набор операций с bitmapами, включая масштабирование, автоматическое преобразование из стандартных форматов в текущий формат экрана без усилий со стороны программиста (StretchDIBits), рисование на bitmapах нескольких стандартных форматов, находящихся в памяти, и огромное количество логических операций комбинирования цветов 2 bitmapов — уже имеющегося на устройстве назначения и вновь рисуемого.

• богатый набор операций векторной графики (примерно тот же, что в PostScript, но используется другой вид сплайнов). Проводимая линия имеет атрибуты — толщину, рисунок пунктира и цвет (собраны вместе в т. н. объекте PEN) и способ сглаживания углов многоугольников. Заливка может быть одноцветной, одной из стандартных штриховок или же bitmapом 8 на 8 (эти атрибуты собраны в «объекте BRUSH»). В Windows NT также появились сплайны Безье.

• все цвета в вызовах — всегда в RGB, независимо от системы цветов текущего устройства. Исключение — отдельные пикселы внутри bitmapов, которые могут быть и в виде, определенном устройством.

• поддержка регионов отсечения и всех основных логических операций над ними. Координаты в них — 16-битные целые (что ограничивало размер экрана Windows, даже довольно поздних версий, до 32K пикселов).

• поддержка матрицы поворотов/растяжений — World Transform, не поддерживается для регионов отсечения, только для векторной графики.

В Windows 9x и более ранних реализована в 16-битной GDI.DLL, которая в свою очередь подгружает выполненный в виде DLL драйвер видеокарты. Драйвер видеокарты первоначально и был обязан реализовать вообще все рисование, в т. ч. рисование на bitmapах в памяти в формате экрана. Позже появилась DIBENG.DLL, в которой было реализовано рисование на bitmapах стандартных форматов, драйвер был обязан пропускать в нее все вызовы, кроме тех, для которых он задействовал аппаратный ускоритель видеокарты.

Драйвер принтера подгружался таким же образом и имел тот же интерфейс «сверху», но «снизу» он вместо рисования в памяти/на аппаратуре генерировал последовательности команд принтера и отсылал их в объект Job. Эти команды как правило были либо бинарные и не читаемые человеком, либо PostScript.

В Windows NT GDI была полностью переписана с нуля заново, причем на Си++ (по слухам, у Microsoft тогда не было компилятора этого языка и они использовали cfront). API для приложений не изменился (кроме добавления кривых Безье), для драйверов — обертки на языке Си вокруг реализованных на Си++ внутренностей (вроде BRUSHOBJ_pvGetRbrush).

Сама GDI была размещена сначала в WINSRV.DLL в процессе CSRSS.EXE, начиная с NT4 — в win32k.sys. Драйверы загружались туда же. DIBENG.DLL была переписана заново и перенесена туда же как совокупность вызовов EngXxx - EngTextOut и другие. Логика взаимодействия драйвера-GDI-DIBENG осталась примерно та же.

GDI32.DLL в режиме пользователя реализована как набор специальных системных вызовов, ведущих в win32k.sys (до NT4 — как обертки вокруг вызова CsrClientCallServer, посылавшего сообщение в CSRSS.EXE).

В Windows Vista появилась модель драйверов WDDM, в которой была отменена возможность использования аппаратуры двухмерной графики. При использовании WDDM все GDI-приложения (т. е. все обычные системные части Windows UI — заголовки и рамки окон, рабочий стол, таскбар и другое) используют GDI-драйвер cdd.dll (Canonical Display Driver), который рисует на некоторых bitmapах в памяти, своих для каждого окна (содержимое окна стало запоминаться в памяти, до того Windows никогда так не делала и всегда перерисовывала окна заново, кроме неких специальных окон с флагом CS_SAVEBITS). Изображения из cdd.dll извлекаются процессом dwm.exe (Desktop Window Manager), который является Direct3D-приложением и отрисовывает «картинки окон» на физическом экране через Direct3D.

Сам же WDDM-драйвер поддерживает только DirectDraw и Direct3D и не имеет отношения ни к GDI, ни к win32k.sys, сопрягаясь с модулем dxgkrnl.sys в ядре.

User mode и kernel mode

При обсуждении архитектуры ОС Windows NT постоянно используются понятия «режим пользователя» и «режим ядра», поэтому стоит определить, что это значит. Начнем с обсуждения разницы между пользовательским режимом и режимом ядра (user mode/kernel mode).

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

Режим ядра - привилегированный режим. Те части NT, которые исполняются в режиме ядра, такие как драйверы устройств и подсистемы типа Диспетчера Виртуальной Памяти, имеют прямой доступ ко всей аппаратуре и памяти.

Различия в работе программ пользовательского режима и режима ядра поддерживаются аппаратными средствами компьютера (а именно - процессором).

Большинство архитектур процессоров обеспечивают, по крайней мере, два аппаратных уровня привилегий. Аппаратный уровень привилегий процессора определяет возможное множество инструкций, которые может вызывать исполняемый в данный момент процессором код. Хотя понятия «режим пользователя» и «режим ядра» часто используются для описания кода, на самом деле это уровни привилегий, ассоциированные с процессором. Уровень привилегий накладывает три типа ограничений:

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

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

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

24. Системный реестр (структура системного реестра Windows).

Редактор системного реестра. Импорт и экспорт данных системного реестра.

Предопределенные ключи системного реестра.

Создание резервных копий и восстановление системного реестра.

Регистрация типа документа и расширения имени файла в реестре (Лаб.раб 3).

Реестр Windows XP отличается многоуровневой архитектурой, включающей в себя четыре нисходящих логических компонента. К первому компоненту, расположенному в самом верху иерархии реестра, относятся так называемые ветви реестра. Эти ветви обозначаются с использованием англоязычной аббревиатуры HKEY_. После символа подчеркивания идет название самой ветви. Всего в реестре Windows XP есть пять основных ветвей: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS и HKEY_CURRENT_CONFIG.

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

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

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

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

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

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

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

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

Разобравшись с реестром, перейдем к обзору типы данных, которые хранятся в параметрах реестра Windows.

Типы данных системного реестра Windows

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

• REG_NONE. Тип данных «Неизвестный». Зашифрованные данные.

• REGSZ. Тип данных «Строковый». Текст.

• REG_EXPAND_SZ. Тип данных «Строковый». Текст и переменные.

• REG_BINARY. Тип данных «Двоичный». Двоичные данные.

• REG_DWORD. Тип данных «Числовой». Число.

• REG_DWORD_BIN_ENDIAN. Тип данных «Числовой». Число с обратным порядком байтов.

• REG_LINK. Тип данных «Строковый». Путь к файлу.

• REG_MULTI_SZ. Тип данных «Многостроковый». Массив строк.

• REG_RESOURCE_LIST. Тип данных «Строковый». Список ресурсов устройств.

• REG_FULL_RESOURCE_DESCRIPTOR. Тип данных «Строковый». Идентификатор ресурса устройства.

• REG_RESOURCE_REQUIREMENTS_LIST. Тип данных «Строковый». Идентификатор ресурса устройства.

Любой пользователь может свободно редактировать все значения параметров реестра, причем не важно, к какому типу данных, из указанных ранее, они относятся. В программе Редактор реестра представлен набор встроенных мастеров, которые дают возможность менять разнообразные типы данных. В частности, для настройки значений числовых параметров используется мастер DWORD, двоичных — BINARY, строковых — STRING и многостроковых — MULTISTRING.

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

• HKEY_LOCAL_MACHINE (HKLM). В этой ветви представлены данные, связанные с операционной системе и оборудованием. К ним относятся, например, тип шины компьютера, общий объем доступной оперативной памяти, список загруженных в текущий момент времени драйверов устройств, а также информация об особенностях загрузки Windows. Это самая объемная ветвь системного реестра Windows XP, которая применяется для тонкой настройки оборудования компьютера. При этом данные, расположенные в этой ветви, относятся сразу ко всем профилям пользователей, зарегистрированных в системе.

• HKEY_CURRENT_USER (HKCU). В этой ветви находятся сведения о пользователе, текущий сеанс работы которого обслуживается реестром. В подразделах этой ветви записаны данные о переменных окружения, группах программ пользователя, настройках рабочего стола и экрана, сетевых соединениях, принтерах и дополнительной конфигурации программ (в Windows XP переменные окружения применяются в сценариях, записях реестра и других программах лишь в роли подстановочных параметров). Эта информация передаются из подраздела Security ID (SID) ветви HKEY_USERS для текущего пользователя. Другими словами, в данной ветви предоставлена вся информация, относящаяся к профилю активного пользователя Windows.

• HKEY_CLASSES_ROOT (HKR). В данной ветви находятся данные об операционной системе и оборудовании, к примеру, тип шины компьютера, объем доступной оперативной памяти, список загруженных в текущий момент времени драйверов устройств, а также информация, связанная с загрузкой Windows. Эта ветвь содержит наибольший объем информации в системном реестре Windows XP и зачастую применяется для тонкой настройки оборудования компьютера. Данные в этой ветви относятся к профилям всех зарегистрированных в системе пользователей.

• HKEY_USERS (HKU). В этой ветви расположены подразделы с данными о всех профилях пользователей компьютера. Один из ее подразделов всегда связан с подразделом HKEY_CURRENT_USER (через параметр Security ID (SID) пользователя)). В другом подразделе, а именно, подразделе, HKEY_USERS\DEFAULT, представлены данные о параметрах системы в настоящий момент времени, которые были актуальны до начала сеанса работы пользователя, зарегистрированного в системе.

• HKEY_CURRENT_CONFIG (HKCC). В данной ветви представлены подразделы со сведениями обо всех профилях оборудования, активного в текущем рабочем сеансе. Профили оборудования дают возможность выбирать драйверы поддерживаемых устройств для выбираемого сеанса работы (что позволяет, к примеру, не задействовать активацию порта док-станции переносного компьютера в тот период, когда он не подключен к станции). Данные сведения передаются из подразделов HKEY_LOCAL_MACHlNE\SYSTEM\CurrentControlSet.

Для эффективной работы с системным реестром Windows XP вам понадобятся специальные программы, предназначенные для работы в данной области. Ключевым инструментом, который известен практически всем, является программа Редактор реестра (Registry Editor), которая поставляется вместе с операционной системой.

Некоторые из инструментов, дающих возможность модифицировать настройки реестра, расположены на самой панели управления Windows XP. Почти все свойства операционной системы, которые имеют отношение к окружению пользовательской среды, ее функциям и ограничениям, доступны для модификации с использованием специализированной программы, которая называется Редактор системных политик (SPE).

Реестром можно управлять и из стандартной командной строки Windows. При этом никаких проблем не составит создать командный файл, содержащий список команд командного интерпретатора cmd, и запускать его по мере надобности. Такой метод управления реестром хоть и является альтернативным, но все же довольно популярен.

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

Программа Редактор реестра (она же RegEdit) поставляется вместе с Windows XP и используются для прямого изменения параметров системного реестра. Чтобы запустить программу, выберите команду Пуск>Выполнить, затем в поле Открыть введите команду regedit и щелкните на кнопке OK. Кроме того, программу можно запустить и просто из командной строки. Какой бы вариант не был выбран, откроется окно, показанное на рисунке далее.

Как видите, рабочее окно программы Редактор реестра содержит две панели: в левой (панель разделов) представлено дерево ветвей, разделов и подразделов, из которых состоит реестр Windows ХР, а в правой (панель параметров) находятся параметры, используемые для выбранного объекта реестра. По своей сути программа RegEdit мало отличается от файлового менеджера Проводник Windows.

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

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

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

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

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

• Меню Вид. Используется для изменения настроек программы.

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

• Меню Справка. Как понятно из названия, просто справка по программе.

Импорт и экспорт файлов кустов реестра

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

Экспортированный файл реестра представляет собой обычный текст в формате ASCII, который можно читать и редактировать при помощи любого текстового редактора.

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

Чтобы восстановить разделы реестра с помощью Regedit, выберите из меню Реестр команду Импорт файла реестра.

Ниже приведен ряд рекомендаций, по работе с функциями импорта и экспорта реестра:

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

• Перед тем как завершить операцию экспорта (нажатием кнопки Сохранить), убедитесь в том, что вы экспортируете именно нужный диапазон разделов. Если установлен переключатель Весь реестра (АН), то будет экспортирован весь реестр. При установленном переключателе Выбранная ветвь (Selected branch) будет экспортирован раздел, имя которого указано в расположенном ниже поле.

• Соблюдайте осторожность, работая с экспортированными файлами реестра. Не пытайтесь импортировать несовместимые файлы реестра (например, не следует импортировать в реестр Windows NT 5.0 файлы реестра, экспортированные из Windows NT 4.0 или 3.51 и обратно; и уж тем'более ни к чему хорошему не приведет импорт в Windows NT файлов реестра Windows 95/98). Скорее всего, в процессе импорта произойдет ошибка, и если процедура импорта до появления ошибки успела записать в реестр некорректные параметры (а это произойдет в большинстве случаев), то нормально работать после этого вы сможете только до первой перезагрузки.

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

Резервное копирование и восстановление реестра

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

• Резервное копирование и восстановление реестра осуществляются, в том числе, и при выполнении рассмотренных ранее процедур резервного копирования и восстановления системных данных (System State data).

• Резервное копирование реестра может выполняться при изготовлении диска аварийного восстановления (ERD). Для этого при создании ERD необходимо установить флажок Архивировать реестр в папку восстановления (Also backup the registry to the repair directory). Резервное копирование реестра будет произведено в папку %SystemRoot%\Kpair. Процедура аварийного восстановления будет использовать информацию из этой папки, поэтому никогда не следует ни удалять, ни модифицировать ее содержимое.

• Резервное копирование и восстановление реестра Windows 2000 может быть выполнено с помощью утилиты Reg, включенной в состав программных продуктов Windows 2000 Resource Kit.

• Резервное копирование и восстановление реестра можно выполнять путем экспорта/импорта реестра с помощью команд Импорт файла реестра (Import Registry File) и Экспорт файла реестра (Export Registry File) программы Regedit или даже вручную.

Ручное резервное копирование и восстановление реестра

Если загрузочный диск Windows NT 4.0 или Windows 2000 отформатирован для использования файловой системы FAT, то резервное копирование реестра с легкостью можно выполнить вручную, загрузив компьютер под управлением другой операционной системы (например, MS-DOS) или Windows 95/98 (в системе с двойной загрузкой или просто с загрузочной дискеты). После этого процедура резервного копирования будет заключаться в обычном копировании файлов кустов реестра, которое может быть выполнено любым способом (из командной строки или с помощью Explorer).

Если загрузочный диск Windows NT 4.0 или Windows 2000 отформатирован для использования файловой системы NTFS, то применение данного метода резервного копирования и восстановления реестра будет затруднено (однако не так уж и невозможно, как утверждается в некоторых источниках). В тех случаях, когда загрузочный диск Windows NT 4.0 или Windows 2000 необходимо форматировать для NTFS (эти требования могут диктоваться правилами безопасности, принятыми на конкретном предприятии, или же необходимостью использования ряда программных продуктов, требующих установки на разделы NTFS), и при этом администратор не хочет отказываться от метода ручного резервного копирования реестра, рекомендуется установить на компьютер избыточную копию Windows NT 4.0 или Windows 2000. Этот совет представляет собой официальную рекомендацию Microsoft по повышению надежности системы, и фигурирует как в сопроводительной документации к программным продуктам из серии Windows NT/2000 Resource Kit, так и в статьях из Microsoft Knowledge Base.

Итак, чтобы выполнить ручное резервное копирование реестров Windows NT 4.0 или Windows 2000, скопируйте содержимое каталога %SystemRoot% \system32\config на другое устройство (носитель ZIP, перезаписываемый компакт-диск или любой другой носитель) — обычной дискеты для этой цели будет недостаточно.

Файлы, которые требуется скопировать из каталога %SystemRoot98\system32 \config, перечислены ниже:

Арр Event. Evt default default.LOG default.sav SAM SAMXOG

Sec Event. Evt Software.LOG SYSTEM.ALT

SECURITY Software.sav System.LOG

SECURITY.LOG SysEvent.Evt System.sav

Software System userdiff

Процедура восстановления реестра при помощи этого метода резервного копирования требует загрузки компьютера под управлением другой операционной системы. После загрузки компьютера файлы резервной копии следует скопировать обратно в папку %SystemRoot%\system32\conug.