Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Конспект лекций по дисциплине
«СИСТЕМНОЕ ПРОГРАММИРОВАНИЕ И ОПЕРАЦИОННЫЕ СИСТЕМЫ»
Литература
Гордеев А.В. Операционные системы. – СПб.: Питер, 2007. – 416 с.
Гордеев А.В., Молчанов А.Ю. Системное программное обеспечение. – СПб.: Питер, 2002. – 736 с.
Харт Д.М. Системное программирование в среде Windows.: пер. с англ. – М.: Издательский дом «Вильямс», 2005. – 529 с.
Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки программного обеспечения. – М.: ИД «ФОРУМ»: ИНФРА-М, 2008. – 400 с.
Иртегов Д.В. Введение в операционные системы. – СПб.: БХВ-Петербург, 2002. – 624 с.
Олифер В.Г., Олифер Н.А. Сетевые операционные системы. – СПб.: Питер, 2001. – 544 с.
Партыка Т.Л., Попов И.И. Операционные системы, среды и оболочки. М.: ФОРУМ: ИНФРА-М, 2007. – 528 с.
Реймонд С. Искусство программирования для UNIX. – М.: Издательский дом «Вильямс», 2005. – 544 с.
Лекция № 1. ОСНОВНЫЕ ПОНЯТИЯ
1.1. Операционные системы
Все программное обеспечение (ПО) делится на системное и прикладное. Системными принято называть такие программы, которые используются всеми остальными программами, без них невозможно создание и выполнение прикладных программ. Прикладные программы выполняют научные, технические и иные задачи, непосредственно не связанные с управлением компьютером. В составе системного ПО можно выделить две составляющие: базовое и сервисное.
Базовое ПО – это минимальный набор программных средств, обеспечивающих работу компьютера. В него входят: операционная система и операционные оболочки.
Сервисное ПО – программы и программные комплексы, которые расширяют возможности базового ПО и организуют более удобную среду работы пользователя.
Операционная система (ОС) представляет собой комплекс управляющих и обрабатывающих программ, которые, с одной стороны, выступают как интерфейс между аппаратурой компьютера и пользователем с его задачами, а с другой стороны, предназначены для наиболее эффективного расходования ресурсов вычислительной системы и организации надежных вычислений.
Операционная система изолирует аппаратное обеспечение компьютера от прикладных программ пользователей. И пользователь, и его программы взаимодействуют с компьютером через интерфейсы операционной системы.
Примеры операционных систем: UNIX, OS/2, Windows, Linux, QNX, MacOS, BeOS.
Основные функции операционной системы следующие:
1.2. Операционные среды
Прикладная программа, созданная для работы в некоторой операционной системе, не будет работать в другой операционной системе, поскольку API у этих операционных систем различаются. Стремясь преодолеть это ограничение, разработчики операционных систем стали создавать так называемые операционные среды. Операционная система (в общем случае) может поддерживать несколько операционных сред, связанных с другими операционными системами.
Та программная среда, которая непосредственно образуется кодом операционной системы, называется основной, естественной, или нативной (native – по английски «туземец»). Помимо основной операционной среды в операционной системе могут быть организованы (путем эмуляции иной операционной среды) дополнительные программные среды. Если в операционной системе организована работа с различными операционными средами, то в такой системе можно выполнять программы, созданные не только для данной, но и для других операционных систем.
Например, можно создать программу для работы в среде DOS. Если такая программа все функции, связанные с операциями ввода-вывода и запросами памяти, выполняет не сама, а за счет обращения к системным функциям DOS, то она будет (в абсолютном большинстве случаев) успешно выполняться и в MS DOS, и в OS/2, и в Windows 2000, и даже в Linux.
Операционная система Windows XP позволяет выполнять помимо основных приложений, созданных с использованием Win32API, 16-разрядные приложения для Windows 3.х, 16-разрядные DOS-приложения, 16-разрядные приложения для первой версии OS/2.
Операционная среда – это то системное программное окружение, в котором могут выполняться программы, созданные по правилам работы этой среды. Операционная среда может быть либо нативной (естественной), либо может быть организована в чужой операционной системе путем эмуляции.
1.3. Операционные оболочки
Как правило, все операционные системы имеют интерфейс командной строки. Хотя системному администратору без него не обойтись, пользоваться им не всегда удобно, поскольку необходимо держать в голове множество команд, принятых в данной операционной системе.
Для преодоления этого недостатка было создано множество программных «оболочек» – shell (по английски – «раковина»).
К ним относятся Norton Commander – программа, созданная как надстройка над DOS, FAR Manager – текстовая оболочка для Windows 95/98/NT/2000/XP, Midnight Commander – программная оболочка системы Linux и т.п. Программные оболочки предлагают пользователю меню, из которого он может выбрать желаемое действие.
В последнее время операционные оболочки активно вытесняются графическими интерфейсами (Graphical User Interface – GUI), например X-Window с различными менеджерами окон – KDE, Gnome и т.п., которые приобретают все большую популярность у пользователей.
По-видимому, операционные оболочки можно рассматривать как нечто промежуточное между интерфейсом командной строки и графическими интерфейсами.
1.4. Классификация операционных систем
По тому, какие из вышеперечисленных функций реализованы и каким было уделено больше внимания, а каким меньше, выделяют несколько различных классов ОС. Многие ОС можно отнести к нескольким классам, т.к. многие классы пересекаются.
ДОС (Дисковые Операционные Системы). Как правило, это просто некий резидентный набор подпрограмм, не более того. Он загружает пользовательскую программу в память и передает ей управление, после чего программа делает с системой все, что ей заблагорассудится. Считается желательным, чтобы после завершения программы машина оставалась в таком состоянии, чтобы ДОС могла продолжить работу (принципиально же, ДОС ничем не может помешать программе привести систему в нерабочее состояние).
Дисковая операционная система MS DOS для IBM PC является примером систем подобного класса. Она, правда, умеет загружать несколько программ, но не предоставляет средств для одновременного исполнения этих программ.
Существование систем такого класса обусловлено их простотой и тем, что они потребляют мало ресурсов. Еще одна причина, по которой такие системы могут использоваться даже на довольно мощных машинах - требование программной совместимости с ранними моделями того же семейства компьютеров.
ОС. К этому классу относятся системы, берущие на себя выполнение всех вышеперечисленных функций. Под ОС мы будем подразумевать системы «общего назначения», то есть рассчитанные на интерактивную работу одного или нескольких пользователей в режиме разделения времени, при не очень жестких требованиях на время реакции системы на внешние события. Как правило, в таких системах уделяется большое внимание защите самой системы, программного обеспечения и пользовательских данных от ошибочных и злонамеренных действий программ и пользователей. Обычно такие системы используют встроенные в архитектуру процессора средства защиты и виртуализации памяти. К этому классу относятся такие широко распространенные системы, как различные семейства Unix, OS/2, семейство Windows NT, хотя некоторые из них не обеспечивают одновременной работы нескольких пользователей и защиты пользователей и программ друг от друга.
ОС могут работать на компьютерах с одним или несколькими процессорами. ОС с мультипроцессорной обработкой делятся на две категории – с асимметричной либо симметричной обработкой.
Операционные системы с асимметричной мультипроцессорной обработкой (asymmetric multiprocessing, ASMP) обычно выбирают для исполнения собственного кода один и тот же процессор, в то время как другие процессоры выполняют только пользовательские задачи. Так как код ОС исполняется на одном процессоре, то ОС ASMP довольно просто создать, усовершенствовав существующую однопроцессорную ОС. Особенно хорошо ОС ASMP подходят для работы на асимметричном оборудовании, например, процессоре, к которому подключен сопроцессор, или на двух процессорах, совместно использующих не всю доступную память. Однако такую ОС трудно сделать переносимой. Аппаратура разных производителей (и даже разные версии аппаратуры одного производителя) имеет тенденцию различаться по типу и степени асимметрии. Либо производители оборудования должны ориентироваться на одну ОС, либо ОС придется постоянно переписывать для каждой аппаратной платформы.
Системы с симметричной мультипроцессорной обработкой (symmetric multiprocessing, SMP) позволяют коду ОС выполняться на любом свободном процессоре или на всех процессорах одновременно, причем каждому из процессоров доступна вся память. Такой подход полнее реализует возможности нескольких процессоров, так как дает возможность полнее использовать процессорное время, независимо от того, какие приложения исполняются. Исполнение ОС только на одном процессоре может сильно загружать его, в то время как остальные простаивают, что уменьшит производительность системы; при увеличении числа процессоров в системе возрастает вероятность того, что узким местом станут именно действия, выполняемые ОС. Помимо равномерного распределения системной загрузки, системы SMP сокращают время простоя из-за неисправностей, так как при сбое одного процессора код ОС может исполняться на других. Наконец, поскольку симметричная аппаратура реализуется разными производителями сходным образом, имеется возможность создания переносимой ОС SMP.
Системы реального времени. Это системы, предназначенные для облегчения разработки так называемых приложений реального времени. Это программы, управляющие некомпьютерным по своей природе оборудованием, часто с очень жесткими ограничениями по времени реакции. Примером такого приложения может быть программа бортового компьютера крылатой ракеты, системы управления ускорителем элементарных частиц или промышленным оборудованием. Такие системы обязаны поддерживать многопроцессность, гарантированное время реакции на внешнее событие, простой доступ к таймеру и внешним устройствам. Примером такой системы может служить ОС QNX.
Любопытно, что multimedia при качественной реализации предъявляет к системе те же требования, что и промышленные задачи реального времени. В multimedia основной проблемой является синхронизация изображения на экране со звуком. Именно в таком порядке. Звук обычно генерируется внешним аппаратным устройством с собственным таймером, и изображение синхронизируется с ним же. Человек способен заметить довольно малые временные неоднородности в звуковом потоке. Напротив, пропуск кадров в визуальном потоке не так заметен, а расхождение звука и изображения заметно уже при задержках около 30 мс. Поэтому системы качественного multimedia должны обеспечивать синхронизацию с такой же или более высокой точностью, что мало отличается от систем мягкого реального времени.
В последнее время вошел в употребление еще один термин: сетевые ОС, или сокращенно NOS (Networking Operating System). Его употребляют в двух различных смыслах:
Лекция № 2. ПРОЦЕССЫ И РЕСУРСЫ
2.1. Вычислительный процесс
Понятие вычислительного процесса, или просто процесса, является основным при рассмотрении операционных систем.
Процесс, иногда называемый задачей (task), – это отдельная программа с ее данными, выполняющаяся на последовательном процессоре.
Концепция процесса предполагает два аспекта: во-первых, он является носителем данных и, во-вторых, он собственно и выполняет операции, связанные с обработкой этих данных.
В качестве примеров процессов (задач) можно назвать прикладные программы пользователей, утилиты и другие системные обрабатываемые программы. Процессом может быть редактирование какого-либо текста, трансляция исходной программы, ее компоновка, исполнение. Причем, трансляция какой-нибудь исходной программы является одним процессом, а трансляция следующей исходной программы – другим процессом, поскольку транслятор как объединение программных модулей здесь выступает как одна и та же программа, но данные, которые он обрабатывает, являются разными.
При исполнении программ на процессоре чаще всего различают следующие характерные отдельные состояния:
порождение — подготовка для первого исполнения на процессоре
активное состояние, или состояние “Счет” — программа исполняется на процессоре
ожидание — программа не исполняется на процессоре по причине занятости какого-либо требуемого ресурса
готовность — программа не исполняется, но для исполнения предоставлены все необходимые в текущий момент ресурсы, кроме центрального процессора
окончание — нормальное или аварийное окончание исполнения программы, после которого процессор и другие ресурсы ей не предоставляются
Процесс находится в каждом из своих допустимых состояний в течение некоторого времени, после чего переходит в какое-то другое допустимое состояние. Состав допустимых состояний, а также допустимые переходы из состояния в состояние обычно задают в форме графа существования процесса, пример которого изображен на рис. 2.1:
Рис. 2.1. Граф существования процесса
Для ОС процесс в такой трактовке рассматривается как объект, в отношении которого требуется обеспечить реализацию каждого из допустимых состояний, а также допустимые переходы из состояния в состояние в ответ на события, которые могут явиться причиной таких переходов. Такие события могут инициироваться и самими процессами, которые способны затребовать процессор или какой-либо другой ресурс, необходимый для исполнения программы.
2.2. Классификация процессов
Процессы определяются рядом временных характеристик. В некоторый момент времени процесс может быть порожден (образован), а через некоторое время закончен. Интервал между этими моментами называют интервалом существования процесса.
В момент порождения последовательность и длительность пребывания процесса в каждом из своих состояний (трасса процесса) в общем случае непредсказуемы. Следовательно, непредсказуема и длительность интервала существования. Однако отдельные виды процессов требуют такого планирования, чтобы гарантировать окончание процесса до наступления некоторого конкретного момента времени. Процессы такого класса называют процессами реального времени. В другой класс входят процессы, время существования которых должно быть не более интервала времени допустимой реакции компьютера на запросы пользователя. Процессы такого класса называют интерактивными. Процессы, не вошедшие в эти классы, называют пакетными.
В любой ОС по требованию существующего или существовавшего процесса проводится работа по порождению процессов. Процесс, задающий данное требование, называют порождающим, а создаваемый по требованию — порожденным. Если порожденный процесс на интервале своего существования в свою очередь выдает требование на порождение второго процесса, то он одновременно становится и порождающим.
При управлении процессами важно обеспечить воспроизводимость результатов работы каждого процесса, учитывать и управлять той ситуацией, которая складывалась при развитии процесса. Введем понятие "трасса" — порядок и длительность пребывания процесса в допустимых состояниях на интервале существования. Проблематичность управления процессами заключается в том, что в момент порождения процессов их трассы неизвестны. Кроме того, требуется учитывать, каким образом соотносятся во времени интервалы существования процессов. Если интервалы двух процессов не пересекаются во времени, то такие два процесса называют последовательными друга относительно друга. Если на рассматриваемом интервале времени существуют одновременно два процесса, то они на этом интервале являются параллельными друг относительно друга. Если на рассматриваемом интервале найдется хотя бы одна точка, в которой существует один процесс, но не существует другой, и хотя бы одна точка, в которой оба процесса существуют одновременно, то такие два процесса называют комбинированными.
Программные процессы принято делить на системные и пользовательские. При развитии системного процесса исполняется программный код из состава операционной системы. При развитии пользовательского процесса исполняется пользовательская (прикладная) программа.
Процессы независимо от их вида могут быть взаимосвязанными или изолированными друг вот друга. Два процесса являются взаимосвязанными, если между ними поддерживаются с помощью системы управления процессами какого-либо рода связи: функциональные, пространственно-временные, управляющие, информационные и т.д. В противном случае они являются изолированными (точнее - процессами со слабыми связями, так как при отсутствии явных связей они могут быть связаны косвенно и определенным образом влиять на развитие друг друга). Когда необходимо подчеркнуть связь между взаимосвязанными процессами по ресурсам, их называют конкурирующими.
Управление взаимосвязанными процессами в составе ОС основано на контроле и удовлетворении определенных ограничений, которые накладываются на порядок выполнения таких процессов. Данные ограничения определяют виды отношений, которые допустимы между процессами, и составляют в совокупности синхронизирующие правила.
Отношение предшествования. Для двух процессов это отношение означает, что первый процесс должен переходит в активное состояние всегда раньше второго.
Отношение приоритетности. Процесс с приоритетом Р может быть переведен в активное состояние только при соблюдении двух условий: в состоянии готовности к рассматриваемому процессору нет процессов с большим приоритетом; процессор либо свободен, либо используется процессом с меньшим, чем Р, приоритетом.
Отношение взаимного исключения. Здесь два процесса используют общий ресурс. При этом совокупность действий над этим ресурсом в составе одного процесса называют критической областью. Критическая область одного процесса не должна выполняться одновременно с критической областью над этим же ресурсом в составе другого процесса.
2.3. Ресурс
Концепция процесса преследует цель выработать механизмы распределения и управления ресурсами. Термин ресурс обычно применяется по отношению к многократно используемым, относительно стабильным объектам, которые запрашиваются, задействуются и освобождаются в период их активности.
Рис. 2.2. Классификация ресурсов
Ресурсы могут быть разделяемыми, когда несколько процессов используют их одновременно (в один и тот же момент времени) или параллельно (попеременно в течение некоторого интервала времени), а могут быть и неделимыми (рис. 2.2).
При разработке первых систем ресурсами считались процессорное время, память, каналы ввода-вывода и периферийные устройства. Однако очень скоро понятие ресурса стало гораздо более универсальным и общим. Различного рода программные и информационные ресурсы также могут быть определены для системы как объекты, которые могут разделяться, и доступ к которым необходимо соответствующим образом контролировать. В настоящее время понятие ресурса превратилось в абстрактную структуру с целым рядом атрибутов, характеризующих способы доступа к этой структуре и ее физическое представление в системе. Ресурсами стали называть и такие объекты, как сообщения и синхросигналы, которыми обмениваются задачи.
В первых вычислительных системах любая программа могла выполняться только после полного завершения предыдущей. Поскольку эти первые вычислительные системы были построены в соответствии с принципами, изложенными в известной работе Яноша Джона фон Неймана, все подсистемы и устройства компьютера управлялись исключительно центральным процессором. Центральный процессор осуществлял и выполнение вычислений, и управление операциями ввода-вывода данных. Соответственно, пока осуществлялся обмен данными между оперативной памятью и внешними устройствами, процессор не мог выполнять вычисления. Введение в состав вычислительной машины специальных контроллеров позволило совместить во времени (распараллелить) операции вывода полученных данных и последующие вычисления на центральном процессоре. Однако все равно процессор продолжал часто и долго простаивать, дожидаясь завершения очередной операции ввода-вывода. Поэтому было предложено организовать так называемый мультипрограммный, или мультизадачный, режим работы вычислительной системы.
Лекция № 3. МУЛЬТИПРОГРАММИРОВАНИЕ
3.1. Введение
Смысл мультипрограммного режима работы заключается в том, что пока одна программа (один вычислительный процесс) ожидает завершения очередной операции ввода-вывода, другая программа может быть поставлена на решение. Это позволяет более полно использовать имеющиеся ресурсы и уменьшить общее время, необходимое для решения некоторого множества задач.
Однако, при этом время выполнения каждого процесса в общем случае больше, чем, если бы мы выполняли каждый из них как единственный. При мультипрограммировании повышается пропускная способность системы, но отдельный процесс никогда не может быть выполнен быстрее, чем, если бы он выполнялся в однопрограммном режиме. Всякое разделение ресурсов замедляет работу одного из участников за счет дополнительных затрат времени на ожидание освобождения ресурса.
Совмещение диалогового режима работы с компьютером и режима мультипрограммирования привело к появлению многопользовательских систем. Организовать параллельное выполнение нескольких задач можно разными способами. Если это осуществляется таким образом, что на каждую задачу поочередно выделяется некий квант времени, после чего процессор передается другой задаче, готовой к продолжению вычислений, то такой режим принято называть режимом разделения времени (time sharing).
3.2. Прерывания
Многопользовательский (и многозадачный) режим работы можно организовать благодаря прерываниям.
Прерывание – это принудительная передача управления от выполняемой программы к операционной системе (а через нее – к соответствующей программе обработки прерываний), происходящая при возникновении определенного события. Механизм прерываний реализуется аппаратно-программными средствами. Прерывание непременно влечет за собой изменение порядка выполнения команд процессором.
Главные функции механизма прерываний следующие:
Прерывания бывают внешние (асинхронные) и внутренние (синхронные).
Внешние прерывания – это:
Внутренние прерывания вызываются событиями, которые связаны с работой процессора и являются синхронными с его операциями. Примерами являются следующие запросы на прерывания:
Могут еще существовать прерывания в связи с попыткой выполнить команду, которая сейчас запрещена. Во многих компьютерах часть команд должна выполняться только кодом самой операционной системы, но не прикладными программами. Это делается с целью повышения защищенности выполняемых на компьютере вычислений. Соответственно в аппаратуре предусмотрены различные режимы работы, и пользовательские программы выполняются в режиме, в котором некоторое подмножество команд, называемых привилегированными, не исполняется. К привилегированным командам помимо команд ввода-вывода относятся и команды переключения режима работы центрального процессора, и команды инициализации некоторых системных регистров процессора. При попытке использовать команду, запрещенную в данном режиме, происходит внутреннее прерывание, и управление передается самой операционной системе.
Наконец, существуют собственно программные прерывания. Эти прерывания происходят по соответствующей команде прерываний, то есть по этой команде процессор осуществляет практически те же действия, что и при обычных внутренних прерываниях. Этот механизм был специально введен для того, чтобы переключение на системные программные модули происходило не просто как переход на подпрограмму, а точно таким же образом, как и обычное прерывание.
Наличие сигнала прерывания не обязательно должно вызывать прерывание исполняющей программы. Процессор может обладать средствами защиты от прерываний: отключение системы прерываний, маскирование (запрет) отдельных сигналов прерывания.
Чтобы обработать сигналы прерывания в разумном порядке, им (как уже отмечалось) присваиваются приоритеты. Сигнал с более высоким приоритетом обрабатывается в первую очередь, обработка остальных сигналов прерывания откладывается.
3.3. Супервизор и дисциплины обслуживания
Операционная система состоит из множества программных модулей. Супервизором (supervisor) называется главный модуль операционной системы. В сложных операционных системах он может состоять из нескольких модулей, например супервизора ввода-вывода, супервизора прерываний, супервизора программ, диспетчера задач и т.д.
При необходимости использовать какой-нибудь ресурс (оперативную память, устройство ввода-вывода, массив данных и т.п.) вычислительный процесс путем обращения к супервизору операционной системы посредством специальных вызовов сообщает о своем требовании. При этом указывается вид ресурса и, если надо, его объем. Например, при запросе оперативной памяти указывается количество адресуемых ячеек, необходимое для дальнейшей работы.
Команда обращения к операционной системе передает ей управление, переводя процессор в привилегированный режим работы. Большинство компьютеров имеют два (и более) режима работы: привилегированный (режим супервизора) и пользовательский. Кроме того, могут быть режимы для эмуляции какой-нибудь другой ЭВМ или для организации виртуальной машины, защищенной от остальных вычислений, осуществляемых на этом же компьютере, и т.д.
Ресурс может быть выделен вычислительному процессу, обратившемуся к операционной системе с соответствующим запросом, если:
Получив запрос, операционная система либо удовлетворяет его и возвращает управление задаче, выдавшей данный запрос, либо, если ресурс занят, ставит задачу в очередь к ресурсу, переводя ее в состояние ожидания (блокируя). Очередь к ресурсу может быть организована несколькими способами, но чаще всего она реализуется с помощью списковой структуры.
После окончания работы с ресурсом задача опять с помощью специального вызова супервизора (посредством соответствующей команды) сообщает операционной системе от отказа от ресурса, либо операционная система забирает ресурс сама, если управление возвращается супервизору после выполнения какой-либо системной функции.
Супервизор, получив управление по этому обращению, освобождает ресурс и проверяет, имеется ли очередь к освободившемуся ресурсу. Если очередь есть, то в зависимости от принятой дисциплины обслуживания и приоритетов заявок он выводит из состояния ожидания задачу, ждущую ресурс, и переводит ее в состояние готовности к выполнению, после чего либо передает управление ей, либо возвращает управление задаче, только что освободившей ресурс.
Термин «дисциплина обслуживания» означает некое правило обслуживания, в том числе и учет каких-либо приоритетов при обслуживании. Например, дисциплина «пришедший последним обслуживается первым» определяет обслуживание в порядке, обратном очередности поступления соответствующих запросов.
При выдаче запроса на ресурс задача может указать, хочет ли она владеть ресурсом монопольно или допускает совместное использование с другими задачами.
Лекция № 4. СРАВНЕНИЕ ОПЕРАЦИОННЫХ СИСТЕМ
4.1. Схема исторических связей между операционными системами
На рис. 4.1. отражены генетические связи между наиболее известными операционными системами.
Рис. 4.1. Схема исторических связей между операционными системами
Отмеченные серым цветом операционные системы не являются системами разделения времени. Системы, названия которых обрамлены сплошными линиями, до сих пор существуют. Дата «рождения» представляет собой дату первой поставки, дата «смерти» – это дата, когда поставщик прекратил поставку системы.
Сплошные стрелки указывают на генетическую связь или очень сильное влияние дизайна (т.е. более позднюю систему с API-интерфейсом, умышленно переработанным путем обратного проектирования для соответствия более ранней системе). Штриховые линии указывают на значительное влияние конструкции, а пунктирные – наоборот, на слабое влияние конструкции.
Блок «UNIX» включает в себя все частные UNIX-системы, включая AT&T и ранние версии Berkeley Unix. Блок «Linux» включает с себя UNIX-системы с открытыми исходными кодами, каждая из которых была основана в 1991 году. Они имеют генетическую наследственность от раннего UNIX -кода, который был освобожден от частного контроля компании AT&T соглашением по судебному процессу 1993 года.
На рис. 4.1, естественно, представлены не все операционные системы. В частности здесь нет систем реального времени. Были выбраны системы разделения времени, которые либо в настоящее время, либо в прошлом составляли конкуренцию UNIX. Достойных конкурентов не много. Большинство подобных систем (MULTICS, ITS, DTSS, TOPS-10, TOPS-20, MTS, GCOS, MPE и десятки других) исчезли так давно, что почти стерлись из коллективной памяти компьютерного сообщества. Отмирают системы VMS и OS/2, MacOS поглощается UNIX-производными. Операционные системы MVS и VM/CMS были ограничены одной частной линейкой мэйнфреймов. Только Microsoft Windows остается жизнеспособным конкурентом, независимым от традиций UNIX.
4.2. Семейство операционных систем UNIX
UNIX является исключительно удачным примером реализации простой мультипрограммной и многопользовательской операционной системы. В свое время она проектировалась как инструментальная среда для разработки программного обеспечения. Своей уникальностью система UNIX обязана во многом тому обстоятельству, что была, по сути, создана всего двумя разработчиками, которые делали ее исключительно для себя и первое время использовали на мини-ЭВМ с очень скромными вычислительными ресурсами PDP-7.
Создателями UNIX являются Кен Томпсон и Денис Ритчи. В своей операционной системе они учли опыт работы над проектом сложной мультизадачной операционной системы с разделением времени MULTICS (MULTiplexed Information and Computing Service). Название новой системы UNIX произошло от аббревиатуры UNICS (Uniplexed Information and Computing Service). Позднее Ритчи описывал эту аббревиатуру как «слегка изменнический каламбур на слово MULTICS».
Первая версия этой системы занимала всего около 12 Кбайт и могла работать на компьютерах с очень небольшим объемом оперативной памяти.
Первой реальной задачей UNIX в 1971 году была поддержка того, что в наши дни назвали бы текстовым процессором, для патентного департамента Bell Laboratories (Кен Томпсон был сотрудником Bell Laboratories). Этот проект оправдывал приобретение гораздо более мощного мини-компьютера PDP-11. Руководство оставалось в счастливом неведении о том, что система обработки текста, которую создавали Томпсон и его коллеги, была инкубатором для операционной системы. Операционные системы не входили в планы Bell Laboratories – AT&T присоединилась к консорциуму MULTICS именно для того, чтобы избежать разработки собственной операционной системы.
Первоначально операционная система UNIX была написана на ассемблере, а ее приложения – на «смеси» ассемблера и интерпретируемого языка, который назывался «В». Его преимущество заключалось в том, что он был достаточно мал для работы на компьютерах PDP-7. Однако язык «В» был недостаточно мощным для системного программирования, поэтому Денис Ритчи добавил в него типы данных и структуры, в результате чего появился язык «С». Это произошло в начале 1971 года. А в 1973 году Томпсон и Ритчи переписали UNIX на новом языке. Это был весьма смелый шаг. В то время для того, чтобы получить максимальную производительность аппаратного обеспечения, системное программирование осуществлялось на ассемблере, и сама концепция переносимой операционной системы представлялась весьма сомнительной. Только в 1979 году Ритчи смог написать: «Кажется бесспорным, что в основном успех UNIX обусловлен читаемостью, редактируемостью и переносимостью ее программного обеспечения, причем, такие позитивные характеристики, в свою очередь, являются следствием ее написания на языках высокого уровня».
Первой целью при разработке системы UNIX было стремление сохранить простоту и обойтись минимальным количеством функций. Второй целью была общность (начало названия системы «Uni-» можно перевести как «общий» или «единый»). Одни и те же методы и механизмы должны были использоваться во многих случаях:
Третья цель заключалась в том, чтобы сложные задачи можно было решать, комбинируя существующие небольшие программы, а не разрабатывая их заново.
Наконец, четвертая цель состояла в создании мультитерминальной операционной системы с эффективными механизмами разделения не только процессорного времени, но и всех остальных ресурсов. В мультитерминальной ОС на одно из первых мест по значимости выходят вопросы защиты одних вычислительных процессов от вмешательства других вычислительных процессов.
В операционной системе UNIX имеется несколько унифицирующих идей или метафор, которые формируют ее API-интерфейсы и определяемый ими стиль разработки. Наиболее важными из них является модель, согласно которой «каждый объект является файлом», и метафора каналов (pipes). Канал представляет собой способ соединения вывода одной программы с вводом другой.
Специалисты, относящиеся к UNIX-сообществу, утверждают, что философия этой операционной системы сводится к одному железному правилу, священному «принципу KISS»: «Keep It Simple, Stupid!». По-русски это можно перевести так: «Будь проще, тупица!»
Хотя система UNIX появилась еще в 1969 году, она существует и поныне. Какие недостатки конкурентов оставили их в проигрыше?
Наиболее очевидной общей проблемой является неспособность к переносу на другие платформы. Большинство конкурентов UNIX, появившихся до 1980 года, были привязаны к какой-либо одной аппаратной платформе и исчезли вместе с ней. Единственной причиной того, что VMS просуществовала достаточно долго для того, чтобы рассматриваться здесь в качестве учебного примера, является то, что она была успешно перенесена с ее первоначального аппаратного обеспечения VAX на процессор Alpha (а в 2003 году – с Alpha на Itanium). MacOS была успешно перенесена с микросхем Motorola 68000 на Power PC в конце 80-х годов прошлого века. Операционная система Microsoft Windows избежала данной проблемы, оказавшись в нужном месте, когда стремление превратить программное обеспечение в продукт массового потребления привело к заполнению рынка универсальными компьютерами монокультуры PC.
С 1980 года все более проявляется другой недостаток, характерный для различных операционных систем: неспособность обеспечить изящную поддержку сети. В мире распространяющихся сетей даже операционная система, спроектированная для однопользовательской работы, нуждается в многопользовательских средствах (множество групп привилегий), поскольку без таких средств любая сетевая транзакция, которая способна обманным путем вынудить пользователя запустить злонамеренный код, может разрушить всю систему.
Windows, имея серьезные недостатки в данных областях, избегает упадка только благодаря тому, что она получила монопольное положение еще до того, как сетевое взаимодействие стало действительно важным, а также благодаря множеству пользователей, которые в силу определенных условий вынуждены принимать как должное аварийные отказы и бреши в системе безопасности. Данную ситуацию нельзя назвать стабильной. Сторонники Linux успешно ее использовали в 2003 году для того, чтобы проникнуть на рынок серверных операционных систем.
4.3. Операционная система VMS
VMS – частная операционная система, первоначально разработанная для миникомпьютера VAX корпорации «Digital Equipment Corporation» (DEC). Впервые она была выпущена в 1978 году и была важной действующей операционной системой в 80-х и начале 90-х годов. Сопровождение данной системы продолжалось, когда DEC была приобретена компанией Compaq, а последняя – корпорацией Hewlett-Packard. На данный момент операционная система VMS продолжает продаваться и поддерживаться. Она имеет полную вытесняющую многозадачность (при которой процессор принудительно может быть отобран у текущей задачи), однако создание дочерних процессов в ней весьма дорогостоящее. Файловая система в VMS имеет детально разработанное понятие типов записи (хотя в ней нет атрибутов). Поэтому в VMS проявляется тенденция к увеличению размеров программ и созданию тяжеловесных монолитов.
VMS характеризуется длинными четкими системными командами, подобными инструкциям языка COBOL. Имеется весьма полная интерактивная справочная система (не по API интерфейсам, а по запускаемым программам и синтаксису командной строки). Фактически CLI-интерфейс (Command Line Interface – интерфейс командной строки) VMS и ее справочная система являются организационной метафорой VMS. Хотя система Windows модифицирована для VMS, CLI-интерфейс продолжает оказывать наиболее важное стилистическое влияние на проектирование программ. В связи с этим определяется ряд следующих факторов и последствий.
VMS была разработана для многопользовательской работы, она имеет заслуживающую доверия систему внутренних границ, разделяющих процессы друг от друга. Взломы системы безопасности VMS бывают редко.
Первоначально VMS-инструменты были дорогими, а интерфейсы сложными. Огромное количество программной документации для VMS доступны только в бумажной форме, поэтому поиск каких-либо сведений является трудоемкой операцией. Только после того как поставщик VMS почти забросим данную систему, вокруг нее развилось любительское программирование, но данная культура не является особенно стойкой.
Подобно UNIX, операционная система VMS предшествовала разграничению клиент/сервер. Она была успешной в свое время в качестве общецелевой системы разделения времени. Целевую аудиторию главным образом представляли технические пользователи и программные предприятия, допускающие умеренную сложность.
Лекция № 5. ОПЕРАЦИОННЫЕ СИСТЕМЫ MacOS и BeOS
5.1. Операционная система MacOS
Операционная система Macintosh была разработана в компании Apple в начале 80-х годов прошлого века. Ее создателей вдохновила передовая работа по разработке GUI-интерфейсов, осуществленная ранее в Исследовательском центре Palo Alto (Palo Alto Research Center) компании Xerox. Она увидела свет вместе с компьютером Macintosh в 1984 году. С тех пор MacOS подверглась двум значительным преобразованиям конструкции, а в настоящее время претерпевает третье. Первое преобразование было связано с переходом от поддержки только одного приложения в тот или иной момент времени к невытесняющей многозадачности (Multi Finder). Вторым преобразованием был переход с процессоров серии 68000 на процессоры PowerPC, что позволило сохранить обратную бинарную совместимость с приложениями 68К, а также добавило для PowerPC-приложений усовершенствованную систему управления общими библиотеками, заменяющими исходную систему прерываний совместно используемых программ на основе инструкций процессора 68К. Третьим преобразованием было объединение в системе MacOS Х конструкторских идей MacOS с UNIX-производной инфраструктурой. Далее мы будем рассматривать версии данной системы, предшествующие MacOS Х.
В MacOS прослеживается очень сильное влияние унифицирующей идеи, которая весьма отличается от идеи UNIX: нормы проектирования интерфейсов компьютеров Macintosh (Mac Interface Guidelines). Они подробнейшим образом определяют внешний вид графического интерфейса приложений и режимы его работы. Согласованность норм значительно влияет на культуру пользователей компьютеров Macintosh. Нередко просто перенесенные программы из DOS или UNIX, не соблюдающие определенные нормы, немедленно отвергаются сообществом Mac-пользователей и терпят неудачи на рынке.
Одна из ключевых идей относительно норм заключается в том, что рабочие компоненты должны находиться там, куда их перенес пользователь. Документы, каталоги и другие объекты постоянно сохраняются на рабочем столе, не смешиваясь с системной информацией, а содержание рабочего стола сохраняется при перезагрузках.
Унифицирующая идея Macintosh проявляется настолько сильно, что большинство других вариантов конструкции либо находятся под ее влиянием, либо незаметны. Во всех программах предусмотрены графические интерфейсы. Интерфейса командной строки не существует вообще. Средства сценариев есть в наличии, однако они используются значительно реже, чем в UNIX; многие Mac-программисты никогда их не изучают. Присущая MacOS метафора неотделимости GUI-интерфейса (организованная вокруг единственного главного событийного цикла) обусловила наличие слабого планировщика задач без приоритетности обслуживания. Слабый планировщик и работа всех MultiFinder-приложений в одном большом адресном пространстве означают, что использовать отдельные процессы или даже параллельные процессы вместо поочередного опроса непрактично.
Вместе с тем приложения MacOS не являются неизменно огромными монолитами. Системный код поддержки графического интерфейса, который частично реализован в ПЗУ, поставляемом с аппаратным обеспечением, а частично в совместно используемых библиотеках, обменивается данными с MacOS-программами посредством интерфейса событий, который с момента возникновения является весьма стабильным. Таким образом, конструкция данной операционной системы поддерживает относительно четкое обособление ядра приложений от GUI-интерфейса.
В MacOS также имеется мощная поддержка для изоляции метаданных приложений, таких как структуры меню, от кода ядра. Файлы данной операционной системы имеют как «ветвь данных» (data folk) (блок байтов в UNIX-стиле, который содержит документ или программный код), так и «ветвь ресурсов» (resource folk) (набор определяемых пользователем атрибутов файла). Mac-приложения часто проектируются так для того, чтобы (например) используемые в приложениях изображения и звук хранились в ветви ресурса и чтобы их можно было бы модифицировать отдельно от кода приложения.
Система внутренних границ MacOS является очень непрочной. Имеется жесткое предположение о том, что есть только один пользователь, поэтому групп привилегий не существует. Многозадачность определяется как невытесняющая. Все MultiFinder-приложения запускаются в одном адресном пространстве, поэтому некорректный код какого-либо приложения способен разрушить любые данные, находящиеся за пределами низкоуровневого ядра операционной системы. Взломать систему безопасности MacOS-машин весьма просто. Данная операционная система избавлена от вирусных эпидемий главным образом потому, что очень немногие заинтересованы в ее взломе.
Mac-программисты стремятся разрабатывать приложения в противоположном относительно UNIX-программирования направлении, т.е. это направление от интерфейса к ядру, а не наоборот. Такой подход поощряется всей конструкцией MacOS.
Macintosh задумывалась как клиентская операционная система для нетехнический конечных пользователей, что предполагает очень низкую толерантность относительно сложности интерфейса. Разработчики в Mac-культуре достигли значительных успехов в проектировании простых интерфейсов.
Классическая система MacOS устаревает. Большинство имеющихся в ней средств импортируются в MacOS Х, которая объединяет их с UNIX-инфраструктурой, вышедшей из традиций университета в Беркли. MacOS Х состоит из двух частных уровней (перенесенные приложения OpenStep и классические GUI-интерфейсы Macintosh) поверх UNIX-основы с открытым исходным кодом (проект Darwin).
В то же время лидирующие UNIX-системы, например Linux, начинают заимствовать у MacOS такие идеи, как использование атрибутов файлов (обобщение ветви ресурса).
5.2. Операционная система BeOS
Компания Be Inc. была основана в 1989 году как производитель аппаратного обеспечения в виде передовых многопроцессорных машин на основе микросхем PowerPC. Операционная система BeOS бы попыткой компании Be повысить стоимость аппаратного обеспечения путем создания новой сетевой модели операционной системы, учитывающей уроки UNIX и MacOS, но не являющейся подобием одной из них. В результате появилась изящная, ясная и интересная конструкция с превосходной производительностью в предопределенной для нее роли мультимедийной платформы.
Унифицирующими идеями BeOS были «заполняющая параллельная обработка» (pervasive threading), мультимедийные потоки и файловая система, выполненная в виде базы данных. BeOS была спроектирована для минимизации задержек в ядре, что делало ее применимым для обработки в реальном времени больших объемов таких данных, как аудио- и видео- потоки. «Параллельные процессы» (threads) BeOS по существу были легковесными процессами в терминологии UNIX, так как они поддерживали локальную память процесса и, следовательно, не обязательно совместно использовали все адресное пространство. Межпроцессорный обмен данными посредством совместно используемой памяти был быстрым и эффективным.
BeOS придерживалась модели UNIX в том, что не имела файловой структуры выше байтового уровня. Подобно MacOS, операционная система BeOS поддерживала и использовала атрибуты файлов. По сути, файловая система BeOS была базой данных с возможностью индексации по любому атрибуту.
Одним из элементом, заимствованным BeOS у UNIX, была логичная конструкция внутренних границ. В описываемой системе работающие процессы надежно изолированы друг от друга. Несмотря на то, что BeOS представлялась как однопользовательская операционная система (без необходимости регистрации в ней), в ее файловой системе и во всем внутреннем устройстве поддерживались UNIX-подобные группы привилегий. Они использовались для защиты важнейших системных файлов от воздействия ненадежного кода. В терминологии UNIX пользователь во время загрузки регистрировался в системе как анонимный гость, а другим единственным «пользователем» был root. Полная многопользовательская функциональность потребовала бы небольших изменений в верхних уровнях системы и по сути была представлена утилитой BeLogin.
Предпочтительным стилем пользовательского интерфейса был GUI, который соответствовал опыту MacOS в области дизайна интерфейсов. Вместе с тем также полностью поддерживались CLI-интерфейс и сценарии. Оболочкой командной строки была перенесенная с UNIX программа bash(1), доминирующая UNIX-оболочка с открытым исходным кодом, работающая посредством библиотеки совместимости POSIX. Благодаря такой конструкции, преобразование программного обеспечения UNIX CLI было очень простым. В системе присутствовала инфраструктура для поддержки всего разнообразия сценариев, фильтров и служебных доменов, сопутствующих UNIX-модели.
BeOS была предназначена для работы в качестве клиентской операционной системы, специализирующейся на обработке мультимедийных данных (особенно на обработке звука и видео) почти в реальном времени. Целевая аудитория данной системы включала в себя технических и деловых конечных пользователей, предполагающих умеренную толерантность к сложности интерфейса.
Препятствия на пути к разработке BeOS-приложений были небольшими. Несмотря на то, что операционная система была частной, средства разработки были недорогими, и доступ к полной документации не представлял сложности. Проект BeOS начался как часть усилий по освобождению от аппаратного обеспечения Intel с RISC-технологией, и после взрывного роста Internet продолжался исключительно как программный проект. Его стратеги изучили опыт периода формирования Linux в начале 90-х годов и были полностью осведомлены о значении крупной базы любительской разработки. Фактически они преуспели в привлечении верных последователей; в 2003 году не менее пяти отдельных проектов пытались возродить операционную систему BeOS в открытом исходном коде.
К сожалению, в отличие от технического дизайна, окружавшая BeOS бизнес-стратегия была не столь мудрой. Программное обеспечение BeOS первоначально было привязано к специализированному аппаратному обеспечению и продавалось только с неопределенными указаниями о целевых приложениях. Позднее (в 1998 году) операционная система BeOS была перенесена на общее аппаратное обеспечение PC, а мультимедийным приложениям было уделено более пристальное внимание, но система так и не привлекла критическую массу пользователей. Наконец в 2001 году BeOS уступила комбинации конкурентного маневрирования Microsoft (судебный процесс продолжался в 2003 году) и конкуренции со стороны вариантов операционной системы Linux, адаптированных для обработки мультимедиа.
Лекция № 6. ОПЕРАЦИОННЫЕ СИСТЕМЫ ФИРМЫ IBM: OS/2, MVS и VM/CMS
6.1. Операционная система OS/2
Операционная система OS/2 зародилась как опытный проект компании IBM, называвшийся ADOS (Advanced DOS), один из трех претендентов на роль DOS 4. В то время компании IBM и Microsoft формально сотрудничали при разработке операционной системы следующего поколения для компьютеров PC. OS/2 версии 1.0 впервые вышла в 1987 году для компьютеров с процессорами 286-й серии, но не имела успеха. Версия 2.0 для процессоров 386 появилась в 1992 году, но к этому времени альянс IBM/ Microsoft уже распался. Microsoft с системой Windows 3.0 двинулась в другом (более выгодном) направлении. OS/2 привлекала преданное меньшинство последователей, но так и не смогла привлечь критическую массу разработчиков и пользователей. На рынке настольных систем она оставалась третьей после Macintosh до тех пор, пока не была отнесена к Java-инициативе IBM 1996 года. Последней была версия 4.0 в 1996 году. Ранние версии нашли применение во встроенных системах и продолжают работать во многих машинах автоматических справочных служб во всем мире.
Подобно UNIX, OS/2 была создана с поддержкой вытесняющей многозадачности, однако, в отличие от UNIX, никогда не создавалась для работы в качестве многопользовательской системы. Создание дочерних процессов было относительно недорогим, но межпроцессное взаимодействие было сложным и ненадежным. Поддержка сети первоначально сводилась к LAN-протоколам, однако в более поздних версиях был добавлен набор протоколов TCP/IP. В OS/2 не было программ, аналогичных системным службам UNIX, поэтому данная система никогда не обеспечивала многофункциональную поддержку сети.
В данной операционной системе были как CLI-, так и GUI-интерфейс. Большинство положительных отзывов, касающихся OS/2, относились к ее рабочему столу Workplace Shell (WPS). Часть этой технологии была лицензирована у разработчиков AmigaOS Workbench, революционного графического интерфейса настольных систем, который имел верных почитателей в Европе. Это одна из областей дизайна, где OS/2 приобрела такой потенциал, которого UNIX, вероятно, еще не достигла. Оболочка WPS представляла собой четкую, мощную, объектно-ориентированную конструкцию с ясным режимом работы и хорошей расширяемостью. По прошествии нескольких лет она станет исходной моделью для Linux-проекта GNOME.
Конструкция WPS с иерархией классов была одной из унифицирующих идей операционной системы OS/2. Другой идеей была мультипроцессорная обработка. OS/2-программисты использовали организацию параллельной обработки в большой степени как частичную замену IPC (Inter-Process Communication – межпроцессорное взаимодействие) между равноправными процессами. Традиции создания взаимодействующих инструментов не развивались.
OS/2 имела внутренние границы. Работающие процессы были защищены друг от друга, пространство ядра было защищено от пользовательского пространства, но пользовательских групп привилегий не было. Это означало, что файловая система не была защищена от злонамеренного кода.
OS/2 имела текстовый, а не двоичный режим. Она поддерживала атрибуты файлов, которые использовались для сохранения постоянство рабочего стола подобно Macintosh. Системные базы данных хранились главным образом в двоичных форматах.
Пользовательские интерфейсы часто были более эргономичными, чем в Windows, хотя и не достигали стандартов Macintosh. Подобно UNIX и Windows, пользовательский интерфейс OS/2 был организован вокруг множества независимых групп окон для различных задач, вместо захвата рабочего стола действующим приложением.
Целевой аудиторией OS/2 были предприятия и нетехнические пользователи, в связи с чем предполагалась низкая толерантность относительно сложности интерфейса. Данная система использовалась как в качестве клиентской, так и в качестве файлового сервера и сервера печати.
OS/2 представляет интерес как учебный пример того, как далеко может продвинуться конструкция многозадачной, но однопользовательской операционной системы.
6.2. Операционная система MVS
MVS (Multiple Virtual Storage – многопользовательское виртуальное хранение) – ведущая операционная система IBM для мэйн-фреймов корпорации. Ее происхождение связывают с OS/360, операционной системой IBM, появившейся в середине 60-х годов прошлого века.
Из всех рассмотренных здесь операционных систем только MVS может считаться более старшей, чем UNIX. Данная система также менее остальных подверглась влиянию идей и технологии UNIX и представляет надежнейшую конструкцию, противоположную последней. Унифицирующей идеей MVS является то, что вся работа формируется в виде пакета. Система разработана для наиболее эффективного использования машины для пакетной обработки больших объемов данных с минимальной необходимостью взаимодействия с пользователями.
Собственные MVS-терминалы функционируют только в режиме блокировки. Пользователю предоставлен экран, который он заполняет, модифицируя локальную память терминала. Прерывание не происходит до тех пор, пока пользователь не нажмет клавишу отправки. Взаимодействие с помощью командной строки, непосредственный ввод данных с клавиатуры, невозможен.
Другое следствие архитектуры, ориентированной на пакетную обработку, заключается в том, что создание подпроцессов является медленной операцией. В данной системе большая пропускная способность достигается ценой дорогостоящей установки (и связанной с этим задержки). Подобный подход хорошо соответствует пакетным операциям, но плохо сказывается на интерактивном отклике.
Операционная система MVS использует аппаратный блок MMU. Процессы выполняются в отдельных адресных пространствах. Межпроцессорный обмен данными осуществляется через совместно используемую память.
Безопасность файловой системы была поздним дополнением к первоначальной конструкции. Однако, когда выяснилось, что безопасность необходима, IBM добавила соответствующие функции оригинальным образом: разработчики определили общий API-интерфейс функций безопасности, а затем все запросы на доступ к файлам перед обработкой направили через данный интерфейс. В результате существует, по крайней мере, три конкурирующих пакета обеспечения безопасности с различной философией дизайна, и все они весьма хороши, учитывая то, что известных взломов между 1980 годами и настоящим временем не было.
Сетевые средства также были добавлены с опозданием. Любительское программирование в MVS почти отсутствует, существуя только внутри сообщества крупных предприятий, использующих данную операционную систему. Поскольку стоимость среды резко снижается, уже определилась небольшая, но растущая группа пользователей последней свободно распространяемой версии MVS (3.8, датированной 1979 годом). Эта система, как и все средства разработки, а также эмулятор для их запуска, доступны по цене компакт-диска.
6.3. Операционная система VM/CMS
VM/CMS – другой пример операционной системы для мэйн-фреймов. Ее вполне можно назвать «родственницей» системы UNIX: их общим предком является система CTSS, созданная в Массачусетском технологическом институте приблизительно в 1963 году и работавшая на мэнфрейме IBM 7094. Группа, разработавшая CTSS, позднее приступила к написанию MULTICS, прямого предка UNIX. IBM учредила в Кембридже группу по созданию системы разделения времени для IBM 360/40 (впервые для систем IBM).
Операционные системы VM/CMS и UNIX являлись видоизмененными «отражениями» друг друга. Унифицирующая идея системы, обеспеченная компонентом VM, воплощена в виртуальных машинах, которые выглядят как физические машины. Они поддерживают вытесняющую многозадачность и работают либо с однопользовательской операционной системой CMS, либо с полностью многозадачной системой (обычно MVS, Linux или другой экземпляр самой VM). Виртуальные машины соответствуют UNIX-процессам, демонам и эмуляторам, а обмен данными между ними осуществляется путем соединения виртуального карточного перфоратора одной машины с виртуальным считывателем перфокарт другой машины. В дополнение к этому, внутри системы обеспечивается многоуровневая инструментальная среда, которая называется CMS Pipelines (конвейеры CMS), непосредственно смоделированная с каналов UNIX, но архитектурно расширенная для поддержки множества вводов и выводов.
В ситуации, когда обмен данными между виртуальными машинами явно не установлен, они полностью изолированы друг от друга. Данная операционная система характеризуется тем же высоким уровнем надежности, расширяемости и безопасности, что и MVS, а также имеет гораздо большую гибкость и проще в использовании.
Стиль пользовательского интерфейса в CMS является интерактивным и диалоговым, весьма отличающимся от MVS, но похожим на пользовательские интерфейсы VMS и UNIX. Интенсивно используется полноэкранный редактор XEDIT.
Операционная система VM/CMS предшествовала разделению клиент/сервер и в настоящее время используется почти полностью как серверная операционная система с эмуляцией IBM-терминалов. До того как Windows стала полностью доминировать на рынке настольных систем, VM/CMS предоставляла службы обработки текстов и электронную почту как внутри IBM, так и между участками пользователей мэйнфреймов. Многие VM-системы были инсталлированы исключительно для запуска таких приложений благодаря доступной расширяемости VM (десятки тысяч пользователей).
Язык сценариев REXX поддерживает программирование в стиле, не отличающемся от shell, awk, Perl или Python. Следовательно, любительское программирование (особенно системными администраторами) является весьма важным в системе VM/CMS.
Прослеживаются поразительные параллели между историей VM/CMS внутри корпорации IBM и UNIX внутри Digital Equipment Corporation (которая создавала компьютеры, где впервые работала UNIX). Компании IBM потребовались годы, чтобы осознать стратегическую важность ее неофициальной системы разделения времени. В течение этого времени появилось сообщество программистов VM/CMS, поведение которого было весьма сходно с поведением раннего UNIX-сообщества. Они обменивались идеями, открытиями в исследовании систем, а главное – обменивались исходным кодом для утилит. Независимо от того, как часто IBM пыталась объявлять о смерти системы VM/CMS, сообщество настаивало на поддержании ее в рабочем состоянии.
Однако системе VM/CMS не хватает какого-либо реального аналога для языка C. Эта операционная системе написана на ассемблере, и остается такой и поныне. Единственным эквивалентом C были различные сокращенные версии языка PL/I, который использовался в IBM для системного программирования, однако клиентам компании не предоставлялся.
С 2000 года IBM очень активно продвигает операционную систему VM/CMS на мэйнфреймах как способ одновременной поддержки тысяч виртуальных Linux-машин.
Лекция № 7. ОПЕРАЦИОННЫЕ СИСТЕМЫ QNX и Linux
7.1. Операционная система реального времени QNX
Сетевая операционная система реального времени QNX является мощной операционной системой, разработанной для процессоров с архитектурой i32. Она позволяет проектировать сложные программные комплексы, работающие в реальном времени как на отдельном компьютере, так и в локальной вычислительной сети. Встроенные средства QNX обеспечивают поддержку многозадачного режима на одном компьютере и взаимодействие параллельно выполняемых задач на разных компьютерах, работающих в среде локальной вычислительной сети.
Основным языком программирования в системе является C. Основная операционная среда соответствует стандарту POSIX. Это позволяет с небольшими доработками переносить ранее разработанное программное обеспечение в QNX.
Операционная система QNX обладает свойствами предсказуемости и масштабируемости.
Предсказуемость означает применимость системы к задачам жесткого реального времени. QNX является операционной системой, которая дает полную гарантию того, что процесс с наивысшим приоритетом начнет выполняться практически немедленно, и критически важное событие (например, сигнал тревоги) никогда не будет потеряно.
Масштабируемость – свойство, выражающееся в возможности исполнения программы на различных ресурсах (объём памяти, число и производительность процессоров) с пропорциональным изменению ресурсов значением показателей эффективности. Именно способность работать на ограниченных аппаратных ресурсах позволяет использовать QNX во встроенных системах.
С точки зрения пользовательского интерфейса QNX очень похожа на UNIX, поскольку выполняет требования стандарта POSIX. Однако QNX – это не версия UNIX, хотя многие так считают. Операционная система QNX была разработана «с нуля» канадской фирмой QNX Software Systems Limited в 1989 году по заказу Министерства обороны США, причем на совершенно иных архитектурных принципах, нежели использовались при создании операционной системы UNIX.
QNX была первой коммерческой операционной системой, построенной на принципах микроядра и обмена сообщениями. Система реализована в виде совокупности независимых (но взаимодействующих путем обмена сообщениями) процессов различного уровня (менеджеры и драйверы), каждый из которых реализует определенный вид услуг.
Микроядро операционной системы QNX имеет объем всего в несколько десятков килобайтов (в одной из версий – 10 Кбайт, в другой – менее 32 Кбайт, хотя есть вариант и на 46 Кбайт). В этом объеме помещаются:
7.2. Операционная система Linux
Операционная система Linux, созданная Линусом Торвальдсом в 1991 году лидирует среди UNIX-систем новой школы с открытым исходным кодом, появившихся в 1990 году (в их число также входит FreeBSD, NetBSD, OpenBSD и Darwin), и представляет направление конструирования, принятое данной группой в целом.
Linux не включает в себя код из дерева исходных кодов первоначальной UNIX, но данная система была сконструирована на основе UNIX-стандартов и работает подобно UNIX.
Многие разработчики и активисты Linux-сообщества стремятся к тому, чтобы данная операционная система заняла прочные позиции на рабочих столах конечных пользователей. Это делает целевую аудиторию Linux несколько шире, чем в случае какой-либо из UNIX-систем старой школы, которые в основном были нацелены на рынки серверов и рабочих станций технических пользователей.
Наиболее очевидным новшеством является смена предпочтительных стилей интерфейса. Большинство UNIX-программистов долго оставались прочно привязанными к командной строке. Разработчики Linux перешли к созданию GUI-интерфейсов.
Желание склонить на свою сторону конечных пользователей также заставило Linux-разработчиков гораздо больше интересоваться проблемами простоты инсталляции и распространения программного обеспечения, чем это было принято при разработке частных UNIX-систем.
Linux-сообщество стремится превратить свое программное обеспечение в некий универсальный канал связи между различными средами. Поэтому Linux предоставляет поддержку чтения и (нередко) записи форматов файловых систем и методов сетевого взаимодействия, характерных для других операционных систем. Linux также поддерживает возможность выбора операционной системы при начальной загрузке на одном и том же аппаратном обеспечении (мультизагрузку), а также программную эмуляцию данных систем внутри самой себя. Долгосрочной целью является поглощение этих систем.
Linux-разработчики перенимают конструкторские идеи из операционных систем, не относящихся к семейству UNIX. Примером могут служить Linux-приложения, использующие для конфигурации INI-файлы формата Windows. Внедрение в ядро 2.5 Linux расширенных атрибутов файлов, которые среди прочего можно использовать для эмуляции семантики ветви ресурса в Macintosh, – еще один яркий пример этого.
Остальные частные UNIX-системы (такие как Solaris, HP-UX, AIX и другие) разрабатываются как большие продукты для суперкомпьютеров. Их рыночная ниша поддерживает конструкции, оптимизированные под максимальную мощность на высококлассном, инновационном аппаратном обеспечении. Поскольку частично Linux связана со средой энтузиастов PC, особое значение в данной системе уделяется выполнению большего количества задач при меньших затратах.
Лекция № 8. ОПЕРАЦИОННЫЕ СИСТЕМЫ ФИРМЫ MICROSOFT
8.1. Операционная система DOS
DOS (дисковая операционная система) – одна из первых операционных систем, предназначенных для работы персональных компьютеров. Она состоит из следующих частей.
8.2. Windows NT
Windows NT (New Technology) – операционная система корпорации Microsoft для использования на мощных персональных компьютерах и серверах. Windows NT 4 (1996) (и все последующие модификации: Windows 2000 (2000), Windows XP (2002), Windows Server 2003 (2003), Windows Vista (2007)) – это нечто совсем иное, чем DOS. Хотя в этих операционных системах можно открыть окно сеанса DOS, они вовсе не являются оболочкой в традиционном понимании этого слова. Здесь речь может идти, скорее, об эмуляции DOS (для того чтобы все желающие могли поработать с привычным интерфейсом командной строки). В сеансе DOS Windows NT многие DOS-программы работать не будут. И символьного режима экрана, который в Windows 9x предшествует загрузке графической оболочки, вы здесь не увидите.
Для хранения параметров и загрузки драйверов Windows NT, как и Windows 9x, использует системный реестр. Файлов Config. sys, Autoexec. bat и .ini здесь нет вообще. Более того, модернизировать Windows 9х до Windows NT невозможно. При установке Windows NT все приложения придется устанавливать и настраивать заново. Windows NT может использовать файловую систему FAT, и поэтому вы можете загружать компьютер с DOS-диска и иметь полный доступ ко всем файлам. Однако некоторые из самых прогрессивных возможностей Windows NT обеспечиваются ее собственной файловой системой NTFS (NT File System). NTFS позволяет создавать на диске разделы объемом до 2 Тбайт (как и FAT 32), но, кроме этого, в нее встроены функции сжатия файлов, безопасности и аудита, необходимые при работе в сетевой среде. Установка операционной системы Windows NT начинается на диске FAT, но по желанию пользователя в конце установки данные на диске могут быть конвертированы в формат NTFS. Можно сделать это и позже, воспользовавшись утилитой Convert. ехе, поставляемой вместе с операционной системой. Преобразованный к системе NTFS раздел диска становится недоступным для других операционных систем. Чтобы вернуться в DOS, Windows 3.1 или Windows 9x, нужно удалить раздел NTFS, а вместо него создать раздел FAT. Windows 2000 можно устанавливать на диск с файловой системой FAT 32 и NTFS.
8.3. Принципы, лежащие в основе Window
В Windows API имеется множество как самых незаметных, так и значительных отличий от других API, таких как POSIX API, с которым знакомы программисты, работающие в UNIX и Linux. Многие системные ресурсы Windows представляются в виде объектов ядра (kernel objects), для идентификации и обращения к которым используются деск рипторы (handles). По смыслу эти дескрипторы аналогичны дескрипторам (descriptors) файлов и идентификаторам (ID) процессов в UNIX.
Любые манипуляции с объектами ядра осуществляются только с использованием Windows API. "Лазеек" для обхода этого правила нет. Подобная ор ганизация работы согласуется с принципами абстрагирования данных, ис пользуемыми в объектно-ориентированном программировании, хотя сама система Windows объектно-ориентированной не является.
К объектам относятся файлы, процессы, потоки, каналы межпроцессного взаимодействия, объекты отображения файлов, события и многое другое. Объекты имеют атрибуты защиты.
Windows – богатый возможностями и гибкий интерфейс. Во-первых, одни и те же или аналогичные задачи могут решаться с помощью сразу несколь ких функций; так, имеются вспомогательные функции (convenience func tions), полученные объединением часто встречающихся последовательно стей функциональных вызовов в одну функцию (к числу подобных функций принадлежит и функция CopyFile, используемая в одном из примеров далее). Во-вторых, функции часто имеют многочисленные параметры и флаги, многие из которых обычно игнорируются.
Windows предлагает многочисленные механизмы синхронизации и взаимо действия, обеспечивающие удовлетворение самых разнообразных запросов.
Базовой единицей выполнения в Windows является поток (thread). В одном процессе (process) могут выполняться один или несколько потоков.
Для функций Windows используются длинные описательные имена. Приве денные ниже в качестве примера имена функций иллюстрируют не только соглашения об использовании имен, но и многоликость функций Windows:
WaitForSingleObject WaitForSingleObjectEx WaitForMultipleObjects WaitNamedPipe
Существует также несколько соглашений, регулирующих порядок исполь зования имен типов:
Имена предопределенных типов данных, необходимых API, также являются описательными, и в них должны использоваться прописные буквы. К числу наиболее распространенных относятся следующие типы данных:
BOOL (определен как 32-битовый объект, предназначенный для хране ния одного логического значения),
HANDLE ,
DWORD (вездесущее 32-битовое целое без знака),
LPTSTR (указатель на строку, состоящую из 8- или 16-битовых символов) LPSECURITY_ATTRIBUTES.
С другими многочисленными типами данных будем знакомиться по ме ре изложения материала.
В именах предопределенных типов указателей операция * не используется, и они отражают дополнительные отличия между указателями раз личного типа, как, например, в случае типов LPTSTR (определен как TCHAR *) и LPCTSTR (определен как const TCHAR *). Тип TCHAR может обозначать как обычный символьный тип char, так и двухбайтовый тип wchar_t.
В отношении использования имен переменных, – по крайней мере, в про тотипах функций, – также имеются определенные соглашения. Так, имя lpszFileName соответствует "длинному указателю на строку, завершаю щуюся нулевым символом", которая содержит имя файла. Этот пример ил люстрирует применение так называемой "венгерской нотации", которой мы в данной книге, как правило, не стремимся придерживаться. Точно так же, dwAccess – двойное слово (32 бита), содержащее флаги прав доступа к файлу, где "dw" означает "double word" – "двойное слово".
Наконец, несмотря на то что оригинальный API Win32 с самого начала разра батывался как совершенно независимый интерфейс, он проектировался с учетом обеспечения обратной совместимости с API Winl6, входившим в состав Windows 3.1. Это привело к некоторым досадным с точки зрения программиста последст виям:
Лекция № 9. ВВЕДЕНИЕ В СИСТЕМНОЕ ПРОГРАММИРОВАНИЕ
9.1. Использование командной строки
В данной лекции приведены примеры коротких программ, реализующих простое последовательное копирование содержимого файла тремя различными способами:
Кроме того, что эти примеры дают возможность сопоставить между собой различные модели программирования, они также демонстрируют возможности и ограничения, присущие библиотеке С и Windows.
Последовательная обработка файлов является простейшей, наиболее распро страненной и самой важной из возможностей, обеспечиваемых любой операци онной системой, и почти в каждой большой программе хотя бы несколько файлов обязательно подвергаются этому виду обработки. Поэтому простая программа обработки файлов предоставляет прекрасную возможность ознако миться с Windows и принятыми в ней соглашениями.
Несмотря на концептуальную простоту последовательной обработки файлов, эффективная реализация этого процесса, обеспечивающая оптимальную ско рость его выполнения, может оказаться нелегкой задачей. Для этого может по требоваться использование перекрывающегося ввода/вывода, отображения файлов, потоков и других дополнительных методов.
Само по себе копирование файлов не представляет особого интереса, однако сравнение программ не только позволит вам быстро оценить, чем отличаются друг от друга различные системы, но и послужит хорошим предлогом для зна комства с Windows. В последующих примерах реализуется ограниченный вари ант одной из команд UNIX – ср, осуществляющей копирование одного файла в другой и требующей задания имен файлов в командной строке. В приведенных программах организована лишь простейшая проверка ошибок, которые могут возникать на стадии выполнения, а существующие файлы просто перезаписываются.
9.2. Копирование файла с использованием стандартной библиотеки
языка C
Как видно из текста программы 9.1, стандартная библиотека С поддерживает объекты потоков ввода/вывода FILE, которые напоминают, несмотря на мень шую общность, объекты Windows HANDLE, представленные в программе 9.2.
Программа 9.1. Копирование файлов с использованием библиотеки С
____________________________________________________________________
/* Программа копирования файлов cpC.
Реализация, использующая библиотеку C. */
/* срC файл1 файл2: Копировать файл1 в файл2. */
# include <stdio.h>
# include <errno.h>
# define BUF_SIZE 256
int main (int argc, char *argv [])
{
FILE *in_file, *out_file;
char rec [BUF_SIZE];
size_t bytes_in, bytes_out;
if (argc != 3) {
printf ("Использование: срС файл1 файл2\n");
return 1;
}
in_file = fopen (argv [1], "rb");
if (in_file == NULL) {
perror (argv [1]);
return 2;
}
out_file = fopen (argv [2], "wb"); if (out_file == NULL) {
perror (argv [2]);
return 3;
}
/* Обработать входной файл по одной записи за один раз.*/
while((bytes_in = fread (rec, 1, BUF_SIZE, in_file))>0) {
bytes_out = fwrite (rec, 1, bytes_in, out_file);
if (bytes_out != bytes_in) {
perror ("Неустранимая ошибка записи.");
return 4;
}
}
fclose (in_file);
fclose (out_file);
return 0;
}
Этот простой пример может служить наглядной иллюстрацией ряда общепринятых допущений и соглашений программирования, которые не всегда при меняются в Windows.
Преимуществом реализации, использующей библиотеку С, является ее пере носимость на платформы UNIX, Windows, а также другие системы, которые под держивают стандарт ANSI С. Кроме того, в том, что касается производительности, вариант, использующий функции вво да/вывода библиотеки С, ничуть не уступает другим вариантам реализации. Тем не менее, в этом случае программы вынуждены ограничиваться синхронными операциями ввода/вывода, хотя влияние этого ограничения будет несколько ослаблено использованием потоков Windows.
Как и их эквиваленты в UNIX, программы, основанные на функциях для рабо ты с файлами, входящих в библиотеку С, способны выполнять операции произ вольного доступа к файлам (с использованием функции fseek или, в случае тек стовых файлов, функций fsetpos и fgetpos), но это является уже потолком сложности для функций ввода/вывода стандартной библиотеки С, выше которо го они подняться не могут. Вместе с тем, Visual C++ предоставляет нестандартные расширения, способные, например, поддерживать блокирование файлов. Нако нец, библиотека С не позволяет управлять средствами защиты файлов.
Резюмируя, можно сделать вывод, что если простой синхронный файловый или консольный ввод/вывод – это все, что вам надо, то для написания перено симых программ, которые будут выполняться под управлением Windows, следует использовать библиотеку С.
9.3. Копирование файла с использованием Windows
В программе 9.2 решается та же задача копирования файлов, но делается это с помощью Windows API.
Программа 9.2. Копирование файлов с использованием Windows, первая реализация
_____________________________________________________________________
/* Программа копирования файлов cpW.
Реализация, использующая Windows.*/
/* cpW файл1 файл2: Копировать файл1 в файл2.*/
#include <windows.h>
#include <stdio.h>
#define BUF_SIZE 256
int main(int argc, LPTSTR argv[]) {
HANDLE hIn, hOut;
DWORD nIn, nOut;
CHAR Buffer [BUF_SIZE];
if(argc != 3) {
printf("Использование: cpW файл1 файл2\n");
return 1;
}
hIn = CreateFile(argv[1], GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL);
if (hIn==INVALID_HANDLE_VALUE) {
printf("Невозможно открыть входной файл. Ошибка: %x\n", GetLastError ());
return 2;
}
hOut = CreateFile (argv[2], GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if(hOut==INVALID_HANDLE_VALUE) {
printf("Невозможно открыть выходной файл. Ошибка: %x\n", GetLastError ());
return 3;
}
while(ReadFile(hIn, Buffer, BUF_SIZE, &nIn, NULL)&&nIn > 0) {
WriteFile (hOut, Buffer, nIn, &nOut, NULL);
if (nIn != nOut) {
printf("Неустранимая ошибка записи: %x\n", GetLastError ());
return 4;
}
}
CloseHandle (hIn);
CloseHandle (hOut);
return 0;
}
Этот простой пример иллюстрирует некоторые особенности программиро вания в среде Windows.
9.4. Копирование файла с использованием вспомогательной функции Windows
Для повышения удобства работы в Windows предусмотрено множество вспо могательных функций (convenience functions), которые, объединяя в себе не сколько других функций, обеспечивают выполнение часто встречающихся задач программирования. В некоторых случаях использование этих функций может приводить к повышению производительности. Например, благодаря применению функции CopyFile значительно упрощается программа копирования файлов (программа 9.3). Помимо всего прочего, это избавляет нас от необходимости заботиться о буфере, размер которого в двух предыдущих про граммах произвольно устанавливался равным 256.
Программа 9.3. Копирование файлов с использованием вспомогательной функции Windows
___________________________________________________________________
/* Программа копирования файлов cpCF.
Реализация, в которой для повышения удобства
использования и производительности программы
используется функция Windows CopyFile. */
/* cpCF файл1 файл2: Копировать файл1 в файл2. */
#include <windows.h> #include <stdio.h>
int main (int argc, LPTSTR argv[]) {
if (argc != 3) {
printf ("Использование: cpCF файл1 файл2\n");
return 1;
}
if(!CopyFile (argv[1], argv[2], FALSE)) {
printf("Ошибка при выполнении функции CopyFile: %x\n", GetLastError ());
return 2;
}
return 0;
}
Лекция № 10. ОПЕРАЦИИ ОТКРЫТИЯ, ЧТЕНИЯ, ЗАПИСИ И ЗАКРЫТИЯ ФАЙЛОВ
10.1. Создание и открытие файла
Первой функцией Windows, которую мы подробно опишем, является функция CreateFile, используемая как для создания новых, так и для открытия сущест вующих файлов. Для этой функции, как и для всех остальных, сначала приводит ся прототип, а затем обсуждаются соответствующие параметры и порядок рабо ты с ней.
Простейшее использование функции CreateFile иллюстрирует приведенный в предыдущей лекции пример ознакомительной Windows-программы (программа 9.2), содер жащей два вызова функций, в которых для параметров dwShareMode, lpSecurityAttributes и hTemplateFile были использованы значения по умолчанию. Параметр dwAccess может принимать значения GENERIC_READ и GENERIC_WRITE.
HANDLE CreareFile (
LPCTSTR lpName,
DWORD dwAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreate,
DWORD dwAttrsAndFlags,
HANDLE hTemplateFile)
Возвращаемое значение: в случае успешного выполнения – дескриптор открытого файла (типа HANDLE), иначе – INVALID_HANDLE_VALUE.
Имена параметров иллюстрируют некоторые соглашения Windows. Префикс dw используется в именах параметров типа DWORD (32-битовые целые без знака), в которых могут храниться флаги или числовые значения, например счетчики, тогда как префикс lpsz (длинный указатель на строку, завершающуюся нулем), или в упрощенной форме – lр, используется для строк, содержащих пути досту па, либо иных строковых значений, хотя документация Microsoft в этом отноше нии не всегда последовательна. В некоторых случаях для правильного определе ния типа данных вам придется обратиться к здравому смыслу или внимательно прочесть документацию.
lpName — указатель на строку с завершающим нулевым символом, содержащую имя файла, канала или любого другого именованного объекта, который необхо димо открыть или создать. Допустимое количество символов при указании путей доступа обычно ограничивается значением МАХ_РАТН (260), однако в Windows NT это ограничение можно обойти, поместив перед именем префикс \\?\, что обеспечивает возможность использования очень длинных имен (с числом сим волов вплоть до 32 К). Сам префикс в имя не входит. О типе данных LPCTSTR го ворится в одном из последующих разделов, а пока вам будет достаточно знать, что он относится к строковым данным.
dwAccess — определяет тип доступа к файлу — чтение или запись, что соответ ственно указывается флагами GENERIC_READ и GENERIC_WRITE. Ввиду отсутствия флаговых значений READ и WRITE использование префикса GENERIC_ может пока заться излишним, однако он необходим для совместимости с именами макросов, определенных в заголовочном файле Windows WINNT.H. Вы еще неоднократно столкнетесь с именами, которые кажутся длиннее, чем необходимо.
Указанные значения можно объединять операцией поразрядного "или" (I), и тогда для получения доступа к файлу как по чтению, так и по записи, следует вос пользоваться таким выражением:
GENERIC_READ | GENERIC_WRITE
dwShareMode — может объединять с помощью операции поразрядного "или" следующие значения:
0 — запрещает разделение (совместное использование) файла. Более того,
открытие второго дескриптора для данного файла запрещено даже в рам
ках одного и того же вызывающего процесса.
FILE_SHARE_READ — другим процессам, включая и тот, который осуществил
данный вызов функции, разрешается открывать этот файл для параллель
ного доступа по чтению.
FILE_SHARE_WRITE — разрешает параллельную запись в файл.
Используя блокирование файла или иные механизмы, программист должен самостоятельно позаботиться об обработке ситуаций, в которых осуществляются одновременно несколько попыток записи в одно и то же место в файле. Более подробно этот вопрос рассматривается в главе 3.
lpSecurityAttributes — указывает на структуру SECURITY_ATTRIBUTES. На первых порах при вызовах функции CreateFile и всех остальных функций вам будет достаточно использовать значение NULL; вопросы безопасности файловой системы рассматриваются в главе 15.
dwCreate — конкретизирует запрашиваемую операцию: создать новый файл, перезаписать существующий файл и тому подобное. Может принимать одно из приведенных ниже значений, которые могут объединяться при помощи опера ции поразрядного "или" языка С.
CREATE_NEW — создать новый файл; если указанный файл уже существует,
выполнение функции завершается неудачей.
CREATE_ALWAYS — создать новый файл; если указанный файл уже существу
ет, функция перезапишет его.
OPEN_E_XI STING — открыть файл; если указанный файл не существует, вы
полнение функции завершается неудачей.
OPEN_ALWAYS — открыть файл; если указанный файл не существует, функция
создаст его.
TRUNCATE_EXISTING — открыть файл; размер файла будет установлен рав
ным нулю. Уровень доступа к файлу, установленный параметром dwAccess,
должен быть не ниже GENERIC_WRITE. Если указанный файл существует, его
содержимое будет уничтожено. В отличие от случая CREATENEW выполне
ние функции будет успешным даже в тех случаях, когда указанный файл не
существует.
dwAttrsAndFlags — позволяет указать атрибуты файла и флаги. Всего имеется 16 флагов и атрибутов. Атрибуты являются характеристиками файла, а не откры того дескриптора, и игнорируются, если открывается существующий файл. Не которые из наиболее важных флаговых значений приводятся ниже.
FILE_ATTRIBUTE_NORMAL — этот атрибут можно использовать лишь при ус
ловии, что одновременно с ним не устанавливаются никакие другие атри
буты (тогда как для всех остальных флагов одновременная установка до
пускается).
FILE_ATTRIBUTE_READONLY — этот атрибут запрещает приложениям осуще
ствлять запись в данный файл или удалять его.
FILE_FLAG_DELETE_ON_CLOSE — этот флаг полезно применять в случае вре
менных файлов. Файл будет удален сразу же после закрытия последнего из
его открытых дескрипторов.
FILE_FLAG_OVERLAPPED — этот флаг играет важную роль при выполнении
операций асинхронного ввода/вывода, описанных в главе 14.
Кроме того, существует несколько дополнительных флагов, позволяющих уточнить способ обработки файла и облегчить реализации Windows оптимиза цию производительности и обеспечение целостности файлов.
• FILE_FLAG_WRITE_THROUGH — устанавливает режим сквозной записи проме
жуточных данных непосредственно в файл на диске, минуя кэш.
• FILE_FLAG_NO_BUFFERING — устанавливает режим отсутствия промежуточ-
i ной буферизации или кэширования, при котором обмен данными проис
ходит непосредственно с буферами данных программы, указанными при
вызове функций ReadFile или WriteFile (описаны далее). Соответственно
требуется, чтобы начала программных буферов совпадали с границами
секторов, а их размеры были кратными размеру сектора тома. Чтобы опре
делить размер сектора при указании этого флага, вы можете воспользо
ваться функцией GetDiskFreeSpace.
FILE_FLAG_RANDOM_ACCESS — предполагается открытие файла для произ
вольного доступа; Windows будет пытаться оптимизировать кэширование
файла применительно к этому виду доступа.
FILE_FLAG_SEQUENTIAL_SCAN — предполагается открытие файла для после
довательного доступа; Windows будет пытаться оптимизировать кэширова
ние файла применительно к этому виду доступа. Оба последних режима
реализуются системой лишь по мере возможностей.
hTemplateFile — дескриптор с правами доступа GENERIC_READ к шаблону фай ла, предоставляющему расширенные атрибуты, которые будут применены к соз даваемому файлу вместо атрибутов, указанных в параметре dwAttrsAndFlags. Обычно значение этого параметра устанавливается равным NULL. При открытии существующего файла параметр hTemplateFile игнорируется. Этот параметр
используется в тех случаях, когда требуется, чтобы атрибуты вновь создаваемого файла совпадали с атрибутами уже существующего файла.
Оба вызова функции CreateFile в программе 1.2 максимально упрощены за счет использования для параметров значений по умолчанию, и, тем не менее, они вполне справляются со своими задачами. В обоих случаях было бы целесооб разно использовать флаг FILE_FLAG_SEQUENTIAL_SCAN. (Эта возможность иссле дуется в упражнении 2.3, а соответствующие результаты тестирования произво дительности приведены в приложении В.)
Заметьте, что для данного файла могут быть одновременно открыты несколь ко дескрипторов, если только это разрешается атрибутами совместного доступа и защиты файла. Открытые дескрипторы могут принадлежать одному и тому же или различным процессам. (Управление процессами описано в главе 6).
В Windows Server 2003 предоставляется функция ReOpenFile, которая возвра щает новый дескриптор с иными флагами, правами доступа и прочим, нежели те, которые были указаны при первоначальном открытии файла, если только это не приводит к возникновению конфликта между новыми и прежними правами доступа.
Закрытие файла
Для закрытия объектов любого типа, объявления недействительными их де скрипторов и освобождения системных ресурсов почти во всех случаях исполь зуется одна и та же универсальная функция. Исключения из этого правила будут оговариваться отдельно. Закрытие дескриптора сопровождается уменьшением на единицу счетчика ссылок на объект, что делает возможным удаление таких не хранимых постоянно (nonpersistent) объектов, как временные файлы или собы тия. При выходе из программы система автоматически закрывает все открытые дескрипторы, однако лучше все же, чтобы программа самостоятельно закрывала свои дескрипторы перед тем, как завершить работу.
Попытки закрытия недействительных дескрипторов или повторного закры тия одного и того же дескриптора приводят к исключениям (исключения и обра ботка исключений обсуждаются в главе 4). Не только излишне, но и не следует закрывать дескрипторы стандартных устройств, которые обсуждаются в разделе "Стандартные устройства и консольный ввод/вывод" далее в этой главе.
BOOL CloseHandle (HANDLE hObject)
Возвращаемое значение: в случае успешного выполнения функции —
TRUE, иначе-FALSE.
Функции UNIX, сопоставимые с рассмотренными выше, отличаются от них в нескольких отношениях. Функция (системный вызов) UNIX open возвра щает целочисленный дескриптор (descriptor) файла, а не дескриптор типа HANDLE, причем для указания всех параметров доступа, разделения и созда ния файлов, а также атрибутов и флагов используется единственный цело численный параметр of lag. Возможные варианты выбора, доступные в обе их системах, перекрываются, однако набор опций, предлагаемый Windows, отличается большим разнообразием.
В UNIX отсутствует параметр, эквивалентный параметру dwShareMode. Фай лы UNIX всегда являются разделяемыми.
В обеих системах при создании файла используется информация, касающая ся его защиты. В UNIX для задания хорошо известных разрешений на доступ к файлу для владельца, членов группы и прочих пользователей используется аргумент mode.
Функция close, хотя ее и можно сопоставить с функцией CloseHandle, от личается от последней меньшей универсальностью.
Функции библиотеки С, описанные в заголовочном файле <stdio.h>, ис пользуют объекты FILE, которые можно поставить в соответствие дескрип торам (дисковые файлы, терминалы, ленточные устройства и тому подоб ные), связанным с потоками. Параметр mode функции fopen позволяет указать, должны ли содержащиеся в файле данные обрабатываться как дво ичные или как текстовые. Имеются также опции открытия файла в режиме "только чтение", обновления файла, присоединения к другому файлу и так далее. Функция f reopen обеспечивает возможность повторного использова ния объектов FILE без их предварительного закрытия. Средства для задания параметров защиты стандартной библиотекой С не предоставляются.
Для закрытия объектов типа FILE предназначена функция fclose. Имена большинства функций стандартной библиотеки С, предназначенных для ра боты с объектами FILE, снабжены префиксом "f".
Чтение файла
BOOL ReadFile ( HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped)
Возвращаемое значение: в случае успешного выполнения (которое счи тается таковым, даже если не был считан ни один байт из-за попытки чтения с выходом за пределы файла) — TRUE, иначе — FALSE.
Вплоть до главы 14 мы будем предполагать, что дескрипторы файлов создают ся без указания флага перекрывающегося ввода/вывода FILE_FLAG_OVERLAPPED в параметре dwAttrsAndFlags. В этом случае функция ReadFile начинает чтение с
текущей позиции указателя файла, и указатель файла сдвигается на число счи танных байтов.
Если значения дескриптора файла или иных параметров, используемых при вызове функции, оказались недействительными, возникает ошибка, и функция возвращает значение FALSE. Попытка выполнения чтения в ситуациях, когда ука затель файла позиционирован в конце файла, не приводит к ошибке; вместо это го количество считанных байтов (*lpNumberOfBytesRead) устанавливается рав ным 0.
Параметры
Описательные имена переменных и естественный порядок расположения па раметров во многом говорят сами за себя. Тем не менее, ниже приводятся неко торые краткие пояснения.
hFile — дескриптор считываемого файла, который должен быть создан с пра вами доступа GENERIC_READ. lpBuffer является указателем на буфер в памяти, куда помещаются считываемые данные. nNumberOfBytesToRead — количество байт, которые должны быть считаны из файла.
lpNumberOfBytesRead — указатель на переменную, предназначенную для хра нения числа байт, которые были фактически считаны в результате вызова функ ции ReadFile. Этот параметр может принимать нулевое значение, если перед выполнением чтения указатель файла был позиционирован в конце файла или если во время чтения возникли ошибки, а также после чтения из именованного канала, работающего в режиме обмена сообщениями (глава 11), если переданное сообщение имеет нулевую длину.
lpOverlapped — указатель на структуру OVERLAPPED (главы 3 и 14). На данном этапе просто устанавливайте значение этого параметра равным NULL.
Запись в файл
BOOL WriteFile ( HANDLE hFile, LPCVOID lpBuffer, DWORD nNumberOfBytesToWrite, LPDWORD lpNumberOfBytesWritten, LPOVERLAPPED lpOverlapped)
Возвращаемое значение: в случае успешного выполнения — TRUE, ина че-FALSE.
Все параметры этой функции вам уже знакомы. Заметьте, что успешное вы полнение записи еще не говорит о том, что данные действительно оказались за писанными на диск, если только при создании файла с помощью функции Сге-ateFile не был использован флаг FILE_FLAG_WRITE_THROUGH. Если во время
вызова функции указатель файла был позиционирован в конце файла, Windows увеличит длину существующего файла.
Функции ReadFileGather и WriteFileGather позволяют выполнять операции чтения и записи с использованием набора буферов различного размера.
OS/2
(1987-2002)
MVS
(1972-)
VM/CMS
(1972-)
OS/360
(1966-1972)
BeOS
(1993-2001)
MacOS
(1984-2003)
Windows
(1991-2002)
MS-DOS
(1981-2001)
CP/M
(1976-1988)
Windows NT
(1993-)
VMS
(1978-)
TOPS-10
(1961-1965)
DTSS
(1961-1965)
MULTICS
(1965-1996)
UNIX
(1969-)
IBM
MacOS
CP/M
DEC
Unix
1960
1965
1970
1975
1980
1985
1990
1995
Linux
(1991-)
Параллельно
разделяемые
Одновременно
разделяемые
Неделимые
Делимые
Ресурсы