В своем развитии осрв строились на основе следующих архитектур.[1]

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

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

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

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

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

Повышенная отказоустойчивость, т. к. «зависший» сервис может быть перезапущен без перезагрузки системы.

Ядро операционной системы

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

Основные сервисы

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

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

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

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

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

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

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

Отличия от операционных систем общего назначения

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

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

Планировщик задач (сервис)

Большинство ОСРВ выполняют планирование задач, руководствуясь следующей схемой. Каждой задаче в приложении ставится в соответствие некоторый приоритет. Чем больше приоритет, тем выше должна быть реактивность задачи. Высокая реактивность достигается путем реализации подхода приоритетного вытесняющего планирования (preemptive priority scheduling), суть которого заключается в том, что планировщику разрешается останавливать выполнение любой задачи в произвольный момент времени, если установлено, что другая задача должна быть запущена незамедлительно.

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

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

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

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

Устанавливает, какая задача должна запускаться следующей.

Сохраняет контекст остановленной задачи (чтобы она потом возобновила работу с места останова)

Устанавливает контекст для следующей задачи.

Запускает эту задачу.

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

Выполнение задачи

В обычных ОСРВ задача может находиться в 3-х возможных состояниях:

Задача выполняется;

Задача готова к выполнению;

Задача заблокирована.

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

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

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

Алгоритмы планирования

В настоящее время для решения задачи эффективного планирования в ОСРВ наиболее интенсивно развиваются два подхода.[11]

Статические алгоритмы планирования (RMS — Rate Monotonic Scheduling). Используют приоритетное вытесняющее планирование. Приоритет присваивается каждой задаче до того, как она начала выполняться. Преимущество отдается задачам с самыми короткими периодами выполнения.

Динамические алгоритмы планирования (EDF — Earliest Deadline First Scheduling). Приоритет задачам присваивается динамически, причем предпочтение отдается задачам с наиболее ранним предельным временем начала (завершения) выполнения.

При больших загрузках системы EDF более эффективен, нежели RMS.

Взаимодействие между задачами и разделение ресурсов

Многозадачным системам необходимо распределять доступ к ресурсам. Одновременный доступ двух и более процессов к какой либо области памяти или другим ресурсам представляет определённую угрозу. Существует 3 способа решения этой проблемы[10]

Временное блокирование прерываний

Двоичные семафоры

Посылка сигналов

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

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

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

Выделение памяти

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

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

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

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

Также этот алгоритм отлично функционирует и в настольных системах, особенно тогда, когда во время обработки участка памяти одним ядром следующий участок памяти обрабатывается другим ядром. Такие оптимизированные для настольных систем ОСРВ как Unison Operating System или DSPnano RTOS предоставляют указанную возможность.

ОС RT-11

