Файл: «ФУНКЦИИ ОПЕРАЦИОННЫХ СИСТЕМ ПЕРСОНАЛЬНЫХ КОМПЬЮТЕРОВ».pdf

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

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

Так как файловых систем (ФС) существует достаточно много, а операционная система должна уметь работать с любой из них, то для каждой конкретной ФС также применяются драйвера. Хотя файловые системы не являются физическим устройством (в данном случае, устройством является жесткий диск), однако программы для работы с ними также называют драйверами. Например, в операционной системе Windows есть файл ntfs.sys, являющийся драйвером файловой системы NTFS, и говорящий ОС, как именно необходимо организовывать файлы на диске, с точки зрения данной ФС.

Самые распространенные файловые системы разнятся в зависимости от используемой ОС. Как правило, в операционной системе Windows применяются файловые системы NTFS или ReFS, а в семействе операционных систем Linux – ext2/3/4, BtrFS или ZFS.

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

• • Специальные файловые системы для хранения настроек или взаимодействия с ядром ОС. Примерами могут являться файловые системы /sys и /proc в ОС Linux, либо файл реестра в Windows;
  • Специальные файловые системы для флеш-устройств, обеспечивающие небольшое число операций чтения-записи (так как каждая флешка рассчитана хоть и на большое, но на конечное число таких циклов). Здесь применяются такие ФС как FAT32 или exFAT;
  • Специальные файловые системы для оптических дисков, которые, как правило, поддерживают лишь однократную запись, например, ISO9660;
  • Специальные файловые системы, не относящиеся к одной операционной системе, а допускающие работу сразу с несколькими физическими компьютерами. Сюда можно отнести такие ФС, как Lustre или Ceph. С их помощью можно создать некий «кластер», в котором файлы будут доступны даже при выходе нескольких компьютеров кластера из строя.

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

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

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

4.2 Абстракция виртуальной памяти

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

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

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

Например, если программист написал программу, которой нужно 4 гигабайта памяти, то она либо откажется работать на системе, где памяти меньше (либо ее больше, но она занята другими программами), либо ему придется существенно ее переделывать, добиваясь снижения потребления памяти, возможно в ущерб быстродействию.

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

Для того же, чтобы решить вторую проблему, любая современная ОС предоставляет каждой программе максимально доступный объем памяти. В случае 32-разрядной операционной системы это байт памяти, или 4 Гигабайта (на самом деле, конечно меньше, так как сама ОС также занимает ее часть). Если система 64-разрядная, то теоретически, каждая программа может адресовать байт памяти, однако это настолько огромное число, что, как правило, истинный объем существенно меньше этого числа (но тем не менее, гораздо больше чем байта).

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

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

Для решения и этой проблемы существует такое понятие как «файл подкачки» (в Windows) или «своп-файл» (в Linux). Как только программы начинают требовать память в объеме большем, чем физически доступно на компьютере, ОС начинает переписывать самые редко используемые ее области на жесткий диск (Windows – в специальный файл pagefile.sys, а Linux – в раздел особого типа). Как только достаточный объем памяти оказывается на жестком диске, операционная система может повторно выделить данные области памяти другим процессам.

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

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

5 Интерфейс между различными программами

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

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

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

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

Операционная система Microsoft Windows позволяет организовать такое взаимодействие между программами с помощью еще одной абстракции под названием «Object Linking and Embedding», или, сокращенно, OLE.

Данная технология описывает, что должна уметь каждая программа, если она хочет, чтобы в нее можно было вставлять данные других программ (быть клиентом OLE, в данном случае Microsoft Word), либо чтобы ее собственные данные можно было внедрить куда-то еще (быть сервером OLE, в данном случае, какой-нибудь редактор изображений, например Paint).

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

Например, если мы работаем в программе Microsoft Word, и вставляем в него диаграмму. Если бы программа Word не понимала технологии OLE, то она либо должна была бы самостоятельно реализовывать работу с диаграммами, либо настраиваться на работу с конкретной программой, и работать с ней в связке. Но так как Word понимает технологию OLE, то он может посмотреть, какая программа отвечает за редактирование диаграмм (например, Microsoft Visio), и просто особым образом вызвать ее.

Когда мы построим какую-нибудь диаграмму в данной вызванной программе, мы закрываем ее, однако так как ее запустили в режиме OLE, программа не просто закрывается, а преобразует свои данные в формат векторного изображения Windows Metafile, и вместе со своими исходными данными, передает клиенту (которым в данном случае является программа Microsoft Word).

Этот текстовый процессор, получив данные программы (которые он не понимает, так как предназначен для редактирования текста, а не диаграмм), сохраняет их нетронутыми внутри своего документа .DOC или .DOCX, а вот возвращаемый программой векторный рисунок он отображает на месте внедренного объекта «Диаграмма». Пользователь не заметит разницы, так как этот векторный рисунок в точности повторяет то, что он видел, когда редактировал эту диаграмму в Microsoft Visio. А если он снова захочет изменить эту диаграмму, то Visio будет запущен снова, только в этот раз он получит свои данные, заранее сохраненные вместе с документом. Хотя сам текстовый процессор Microsoft Word не понимает их смысла, тем не менее, он знает, что программа Microsoft Visio умеет с ними работать, и для нее (и для пользователя) они что-то значат. Когда пользователь отредактирует диаграмму, ее измененные данные, и новое векторное изображение снова попадет в файл .DOC.

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

Заключение