RT-11 (RT от Real time (в режиме реального времени) — небольшая однопользовательская операционная система реального времени фирмы DEC для 16-битных компьютеров серии PDP-11. Впервые была запущена в 1970 году и широко использовалась для систем реального времени, управления процессами и сбора данных.

Системы RT-11 не поддерживали вытесняющую многозадачность, но большинство версий позволяло запускать несколько приложений одновременно. Все варианты программы-монитора предоставляли возможность запускать «фоновую задачу», мониторы FB, XM и ZM также предоставляли «задачу переднего плана» (Foreground Job), а также небольшое число «системных задач».

Исходный код — RT-11 была написана на языке ассемблера. Интенсивное использование условной компиляции и макро-программирования ассемблера MACRO-11, предоставляли значительную степень конфигурируемости.

Драйвера устройств — В ранних версиях RT-11, драйвера устройств встраивались в ядро на этапе конфигурирования системы, в более поздних версиях драйвера стали подгружаемыми. Поскольку RT-11 часто использовалась для управления устройствами и сбора данных, разработчики часто писали новые драйвера устройств или улучшали существующие, и DEC поощряла такую разработку, делая свои аппаратные подсистемы открытыми, поддерживая сторонних разработчиков аппаратуры и ПО, и поощряя Сообщество пользователей DEC (DIGITAL Equipment Corporation Users Society).

Файловая система — RT-11 имела простейшую двухуровневую (том/файл) файловую систему с непрерывными (односегментными) файлами, что требовало периодической дефрагментации дискового пространства. Многоуровневость файловой системы обычно реализовывалась при помощи виртуальных дисков (файловая система монтируемых томов реализовывалась в обычном файле или файле другого виртуального диска).

Программное обеспечение — RT-11 поставлялась с целым рядом сервисных программ. Утилиты DIR, DUP, PIP и FORMAT позволяли управлять дисками и каталогами. Редакторы TECO, EDIT и визуальные редакторы давали возможность создавать и редактировать файлы с исходным кодом и данными. MACRO, LINK и LIBR позволяли создавать свои исполняемые файлы. ODT, VDT и SD — отлаживать программы. И наконец, программа VTCOM позволяла связываться с другой системой посредством телефонной линии и модема.

Известные версии

V5.x — В этой версии ОС сделано очень много нового, что обусловило её широкое распространение. Версия 5.0 после своего появления на свет практически мгновенно вытеснила все предыдущие.

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

Данная версия ОС получила наиболее широкое распространение. На её базе в СССР были сделаны многочисленные клоны. Наиболее известным клоном являлась ОС РАФОС, предназначенная для машин СМ ЭВМ.

Операционная система ОС2000

ос2000 («ОС РВ Багет» и «Багет 2.0») — операционная система реального времени (ОСРВ), разработанная НИИСИ РАН для ЭВМ серии «Багет» на микропроцессорах MIPS и Intel.

ос2000 предназначена для разработки программного обеспечения для систем (программно-аппаратных комплексов), работающих в режиме жёсткого реального времени.

Разработка ос2000 базируется на следующих принципах:

-соответствие международным стандартам,

-мобильность,

-масштабируемость,

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

-использование объектно-ориентированного подхода,

Поддержка устройств

-сетевые устройства Ethernet (протоколы NFS, FTP, Telnet), для Intel-версии поддержка

ограничена ISA- и PCI-картами фирмы Realtek, NE2000-совместимых карт.

-накопительные устройства — флоппи- и жёсткие диски (файловые системы vfat и tar)

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

-POSIX 1003.1, стандарт на мобильные операционные системы (программный интерфейс);

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

-графическая подсистема X Window System (клиент-сервер)

Windows CE

Windows CE (она же WinCE) — это вариант операционной системы Microsoft Windows для наладонных компьютеров, мобильных телефонов и встраиваемых систем. Windows CE не является «урезанной» версией Windows для настольных ПК, она основана на совершенно другом ядре. Поддерживаются архитектуры x86, MIPS, ARM и процессоры Hitachi SuperH.

Windows CE оптимизирована для устройств, имеющих минимальный объём памяти: ядро Windows CE может работать на 32 КБ памяти. С графическим интерфейсом (GWES) для работы Windows CE понадобится от 5 МБ. Устройства часто не имеют дисковой памяти и могут быть сконструированы как «закрытые» устройства, без возможности расширения пользователем (например, ОС может быть «зашита» в ПЗУ). Windows CE соответствует определению операционной системы реального времени.

На базе Windows CE основано множество платформ, включая Handheld PC, Palm-size PC, Pocket PC, Pocket PC 2002, Pocket PC 2003, Pocket PC 2003 SE, Smartphone 2002, Smartphone 2003, Windows Mobile, Meizu OS, а также множество промышленных устройств и встроенных систем. Приставка Sega Dreamcast имела поддержку Windows CE. Самой Windows CE в изначальной поставке не было, но она могла запускаться на приставке с CD. Некоторые игры использовали данную возможность.

Системы виртуальных машин(СВМ)

СВМ (VM, и её ранняя версия CP/CMS) — первая система, в которой была реализована технология виртуальных машин. Виртуализация в СВМ была последовательной и полной, в частности, на виртуальной машине можно было запустить другую копию системы СВМ, и так далее. Более того, запуск СВМ на виртуальной машине СВМ был рекомендованным методом генерации новой версии системы для установки. В частности, это означало, что любое реальное устройство ЭВМ могло быть тем или иным методом представлено в виде виртуального устройства на виртуальной машине. До сих пор ни одна другая реализация виртуальных машин не обладает таким свойством.

Статус СВМ

Система виртуальных машин в социалистическом лагере была впервые адаптирована в версии 1 предприятием «Роботрон» (ГДР), а затем, с версии 2, развивалась НИИЭВМ (Минск). Благодаря активности НИИЭВМ, СВМ рассматривалась в СССР как один из основных компонентов системного программного обеспечения ЕС ЭВМ и впоследствии стала основой версии 7 ОС ЕС, предлагавшейся в качестве штатного варианта для применения на системах ЕС ЭВМ Ряд-3 и выше. Наибольшее распространение в СССР получили версии СВМ 3 и 4. Версия 5 была выпущена уже в период распада СССР и массового отказа от использования оборудования ЕС ЭВМ, в связи с чем не получила широкого распространения, а под названием «СВМ версия 6» минские специалисты выпустили пакет программ для VM, обеспечивающий её максимальную совместимость с приложениями СВМ.

С другой стороны, по причинам, не имеющим рационального объяснения, фирма IBM никогда не поощряла использование своей операционной системы VM, и VM всегда позиционировалась маркетингом IBM на вторых ролях по отношению к другим операционным системам мэйнфреймов — MVS, OS и даже DOS, гораздо менее технологичным и дружественным к пользователю. Скорее всего, низкий бюджет разработки VM как первоначально экспериментального проекта не позволил финансовому руководству IBM признать её равной тем системам, на которые было затрачено гораздо больше средств.

Архитектура СВМ

Архитектурно СВМ состояла из нескольких независимых компонентов. Центральным компонентом был монитор виртуальных машин (МВМ, IBM-овское название — CP, Control Program), который управлял аппаратурой реальной ЭВМ и реализовывал набор виртуальных машин с заданной конфигурацией. Остальные компоненты представляли собой операционные системы или системонезависимые программы виртуальных машин, работавшие под управлением МВМ: подсистема диалоговой обработки (ПДО), подсистема сетевой передачи файлов (ПСП), подсистема логической коммутации абонентских пунктов (ПЛК), подсистема анализа дампов (ПАД), подсистема дистанционной передачи файлов (ПДП), подсистема контроля технических средств (ПКТ), средства генерации и обслуживания (СГО).

Подсистема Диалоговой Обработки (ПДО)

ПДО (Подсистема Диалоговой Обработки, IBMовское название — CMS, Conversational Monitor System, ранее Cambridge Monitor System; обратный перевод на английский — PTS, Programming and Testing System) представляла собой основную операционную систему виртуальной машины в СВМ, в которой осуществлялась работа пользователей. ПДО предоставляла пользователю диалоговый интерфейс, фактически работа пользователя за терминалом в ПДО на виртуальной машине напоминала работу на персональном компьютере. Это был очень серьёзный шаг вперёд по сравнению с более ранними операционными системами ЕС ЭВМ, диалоговые возможности которых либо полностью отсутствовали, либо были очень ограниченны.

Служебные подсистемы

Подсистемы ПСП, ПЛК, ПАД, ПДП, ПКТ, СГО были предназначены для задач обслуживания системы и прикладными программистами и пользователями не использовались.

Гостевые ОС

Кроме того, на виртуальной машине СВМ можно было запускать любую операционную систему ЕС ЭВМ, предназначенную для работы на реальном «железе» (так называемые гостевые ОС) — ОС ЕС, ДОС ЕС, МОС ЕС, МВС и т. д. В составе ОС ЕС версии 7 была разработана специальная операционная система БОС, функционально эквивалентная ОС ЕС версии 6 (SVS), но предназначенная специально для работы на виртуальной машине СВМ. БОС, в отличие от подавляющего большинства других системных средств ЕС ЭВМ, являлась самостоятельной разработкой советских программистов, независимой от фирмы IBM. Так как ОС ЕС являлась пакетной системой, пользователи ПДО могли передавать в неё подготовленные пакеты заданий и получать результаты при помощи виртуального перфоратора и виртуального АЦПУ.

Производительность монитора виртуальных машин

Монитор виртуальных машин теоретически позволял поддерживать до 10000 виртуальных машин на одной реальной системе. На практике количество одновременно активных виртуальных машин ограничивалось производительностью ЭВМ и могло достигать нескольких десятков.

В ЕС ЭВМ Ряд-3 и выше были реализованы средства микропрограммной поддержки СВМ.

Учёт времени

Архитектура СВМ позволяла естественным образом организовать учёт использования машинного времени, что было весьма актуально для дорогих в эксплуатации многопользовательских систем. Команда МВМ QUERY TIME, доступная пользователю виртуальной машины, позволяла узнать текущие дату и время, а также общую величину процессорного времени реального и виртуального процессоров, использованного в текущем сеансе работы виртуальной машины. Пользовался популярностью нехитрый скрипт на языке REXX, который при выходе из системы выдавал такую команду, умножал полученный результат на стоимость машинного времени системы и сообщал пользователю итоговую сумму, в которую обошлась его работа для эксплуатирующей ЭВМ организации. Для программиста, не занимавшего процессор интенсивными расчётами, а выполнявшего обычную разработку и отладку программ, на ЕС-1066 типичная стоимость машинного времени составляла порядка 10 рублей за рабочий день (то есть примерно была равна заработной плате). Ресурсоёмкие программы при эксплуатации могли использовать на порядки больше процессорного времени. Конечно, программисты в СССР не платили за машинное время из своего кармана, но из этой цифры видно, что труд программистов по оптимизации кода окупался в то время очень быстро.

Совместимость с ОС ЕС

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

Разделяемые сегменты

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

Работа с файлами в ПДО

В отличие от систем ДОС ЕС, ОС ЕС и МВС, предоставлявших очень громоздкую и неудобную для повседневного использования систему управления файлами (точнее, в их терминологии, наборами данных), в ПДО была реализована концепция так называемых минидисков с возможностью использования собственной файловой системы. Минидиск представлял собой виртуальное дисковое устройство, эмулируемое МВМ. Минидиск можно было отформатировать в файловой системе ПДО, в таком случае он содержал единый каталог файлов. Идентификатор файла состоял из имени файла (до 8 символов), расширения (до 8 символов) и режима файла (1 буква диска и 1 цифра режима доступа). Компоненты имени разделялись пробелом, режим файла можно было опускать целиком или указывать только букву диска. Например, файл с именем PROFILE EXEC A1 — файл автозагрузки системы ПДО типа EXEC (на одном из скриптовых языков) на основном пользовательском минидиске A, с обычным режимом доступа 1.

Структура файлов ПДО соответствовала структуре наборов данных ОС ЕС (за исключением наиболее сложных типов наборов данных), то есть каждый файл разбивался на записи определённого формата и длины. Основным форматом текстовых файлов в ПДО был формат F(80), то есть образ виртуальной колоды 80-колоночных перфокарт.

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

В целях совместимости с ДОС ЕС, ОС ЕС и МВС, в ПДО преимущественно использовался механизм внешней ассоциации файлов, заимствованный из этих систем. Хотя программа в ПДО могла открыть файл на диске непосредственно по его имени, фактически так были устроены только немногочисленные системные программы типа файловых утилит, текстового редактора и т. п. Штатным механизмом для прикладных программ было ассоциирование файла на диске (или устройства) с именем файла в программе при помощи команды FILEDEF, выдаваемой перед выполнением программы (аналог оператора DD в языке JCL для ДОС, ОС и МВС). Например, команда FILEDEF SYSPRINT DISK TEST LISTING означала, что системный вывод (SYSPRINT) следующих за ней программ следует записывать в файл на минидиске ПДО с именем TEST LISTING (и подразумеваемым режимом A1).

Усечения и аббревиатуры

Для удобства диалоговой работы в СВМ в большинстве команд МВМ, ПДО и системных программ, а также в некоторых операндах команд допускалось использование усечений и аббревиатур. Например, слово READER могло вводиться в виде одного из усечений READER, READE, READ, REA, RE, R или в виде аббревиатуры RDR. Более часто используемые команды и операнды имели более короткие усечения, вплоть до одной буквы, более редко используемые — более длинные. В описании синтаксиса обязательная часть усечения выделялась большими буквами или подчёркивалась, например: READER | RDR.

Редактор XEDIT

Экран текстового редактора XEDIT в ПДО СВМ, получен на эмуляторе «ЕСли» в системе «Букет»

Экран текстового редактора THE в Mac OS X

Начиная с СВМ версии 3, в ПДО применялся очень развитый текстовый редактор XEDIT, который, в частности, полностью управлялся на языке REXX. С помощью скриптов на REXX для XEDITа реализовывались многие сложные системы, такие, например, как системы коллективного управления версиями программ. Впоследствии клоны XEDITа (KEDIT, SEDIT, THE) были реализованы в различных операционных системах персональных компьютеров, но не очень прижились, так как идеология XEDIT в значительной степени была ориентирована на особенности работы с терминалом мэйнфрейма. Редактор THE (The Hessling Editor) в настоящее время распространяется под лицензией GPL для платформ Unix, z/OS, MS-DOS, OS/2, Windows, QNX, Amiga, BeOS, Mac OS X. Интересно, что распространением версии THE для z/OS занимается сама фирма IBM.

Электронная почта

В составе ПДО поставлялись программы для работы с электронной почтой. Обычно электронная почта работала между пользователями одной реальной ЭВМ (для старших моделей ЕС ЭВМ это могли быть сотни пользователей за терминалами в радиусе нескольких километров), но, при использовании телекоммуникационных средств, бывших в те времена ещё диковиной, различные машины могли объединяться в сеть. Также была реализована система мгновенной передачи коротких сообщений между пользователями.

Системы программирования и язык REXX

Основными средствами программирования для ПДО были скриптовые языки REXX и более ранние EXEC и EXEC2, ассемблер, компиляторы с языков ПЛ/1, Фортран, Кобол. Также для ПДО было реализовано множество других систем программирования, таких как Паскаль, Си, Лисп, система символьных вычислений REDUCE и т. д.

Интерпретатор языка REXX был впервые включён в состав ПДО в СВМ версии 3. Язык REXX получил впоследствии широкое распространение в операционной системе OS/2 и был реализован также для многих других операционных систем. В СВМ популярность REXX среди пользователей была более ограничена, чем в OS/2, так как скриптовый язык предыдущих версий ПДО, EXEC2, обеспечивал достаточно широкие возможности, и необходимость в использовании более сложного языка REXX возникала реже, в то время как в OS/2 единственной альтернативой REXXу был крайне ограниченный язык bat (cmd) файлов.

Литература

Тимонин В. И. СВМ ЕС: Основы функционирования и средства обеспечения пользователя. — М.: Изд-во МАИ, 1990. — 232 с.: ил. ISBN 5-7035-0157-1

Система виртуальных машин для ЕС ЭВМ: Справочник/И. М. Булко, Н. Н. Дорожко, Л. И. Дудкин и др.; Под ред. Э. В. Ковалевича. — М.: Финансы и статистика, 1985. — 360 с.

Пекер Ф. Л., Морозов Б. А. Прикладное программирование в системе виртуальных машин ЕС ЭВМ: Справочное пособие. — Минск: Вышэйшая школа, 1989. — 208 с.: ил. ISBN 5-339-00213-6

Потапов В. И., Денщиков А. В., Шкода О. Б. Работа в системе виртуальных машин ОС ЕС/Под ред. В. Н. Лебедева. — М.: Финансы и статистика, 1988. — 253 с.: ил. ISBN 5-279-00117-1

28