Исследования и разработки в области операционных систем. Открытый стандарт для операционных систем

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

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

1. ОС UNIX и стандарты Открытых Систем

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

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

1.2 UNIX System V 4.x и опирающиеся на него операционные системы

Канонические исходные тексты ОС UNIX, как известно, были написаны сотрудниками телефонной компании AT&T, и долгое время авторские права, равно как и права на продажу лицензий на использование исходных текстов принадлежали этой компании. В дальнейшем, по причине технических сложностей с разработкой и сопровождением сложного программного продукта и некоторых юридических затруднений компания AT&T образовала дочернюю компанию USL (UNIX System Laboratories) с основной задачей развития и сопровождения исходных текстов ОС UNIX.

Именно USL выпустила вариант ОС UNIX System V 4.0, который стал фактическим стандартом операционной системы UNIX и явился основой многочисленных версий ОС UNIX, производимых поставщиками рабочих станций и серверов. Последним успехом USL как дочерней компании AT&T явился выпуска SVR 4.2. Помимо прочего, в этой ОС был впервые в истории UNIX реализован механизм легковесных процессов (threads), работающих на общей виртуальной памяти и позволяющих использовать аппаратные возможности так называемых "симметричных мультипроцессорных архитектур", в которых несколько процессоров имеют равноправный доступ к общей оперативной памяти.

В 1993 г. компания USL была поглощена компанией Novell, и в настоящее время фактически является подразделением этой компании. При этом владение торговой маркой UNIX было передано консорциуму X/Open. В 1994 г. USL в составе Novell была почти незаметна; видимо, сказывались необходимые структурные, организационные и маркетинговые преобразования. Однако в начале 1995 г. компания Novell объявила о выпуске нового варианта своей ОС UnixWare 2.0, основанного на System V 4.2, что свидельствует о завершении процесса внедрения USL в Novell.

1.2.1 UnixWare компании Novell

Компания Novell приобрела широкую известность и заработала основной капитал на рынке локальных сетей персональных ЭВМ. Распространенная "сетевая" ОС NetWare на самом деле всего лишь обеспечивает сетевой доступ персональных компьютеров, работающих под управлением MS-DOS, к ресурсам серверов (главным образом, файловых). Возрастающие возможности компьютеров, основанных на процессорах компании Intel, их фактический переход из класса персональных компьютеров в класс развитых рабочих станций, недостаточные возможности ОС типа MS-DOS для эффективного использования этих компьютеров заставили компанию Novell обратить внимание на операционную систему UNIX.

Первая версия системы под названием UnixWare целиком основывалась на SVR 4.0, но включала ряд расширений, специфичных для Novell. Следует отметить, что многие пользователи этой системы были не слишком ей довольны: она была не очень надежна и сложно администрировалась. В начале 1995 г. появился релиз UnixWare 2.0, основанный на SVR 4.2. По отзывам пользователей эта система гораздо более продвинута. В частности, обеспечивается полный графический интерфейс администратора, файловая система очень надежна, допускается доступ к файлам, хранимым на серверах NetWare и т.д. В конце 1995 г. компания Novell обещает выпустить новый продукт, который будет основываться на UNIX, но при этом будет поддерживать все функции NetWare.

1.2.2 Solaris компании Sun Microsystems

Известно, что в течении многих лет основой операционных систем (SunOS) компании Sun являлся UNIX BSD. Однако, начиная с SunOS 4.0, произошел полный переход на System V 4.0. Это связано, прежде всего, с тем, что SVR 4.0 включает функциональные возможности UNIX линии BSD.

Sun Microsystems внесла ряд существенных расширений в SVR 4.0. Прежде всего это касается обеспечения распараллеливания программ при использовании симметричных мультипроцессорных компьютеров (механизм потоков управления - threads). В SVR 4.0 этот механизм отсутствовал (он появился только в SVR 4.2), а компания Sun уже активно выпускала мультипроцессорные компьютеры. Поэтому в SunOS был реализован собственный механизм threads, что потребовало многочисленных переделок в ядре системы.

Solaris является внешней оболочкой SunOS и дополнительно включает средства графического пользовательского интерфейса и высокоуровневые средства сетевого взаимодействия (в частности, средства вызова удаленных процедур - RPC). Заметим, что хотя самая первая реализация механизма RPC принадлежит компании Xerox, именно реализация Sun стала фактическим стандартом и лицензирована многими компаниями.

1.2.3 HP/UX компании Hewlett-Parkard, DG/UX компании Data General, AIX компании IBM

HP/UX, DG/UX и AIX обладают многими отличиями. В частности, в этих версиях ОС UNIX поддерживаются разные средства генерации графических пользовательских интерфейсов (хотя все они основаны на использовании оконной системы X), по-разному реализованы threads и т.д.

Однако все эти системы объединяет тот факт, что в основе каждой из них находится SVR 4.x. Поэтому основной набор системных и библиотечных вызовов в этих реализациях совпадает.

Заметим, что в компании IBM существовал план разработки полностью самостоятельной реализации AIX на основе микроядра. Однако в последнее время IBM отказалась от этой идее, хотя собственное микроядро (новая реализация микроядра Mach) уже было создано.

1.3 Santa Cruz Operation и SCO UNIX

Варианты ОС UNIX, производимые компанией SCO и предназначенные исключительно для использования на Intel-платформах, до сих пор базируются на лицензированных исходных текстах System V 3.2. Однако SCO довела свои продукты до уровня полной совместимости со всеми основными стандартами (в тех позициях, для которых существуют стандарты).

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

Тем не менее, SCO имеет соглашение с французской компанией Chorus Systems о разработки новой версии SCO UNIX, базирующегося на микроядре Chorus и предназначенного для использования в системах реального времени.

1.4 Open Software Foundation и OSF-1

OSF была первой коммерческой компанией, решившейся на полную реализацию ОС UNIX на базе микроядра Mach. Результатом этой работы явилось создание ОС OSF-1. Как утверждают, OSF-1 на самом деле не является полностью лицензионно чистой системой: в ней используется часть исходных текстов SVR 4.0.

На сегодняшний день наиболее серьезным потребителем OSF-1 является компания Digital Equipment на своих платформах, основанных на микропроцессорах Alpha. В OSF-1 поддерживаются все основные стандарты ОС UNIX, хотя многие утверждают, что пока система работает не очень устойчиво.

1.5 Berkeley Standard Distribution, Free BSD, BSD Net и т.д.

Многие годы варианты ОС UNIX, разработанные в Калифорнийском университете г. Беркли, являлись реальной альтернативой AT&T UNIX. Например, ОС UNIX BSD 4.2 была бесплатно доступна в исходных текстах и достаточно широко использовалась даже в нашей стране на оригинальных и воспроизведенных машинах линии DEC. BSD 4.3 являлась основой популярной ОС Ultrix компании DEC. UNIX BSD использовался в SunOS. И т.д.

Группа BSD оказала огромное влияние на общее развитие ОС UNIX. До появления SVR 4.0 проблемой для пользователей являлась несовместимость наборов системных вызовов BSD и System V. Как мы отмечали выше, в SVR 4.0 был реализован общий набор системных вызовов.

Около 5 лет назад в Беркли была начата работа над микроядерной реализацией BSD 4.4. Работа была уже близка к завершению, когда компания USL, являвшаяся в то время владельцем исходных текстов System V, подала в суд на университет Беркли, мотивируя это тем, что в BSD 4.4 нелегально используются части исходных текстов SVR 4.0. Процесс продолжался около двух лет и закончился победой Беркли, хотя в то же время было выставлено условие произвести полную очистку текстов BSD от следов System V. Все это, естественно, затормозило выпуск BSD 4.4, полный вариант которой до сих пор недоступен.

Несколько лет назад группа BSD разделилась на коммерческую и некоммерческую части. Новая коммерческая компания получила название BSDI. Обе подгруппы выпустили варианты ОС UNIX для Intel-платформ под названиями 386BSD и BSD386, причем коммерческий вариант был гораздо более полным.

Сегодня популярен новый свободно распространяемый вариант ОС UNIX, называемый FreeBSD. Ведутся работы над более развитыми версиями BSDNet.

1.6 Torvald Linus и LINUX

LINUX - это оригинальная реализация ОС UNIX для Intel-платформ, выполненная молодым сотрудником университета Хельсинки Торвальдом Линусом. По непроверенным слухам совсем недавно появилась версия LINUX для PowerPC.

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

1.7 POSIX, XPG и т.д.

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

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

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

1.7.1 System V Interface Definition (SVID)

Одним из наиболее ранних стандартов де-факто ОС UNIX явился изданный UNIX System Laboratories (USL) одновременно с выпуском версии ОС UNIX System V Release 4 документ System V Interface Definition (SVID). Если кратко напомнить историю, то владельцем оригинальных исходных текстов ОС UNIX являлась компания AT&T Bell Laboratories (именно работники этой компании Ричи, Томпсон и Керниган разработали в начале 1970-х самый первый мобильный вариант ОС UNIX). В 1980-е годы компания AT&T основала дочернюю компанию USL, которой были переданы права на исходные тексты и торговую марку ОС UNIX. USL выпустила системы с System V R.4.0 до System V R.4.2, после чего в конце 1993 г. была поглощена компанией Novell, которая теперь является владельцем исходных текстов ОС UNIX (под давлением общественности торговая марка "UNIX" была передана компании X/Open).

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

1.7.2 Деятельность комитетов POSIX

Следует вспомнить, что наряду с версиями ОС UNIX, развивавшимися в компании AT&T (затем в USL, а теперь - в Novell), исторически существовало еще направление BSD (Berkeley Standard Distribution), успешно поддерживавшееся небольшой, но всемирно известной группой из университета г. Беркли (шт. Калифорния). В свое время (в конце 1970-х) университет получил из AT&T исходные тексты 16-разрядной ОС UNIX, на основе которых была произведена 32-разрядная система, которая сначала использовалась на компьютерах семейства VAX, а затем была перенесена на многие другие аппаратные платформы. В результате наборы системных вызовов UNIX AT&T и BSD стали значительно различаться.

Хотя большинство коммерческих реализаций UNIX основывалось на System V, UNIX BSD всегда был популярен в университетах, и общественность потребовала определения некоторого интерфейса, который являлся бы по сути объединением средств AT&T и BSD. Эта работа была начата Ассоциаций профессиональных программистов Открытых Систем UniForum, а затем продолжена в специально созданных рабочих группах POSIX (Portable Operating System Interface). В рабочих группах POSIX разрабатываются многие стандарты открытых систем, но наиболее известным и авторитетным является принятый ISO по представлению IEEE стандарт POSIX 1003.1, в котором определены минимальные требуемые средства операционной системы (по сути дела, UNIX).

1.7.3 Деятельность X/Open

Международная организация X/Open, которая выполняет многие работы, связанные с пропагандой и анализом использования открытых систем, кроме того, собирает и систематизирует де-юре и де-факто стандарты, имеющие промышленное значение, в так называемом X/Open Common Application Environment (CAE). Спецификаций интерфейсов средств, входящих в CAE, публикуются в многотомном документе X/Open Portability Guide (XPG).

1.7.4 Стандарт ANSI C

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

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

Имеется другая разновидность стандартов де-факто, распространяемых на некоторый класс аппаратных архитектур. Примером такого стандарта может служить документ, принятый международной организацией SPARC International документ SPARC Complience Definition, содержащий машинно-зависимые уточнения к машинно-независимым спецификациям интерфейсов. Аналогичный документ разрабатывался организацией 88/Open, связанной с RISC-процессорами фирмы Motorola.

Среди других индустриальных де-факто стандартов для современных вариантов ОС UNIX наиболее важны фактический стандарт оконной системы, поддерживаемый X Cosortium, в основе которого находится лаборатория Массачусетского технологического института (MIT), являющаяся разработчиком системы X, а также спецификации интерфейсов инструментального средства разработки графических пользовательских интерфейсов OSF/Motif, разработанные в Open Software Foundation (OSF).

Заметим, что кроме того, в OSF разработан документ OSF Application Environment Specification (AES), содержащий спецификации интерфейсов ОС OSF/1, являющей собственной реализацией OSF ОС UNIX на базе новой микроядерной технологии (правда, до сих пор в этой реализации используются фрагменты исходного текста System V). AES является расширением SVID, POSIX 1003.1 и XPG.

2. Микроядерные операционные системы

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

В широкий обиход понятие микроядра ввела компания Next, в операционной системе которой использовалось микроядро Mach. Небольшое привилегированное ядро этой ОС, вокруг которого располагались подсистемы, выполняемые в режиме пользователя, теоретически должно было обеспечить небывалую гибкость и модульность системы. Но на практике это преимущество было несколько обесценено наличием монолитного сервера, реализующего операционную систему UNIX BSD 4.3, которую компания Next выбрала в качестве оболочки микроядра Mach. Однако опора на Mach дала возможность включить в систему средства передачи сообщений и ряд объектно-ориентированных сервисных функций, на основе которых удалось создать элегантный интерфейс конечного пользователя с графическими средствами конфигурирования сети, системного администрирования и разработки программного обеспечения.

Следующей микроядерной операционной системой была Windows NT компании Microsoft, в которой ключевым преимуществом использования микроядра должна была стать не только модульность, но и переносимость. (Заметим, что отсутствует единодушное мнение по поводу того, следует ли на самом деле относить NT к микроядерным ОС.) ОС NT была построена таким образом, чтобы ее можно было применять в одно- и мультипроцессорных системах, основанных на процессорах Intel, Mips и Alpha (и тех, которые придут вслед за ними). Поскольку в среде NT должны были выполняться программы, написанные для DOS, Windows, OS/2 и систем, совместимых со стандартами Posix, компания Microsoft использовала присущую микроядерному подходу модульность для создания общей структуры NT, не повторяющей ни одну из существующих операционных систем. Каждая операционная система эмулируется в виде отдельного модуля или подсистемы.

Позднее микроядерные архитектуры операционных систем были объявлены компаниями Novell/USL, Open Software Foundation (OSF), IBM, Apple и другими. Одним из основных конкурентов NT в области микроядерных ОС является Mach 3.0, система, созданная в университете Карнеги-Меллон, которую как IBM, так и OSF взялись довести до коммерческого вида. (Компания Next в качестве основы для NextStep пока использует Mach 2.5, но тоже внимательно присматривается к Mach 3.0.) Другим конкурентом является микроядро Chorus 3.0 компании Chorus Systems, выбранное USL в качестве основы новых реализаций ОС Unix. Некоторое микроядро будет использоваться в SpringOS фирмы Sun, объектно-ориентированном преемнике ОС Solaris. Очевидна тенденция к переходу от монолитных к микроядерным системам (хотя, как мы отмечали в предыдущем разделе, этот процесс не является прямолинейным: компания IBM сделала шаг назад и отказалась от перехода к микроядерной технологии). Кстати, это совсем не новость для компаний QNX Software Systems и Unisys, которые уже в течение нескольких лет выпускают пользующиеся успехом микроядерные операционные системы. ОС QNX пользуется спросом на рынке систем реального времени, а CTOS фирмы Unisys популярна в области банкового дела. В обеих системах успешно использована модульность, присущая микроядерным ОС.

2.1 Функции микроядра

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

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

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

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

Это свойство микроядерных систем позволяет естественно использовать их в распределенных средах. При получении сообщения микроядро может его обработать или переслать другому процессу. Поскольку для микроядра безразлично, поступило ли сообщение от локального или удаленного процесса, подобная схема передачи сообщений является удобной основой удаленных вызовов процедур (RPC - remote procedure calls). Однако пересылка сообщений производится медленнее обычных вызовов функций; оптимизация пересылки сообщений является критическим фактором успеха микроядерной операционной системы. Например, в ОС Windows NT в некоторых случаях для оптимизации используется разделяемая память. Расходы на дополнительную фиксированную память микроядра оправдываются повышением эффективности передачи сообщений.

2.2 Переносимость, расширяемость и надежность

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

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

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

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

Микроядро, обладающее небольшим набором API (микроядро OSF обеспечивает около 200 системных вызовов, а крохотное микроядро QNS - всего лишь 14), увеличивает шансы получения качественных программ. Конечно, этот компактный интерфейс облегчает жизнь только системных программистов; прикладной программист по прежнему должен бороться с сотнями вызовов.

2.3 Разделение функций

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

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

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

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

2.4 Mach и IBM

В разрабатывавшейся компанией IBM ОС Workplace (теперь она отказалась от завершения этой ОС) использовалось микроядро Mach 3.0, расширенное в кооперации с OSF средствами поддержки параллельной обработки и реального времени. Микроядро заведовало функциями взаимодействия процессов, управления виртуальной памятью, управления процессами и нитями (threads), управления процессорами (включая мультипроцессорные системы), а также управления вводом-выводом и обработки прерываний. Файловая система, планировщик процессов, сетевые службы и система безопасности вынесены из микроядра. В IBM эти компоненты называют PNS (personally neutral services), поскольку они используются во всех эмуляторах операционных систем.

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

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

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

2.5 Mach и OSF/1

ОС OSF/1 1.3 также основана на микроядре Mach. IBM является членом OSF, и эти компании обменивались технологиями организации микроядра. Однако по некоторым важным направлениям подходы IBM и OSF различаются. В версии 1.3 весь сервер OSF/1 работает в пользовательском пространстве и использует функции Mach.

Почему же OSF решилась на микроядерную реализацию монолитного сервера Unix? Как говорят специалисты OSF, OSF/1 является слишком хорошей и надежной системой, чтобы можно было ее бросить и начать все сначала. В OSF/1 1.3 используется более 90% кода предыдущих версий OSF/1. С другой стороны, чтобы улучшить возможности управления объектами, часть ядра Mach была переписана на Си++.

В результате OSF/1 1.3 получилась не такой модульной, как ОС Workplace. Но использовав значительную часть OSF/1, компания OSF смогла раньше IBM получить более или менее полную микроядерную реализацию систему.

OSF ориентируется на массивно параллельные аппаратные системы. Активно изучаются вопросы изменения поведения операционной системы при возрастании числа процессоров. В такой системе микроядро Mach будет работать на всех процессорах, а сервер OSF/1 потребуется только на некоторых из них.

Как планирует OSF, в будущих версиях OSF/1 на основе Mach будет поддерживаться возможность размещения сервера OSF/1 в пространстве ядра или в пользовательском пространстве в соответствии с выбором системного администратора при конфигурировании системы. Выполнение сервера OSF/1 в пространстве ядра позволит повысить производительность, так как вместо передачи сообщений будут использоваться вызовы процедур, и сервер всегда будет целиком располагаться в памяти. При выполнении сервера в пользовательском пространстве будет возможен его свопинга, что потенциально увеличит память, доступную для программ пользователя. Заметим, что примерно такой же подход используется USL в версиях Unix, основанных на микроядре Chorus. Системные функции будут разработаны и отлажены в пользовательском пространстве, а потом можно будет перенести в пространство ядра для достижения наилучшей производительности.

Основным назначением микроядра ОС Windows NT является упрощение переноса системы: все машинно-зависимые программы сконцентрированы внутри микроядра. Microsoft пока не пытается вычленить микроядро NT. В частности, поэтому многие полагают, что NT на самом деле не обладает микроядром ОС, подобным Mach и Chorus. Отмечается также, что в NT из пространства ядра должным образом не вынесены функции более высокого уровня (хотя аналогичные замечания применимы и к OSF/1 и Chorus/MiX) и что драйверы устройств в NT минимально взаимодействуют с ядром, а большей частью непосредственно работают с более низким уровнем абстракции аппаратуры (HAL - Hardware Abstraction layer).

Приложения Windows NT общаются с "подсистемами окружения", которые работают в режиме пользователя и аналогичны прикладным средам в ОС Workplace. Эти подсистемы поддерживаются исполнительной системой NT, которая работает в пространстве ядра и никогда не откачивается на диск. В состав исполнительной системы входят менеджер объектов, монитор безопасности, менеджер процессов и менеджер виртуальной памяти. Исполняющая система, в свою очередь, основывается на службах нижнего уровня, предоставляемых ядром (или, если угодно, микроядром) NT. Эти службы включают планирование процессов и нитей, обработку прерываний и исключительных ситуаций, синхронизацию процессоров и восстановление после сбоев системы. Ядро исполняется в привилегированном режиме и никогда не откачивается из оперативной памяти. Параллельные верви в ядре возникают только при обработке прерываний. Ядро основывается над уровнем HAL, в котором сконцентрирована большая часть аппаратно-зависимых программ.

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

Многие другие решения принимались на основе подобных прагматических соображений. Например, для эмуляции Win32 традиционная иерархия процессов не требуется, но для других подсистем окружения (например, для OS/2 и Posix) это необходимо. Исполнительная система NT обеспечивает набор средств управления процессами, достаточный для текущего набора прикладных сред NT и для схожих с ними, которые пока не поддерживаются (например, VMS). Радикально отличающиеся случаи, для реализации которых может потребоваться модификация исполнительной системы, не предусматриваются.

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

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

Подобно другим микроядрам, ядро NT заведует обработкой прерываний и переключениями контекста. Прерывание обрабатывается ядром, а затем переправляется в подпрограмму обработки прерывания (ISR - interrupts service routine). Для связывания уровня прерывания с ISR в ядре используется объект прерывания; это позволяет концептуально отделить драйверы устройств от аппаратуры прерываний. В этом также различие подсистем ввода-вывода NT и большинства других микроядер. В Mach и Chorus драйверы устройств имеют доступ к аппаратуре только через средства ядра. Менеджер ввода-вывода в NT, который включает файловую систему, драйверы устройств и сетевую поддержку, обычно работает напрямую с уровнем HAL, лежащим ниже ядра. Поддержка ядра требуется для обработки прерываний, но в остальных отношениях драйверы работают автономно.

В Microsoft утверждают, что имелись существенные основания для подобной организации интерфейса драйверов устройств. Например, IBM не смогла реализовать все функции драйверов устройств за пределами ядра; пришлось находить способ, позволяющий части драйвера работать в пространстве ядра. Для обработки и пересылки прерываний в NT устанавливается объектная связь с драйвером устройства, а затем драйвер может работать непосредственно со связанным с ним устройством через HAL. Ничто не мешает писать специализированные драйверы устройств, но они должны быть отделены от прикладной программы и должны взаимодействовать с подсистемой ввода-вывода NT.

2.7 AT&T и Chorus

Микроядро Chorus во многих отношениях походит на реализации Mach, выполненные IBM и OSF. Chorus включает поддержку распределенных процессоров, нескольких распределенных серверов операционной системы (во многом похожую на комбинацию Mach-OSF/1), управления памятью и обработки прерываний. Поддерживается также прозрачное взаимодействие с другими экземплярами микроядра Chorus, что делает Chorus хорошей основой для сильно распределенных систем.

Существует несколько реализаций микроядра Chorus. Chorus/MiX, версия компании Chorus операционной системы с интерфейсами Unix, включает отдельные версии, совместимые с SVR3.2 и SVR4. USL собирается объявить Chorus/MiX V.4 микроядерной реализацией SVR4. USL и Chorus Systems планируют совместную работу по разработке Chorus/MiX V.4 в качестве будущего направления Unix. Специально для использования на персональных компьютерах компания Chorus поддерживает реализацию Chorus/MiX, совместимую с SCO.

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

2.8 Новые микроядерные системы

Операционная системы SpringOS фирмы Sun, которая пока находится в стадии проектирования и разработки, основывается на микроядре и объектах. Вероятно, в SpringOS будет использоваться значительный объем существующих программ Solaris подобно тому, как в OSF/1 используется существующий сервер OSF/1. Компания Sun не объявляла об использовании какого-либо существующего микроядра и, по-видимому использует собственную разработку.

2.9 Зрелые микроядра

QNX и CTOS - это две зрелые микроядерные операционные системы, поставляемые на протяжении нескольких лет. 8-килобайтное микроядро QNX поддерживает только планирование и диспетчеризацию процессов, взаимодействие процессов, обработку прерываний и сетевые службы нижнего уровня. Это микроядро обеспечивает всего лишь 14 системных вызовов. Микроядро QNX может быть целиком размещено во внутреннем кэше некоторых процессоров, таких как Intel 486.

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

CTOS, появившаяся в 1980 году, была написана для рабочих станций фирмы Convergent Technologies - семейства машин на основе процессоров Intel для работы в "кластерных сетях", соединенных по обычным телефонным проводам. Продаваемые в настоящее время фирмой Unisys, эти основанные на CTOS машины продемонстрировали преимущества распределенных вычислений на основе передачи сообщений задолго до того, как этот термин стал модным. Крохотное 4-килобайтное микроядро CTOS взяло на себя только планирование и диспетчеризацию процессов и взаимодействие процессов на основе сообщений. Все другие системные службы взаимодействуют с ядром и друг с другом через четко определенные интерфейсы сообщений.

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

Сергей Кузнецов , Центр Информационных Технологий.
Оригинал статьи опубликован на сервере Центра Информационных Технологий по адресу:

Причиной появления стандартов на операционную систему UNIX стало то, что она была перенесена на многие аппаратные платформы. Ее первые версии работали на аппаратуре PDP, но в 1976 и 1978 годах система была перенесена на Interdata и VAX. С 1977 по 1981 годы оформились две конкурирующие ветви: UNIX AT&T и BSD. Наверное, цели разработки стандартов были разными. Одна из них – узаконить главенство своей версии, а другая – обеспечить переносимость системы и прикладных программ между различными аппаратными платформами. В связи с этим говорят и о мобильности программ. Такие свойства имеют отношение как к исходным текстам программ, так и исполнимым программам.

Дальнейший материал приводится в хронологическом порядке появления стандартов.

Стандарты языка программирования C

Этот стандарт не относится непосредственно к UNIX. Но поскольку C является базовым как для этого семейства, так и других ОС, упомянем о стандарте этого языка программирования. Начало ему было положено выходом в 1978 году первой редакции книги Б.Кернигана и Д.Ритчи. Этот стандарт часто называют K&R. Программисты, авторы этого труда, работали над UNIX вместе с Кеном Томпсоном. При этом первый из них предложил название системы, а второй изобрел этот язык программирования. Соответствующий текст доступен в Интернете [45 ].

Однако промышленный стандарт языка программирования С был выпущен в 1989 году ANSI и имел имя X3. 159 – 1989. Вот что написано про этот стандарт [46 ]:

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

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

System V Interface Definition (SVID)

Другое направление развития стандартов UNIX связано с тем, что не только энтузиасты задумывались о создании "эталонов". Основные разработчики системы с появлением многих "вариантов" решили издавать собственные документы. Так появляются стандарты, выпускаемые USG, организацией, разрабатывающей документацию версий UNIX AT&T с того момента, когда для создания операционной системы была образована эта дочерняя компания. Первый документ появился в 1984 году на основе SVR2. Он имел название SVID (System V Interface Definition). Четырехтомное описание было выпущено после выхода в свет версии SVR4. Эти стандарты дополнялись набором тестовых программ SVVS (System V Verification Suite). Основное назначение этих средств состояло в том, чтобы разработчики имели возможность судить, может ли их система претендовать на имя System V [14 ].

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

Комитеты POSIX

Работа по оформлению стандартов UNIX началась группой энтузиастов в 1980 году. Была сформулирована цель – формально определить услуги, которые операционные системы обеспечивают приложениям. Такой стандарт программного интерфейса стал основой документа POSIX (Portable Operating System Interface for Computing Environment – переносимый интерфейс операционной системы для вычислительной среды) [14 ]. Первая рабочая группа POSIX была образована в 1985 году на основе UNIX-ориентированного комитета по стандартизации /usr/group, также называемой UniForum [47 ]. Название POSIX было предложено родоначальником GNU Ричардом Столмэном.

Ранние версии POSIX определяют множество системных сервисов, необходимых для функционирования прикладных программ, которые описаны в рамках интерфейса, специфицированного для языка С (интерфейс системных вызовов). Заложенные в нем идеи использовались комитетом ANSI (American National Standards Institute) при создании стандарта языка C, упомянутого ранее. Исходный состав функций, закладываемый в первые версии, опирался на UNIX AT&T (версия SVR4 [48 ]). Но в дальнейшем происходит отрыв спецификаций стандартов POSIX от этой конкретной ОС. Подход к организации системы на основе множества базовых системных функций был применен не только в UNIX (например, WinAPI фирмы Microsoft).

В 1988 году был опубликован стандарт 1003.1 – 1988, определяющий API (Application Programming Interface, программный интерфейс приложений). Через два года был принят новый вариант стандарта IEEE 1003.1 – 1990. В нем были определены общие правила программного интерфейса, как для системных вызовов, так и для библиотечных функций. Далее утверждаются дополнения к нему, определяющие сервисы для систем реального времени, "нитей" POSIX и др. Важным является стандарт POSIX 1003.2 – 1992 – определение командного интерпретатора и утилит.

Имеется перевод [1 ] этих двух групп документов, которые получили такие названия: POSIX.1 (интерфейс прикладных программ) и POSIX.2 (командный интерпретатор и утилиты – интерфейс пользователя). В упомянутом переводе содержатся три главы: основные понятия, системные услуги и утилиты. Глава "Системные услуги" разделена на несколько частей, каждая из которых группирует сходные по функциям услуги. Например, в одном из разделов "Базовый ввод/вывод" седьмая часть, посвященная операциям с каталогами, описывает три функции (opendir, readdir и closedir). Они определяются в четырех пунктах: "Синтаксис", "Описание", "Возвращаемое значение" и "Ошибки".

Для тех, кто знаком с алгоритмическим языком программирования С, приведем пример фрагментов описания. Фактически такое описание дает представление о том, как специфицируется "Интерфейс системных вызовов". В пункте "Синтаксис" про функцию readdir приведены такие строки:

#include

#include

struct dirent *readdir(DIR *dirp);

Второй пункт ("Описание") содержит следующий текст:

"Типы и структуры данных, используемые в определениях с каталогами, определяются в файле dirent.h. Внутренний состав каталогов определяется реализацией. При чтении с помощью функции readdir формируется объект типа struct dirent, содержащий в качестве поля символьный массив d_name, в котором находится завершаемое символом NUL локальное имя файла.

Readdir читает текущий элемент каталога и устанавливает указатель позиции на следующий элемент. Открытый каталог задается указателем dirp. Элемент, содержащий пустые имена, пропускается".

А вот что приводится в пункте "Возвращаемое значение":

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

В пункте "Ошибки стандарта" указано следующее:

" Readdir и closedir обнаруживают ошибку. Dirp не являются указателем на открытый каталог".

Этот пример показывает, как описываются представляемые приложением услуги. Требования к операционной системе (реализации) заключается в том, что она "…должна поддерживать все обязательные служебные программы, функции, заголовочные файлы с обеспечением специфицированного в стандарте поведения. Константа _POSIX_VERSION имеет значение 200112L [49 ]".

В мире компьютерных технологий существует такое словосочетание: "программирование POSIX". Этому можно научиться, используя различные руководства по системному программированию UNIX и операционным системам (например, [5 ]). Есть отдельная книга с таким названием [3 ]. Заметим, что в предисловии к этой книге сказано, что она описывает ". . . стандарт втройне. . ", так как она опирается на последнюю версию POSIX 2003 года, в основе которой три стандарта: IEEE Std 1003.1, технический стандарт Open Group и ISO/IEC 9945.

Как же проверить соответствие конкретной системы стандарту POSIX? Формализация такого вопроса не так проста, как кажется на первый взгляд. В современных версиях предлагается 4 вида соответствия (четыре семантических значения слова "соответствие": полное, международное, национальное, расширенное).

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

Отметим, что набор документов POSIX изменяется уже много лет. Но разработчики новых версий всегда стараются максимально сохранить преемственность с предыдущими версиями, В более свежих редакциях может появиться что-то новое. Например, в документе 2004 года были объединены четыре части [50 ]:

Base Definitions volume (XBD) – определение терминов, концепций и интерфейсов, общих для всех томов данного стандарта;

System Interfaces volume (XSH) – интерфейсы системного уровня и их привязка к языку Си, где описываются обязательные интерфейсы между прикладными программами и операционной системой, в частности – спецификации системных вызовов;

Shell and Utilities volume (XCU) – определение стандартных интерфейсов командного интерпретатора (т.н. POSIX-shell), а также базовой функциональности Unix-утилит;

Rationale (Informative) volume (XRAT) – дополнительная, в том числе историческая, информация о стандарте.

Как и первые редакции, документ в своей основной части описывает группы представляемых услуг. Каждый элемент там описан в следующих пунктах: NAME (Имя), SINOPSIS (Синтаксис), DISCRIPTION (Описание), RETURN VALUE (Возвращаемое значение), ERRORS (Ошибки) и в заключении EXAMPLE (Примеры).

Современные версии стандарта определяют требования как к операционной системе, так и к прикладным программам. Приведем пример [51 ].

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

И в заключение приведем отрывок из курса лекций Сухомлинова ("ВВЕДЕНИЕ В АНАЛИЗ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ", Сухомлинов В.А. Часть V. Методология и система стандартов POSIX OSE), посвященным области применимости стандартов [52 ]:

"Область применимости стандартов POSIX OSE (Open System Environment) – обеспечение следующих возможностей (называемых еще свойствами открытости) для разрабатываемых информационных систем:

Переносимость приложений на уровне исходных текстов (Application Portability at the Source Code Level), т.е. предоставление возможности переноса программ и данных, представленных на исходных текстах языков программирования, с одной платформы на другую.

Системная интероперабельность (System Interoperability), т.е. поддержка взаимосвязанности между системами.

Переносимость пользователей (User Portability), т.е. обеспечение возможности для пользователей работать на различных платформах без переобучения.

Адаптируемость к новым стандартам (Accommodation of Standards), связанным с достижением целей открытости систем.

Адаптируемость к новым информационным технологиям (Accommodation of new System Technology) на основе универсальности классификационной структуры сервисов и независимости модели от механизмов реализации.

Масштабируемость прикладных платформ (Application Platform Scalability), отражающая возможность переноса и повторного использования прикладного программного обеспечения применительно к разным типам и конфигурациям прикладных платформ.

Масштабируемость распределенных систем (Distributed System Scalability), отражающая возможность функционирования прикладного программного обеспечения независимо от развития топологии и ресурсов распределенных систем.

Прозрачность реализаций (Implementation Transparency), т.е. сокрытие от пользователей за интерфейсами систем особенностей их реализации.

Системность и точность спецификаций функциональных требований пользователей (User Functional Requirements), что обеспечивает полноту и ясность определения потребностей пользователей, в том числе в определении состава применяемых стандартов."

Это позволяет решать следующие задачи:

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

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

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

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

Всего в списке стандартов POSIX более трех десятков элементов. Их имена традиционно начинаются буквой "Р", после которой расположено четырехзначное число с дополнительными символами. Существуют также групповые имена стандартов POSIX1, POSIX2 и т.д. Например, POSIX1 связан со стандартами на базовые интерфейсы ОС (Р1003.1х, где вместо х либо пусто, либо символы от a до g; таким образом, в этой группе 7 документов), а POSIX3 – методы тестирования (два документа – Р2003 и Р2003n).

X/Open, OSF и Open Group

Основанная в 1984 году рядом компьютерных фирм организация X/Open своей основной задачей ставила согласование и утверждение для разных версий UNIX стандартов общего программного интерфейса и программной среды для приложений. В 1988 году появился документ XPG3 (X/Open Portability Guide3). Он включал POSIX 1003.1 – 1988 и стандарт на графическую систему X Window System (MTI). Этот документ был развит, включая последние идеи UNIX версии BSD и System V. Он получил название XPG4.2 [14 ].

X/Open объединила свои усилия с Open Software Foundation, создав The Open Group, которая до настоящего времени работает над идеологией открытых систем. С момента создания ей принадлежит торговая марка UNIX. Фирма активно работает (вместе с IEEE, ISO и IEC) над последними стандартами операционных систем.

Заметим, что OSF была образована рядом организаций в ответ на объединение Sun Microsystems и AT&T для разработки операционной системы, претендующей на универсальность. Сегодня организация The Open Group является главным держателем стандартов UNIX. Она размещает на своем сайте много самой разнообразной информации, начиная от истории описания "What is UNIX" ("Что такое UNIX") и заканчивая серией стандартов Single Unix, Unix95, Unix98, Unix03, ISO/IEC 9945:2003, а также UNIX System API Table.

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

	NEC Corporation
Red Hat (R), Inc.	Sun Microsystems	SUSE LINUX Products GmbH

В заключение этого раздела заметим, что существует еще много менее значимых стандартов на программное обеспечение. Один из них, Linux Standard Base (LSB), создавался Free Standards Group. Но последняя объединилась с Open Source Development Labs (OSDL) и образовала новую организацию The Linux Foundation. Назовем и еще один документ – лицензию BSD (программная лицензия университета Беркли, применяемая для распространения UNIX-подобных операционных систем BSD).

1. Стандарт CP/M Начало созданию операционных систем для микроЭВМ положила ОС СР/М. Она была разработана в 1974 году, после чего была установлена на многих 8-разрядных машинах. В рамках этой операционной системы было создано программное обеспечение значительного объема, включающее трансляторы с языков Бейсик, Паскаль, Си, Фортран, Кобол и др, текстовые. Они позволяют подготавливать документы гораздо быстрее и удобнее, чем с помощью пишущей машинки.2. Операционные системы типа DOS ОС типа DOS стала доминирующей с появлением 16-разрядных ПЭВМ, использующих 16-разрядные микропроцессоры типа 8088 и 8086. С точки зрения долголетия ни одна операционная система для микрокомпьютеров не может даже приблизиться к DOS. появилась в 1981 году3. Стандарт MSX определял не только ОС, но и характеристики аппаратных средств для школьных ПЭВМ. Согласно стандарту MSX машина должна была иметь оперативную память объемом не менее 16 К, постоянную память объемом 32 К с встроенным интерпретатором языка Бейсик, цветной графический дисплей с разрешающей способностью 256х192 точек и 16 цветами, трехканальный звуковой генератор на 8 октав, параллельный порт для подключения принтера и контроллер для управления внешним накопителем, подключаемым снаружи. Операционная система такой машины должна была обладать следующими свойствами: требуемая память - не более 16 К, совместимость с СР/М на уровне системных вызовов, совместимость с DOS по форматам файлов на внешних накопителях на основе гибких магнитных дисков, поддержка трансляторов языков Бейсик, Си, Фортран и Лисп.

4. Операционные системы, основанные на графическом интерфейсе . наибольшее внимание в начале и середине 80-х годов привлекли своими графическими возможностями машины Macintosh и Amiga. В первой из них дисплей был монохромным, во второй - цветным, но обе отличались высокой разрешающей способностью и скоростью вывода графической информации на дисплей.

Операционные системы для этих машин были спроектированы так, чтобы максимально использовать возможности работы с графикой5. Пи - система В начальный период развития персональных компьютеров была создана операционная система USCD p-system. Основу этой системы составляла так называемая П-машина - программа, эмулирующая гипотетическую универсальную вычислительную машину. П-машина имитирует работу процессора, памяти и внешних устройств, выполняя специальные команды, называемые П-кодом. Программные компоненты Пи-системы (в том числе компиляторы) составлены на П-коде, прикладные программы также компилируются в П-код. Таким образом, главной отличительной чертой системы являлась минимальная зависимость от особенностей аппаратуры ПЭВМ. Именно это обеспечило переносимость Пи-системы на различные типы машин.6. Операционные системы семейства UNIX UNIX - операционная система, которая позволяет осуществить выполнение работ в многопользовательском и многозадачном режиме. Поначалу она предназначалась для больших ЭВМ, чтобы заменить MULTICS. UNIX является очень мощным средством в руках программиста, но требует очень большого объёма ОЗУ и пространства диска. Несмотря на попытки стандартизировать эту операционную систему, существует большое количество различных его версий, главным образом потому, что она была распространена в виде программы на языке Си, которую пользователи стали модифицировать для своих собственных нужд. Главной отличительной чертой этой системы является ее модульность и обширный набор системных программ, которые позволяли создать благоприятную обстановку для пользователей-программистов. Система UNIX сочетается с языком Си, на котором написано более 90% ее собственных модулей. Командный язык системы практически совпадает с языком Си, что позволяло легко комбинировать программы при создании больших прикладных систем. UNIX имеет "оболочку", с которой пользователь взаимодействует, и "ядро", которое управляет действиями компьютера. Компьютер выводит в качестве приглашения для ввода команд долларовый знак. Количество команд весьма велико. В добавление к командам по управлению файлами, которые присутствуют в любой операционной системе, UNIX имеет, по крайней мере, один текстовый редактор, а также форматер текста и компилятор языка Си, что позволяет, по мере надобности, модифицировать "оболочку".

Рядом зарубежных организаций и промышленных фирм под руководством IEEE с 1990 года ведется активная разработка последовательных версий стандартов интерфейсов открытых систем POSIX (Portable operating system interfaces). Выполнена большая работа по пересмотру, расширению и реорганизации около двадцати базовых спецификаций POSIX 1990-- 1998 годов IEEE 1003. Улучшена систематизация и структура стандартов, усовершенствовано удобство их применения пользователями. В результате подготовлен комплексный проект фундаментального международного стандарта из четырех крупных частей ISO 9945:1-4:2003 (DEEE 1003.1 - 2003), объемом свыше трех тысяч страниц. Настоящий стандарт - совместная разработка IEEE и The Open Group, он является одновременно стандартом IEEE, стандартом ISO и стандартом Open Group Technical.

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

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

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

При формировании концепции стандартов POSIX были поставлены следующие задачи:

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

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

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

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

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

Новую версию международных стандартов POSIX составляют аннотированные ниже четыре части стандартов ISO 9945:1-4:2003 - ИТ. Интерфейсы переносимых операционных систем. Ч. 1. Базовые определения. Ч. 2. Системные интерфейсы. Ч. 3. Команды управления и сервисные программы. Ч. 4. Обоснование.

Стандарт ISO 9945-1:2003 - содержит основные концептуальные определения и подробные пояснения методов реализации интерфейсов для обеспечения мобильности компонентов и комплексов программ, общее для всех томов оглавление стандарта, в том числе сервисные соглашения и определения заголовков языка Си. В большом разделе - концепция - изложены: базовые директории; файловая иерархия; сетевое взаимодействие; измерение времени и синхронизация; процессы повторного использования компонентов; политика очередей и применение семафоров. Далее выделены разделы .

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

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

• -- введение;
• -- содержание основной информации;
• -- системные интерфейсы.

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

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

В третьей части стандарта ISO 9945-3:2003 - Основные команды управления и сервисные программы (Shell and utilities) - изложено конкретное представление команд операционной системы и утилит, обеспечивающих унифицированное взаимодействие с мобильными прикладными программами, определения для стандартного источника кодового уровня интерфейса командного интерпретатора ("shell") и стандартные утилиты для прикладных программ. Стандарт содержит четыре раздела :

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

Цель этой части стандарта - конкретизировать интерфейсы прикладных программ на уровне команд, для интерпретатора командного языка, и полный набор сервисных программ - утилит. Он специфицирует интерфейсы операционных систем на уровне программных текстов и кодов. Стандартизированный командный язык Shell - средство для подготовки небольших мобильных процедур и их быстрой интерактивной отладки. В развитой среде возможно объединять команды в цепочки с фильтрацией промежуточных результатов. Каждая утилита содержит: описание структуры; применение; операнды; входные файлы; окружение. Факультативные утилиты расширяют возможности для пользователей мобильных приложений по связи с внешним окружением. В терминах языка Си (стандарт ISO 9899:1990) описаны языково-независимые услуги интерфейсов для переносимых приложений и связи с внешним окружением при представлении интерфейсов приложений на различных языках высокого уровня.

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

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

Четвертая часть стандарта ISO 9945-4:2003 - Обоснование - содержит группу из пяти крупных приложений

• -- обоснование базовых определений - приложение А;
• -- обоснование системных интерфейсов - приложение В;
• -- обоснование команд управления и сервисных программ-утилит -- приложение С;
• -- рассмотрение переносимости - приложение D;
• -- рассмотрение субпрофилей - приложение Е.

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

В стандарте ISO 14252:1996 - Руководство по POSIX окружению открытых систем (OSE) - изложена идеология и модель создания мобильных программных средств, которое детализирует для пользователей модель комплекса стандартов POSIX, а также взаимодействующих с ними стандартов де-юре, де-факто и спецификаций, необходимых для создания переносимых приложений. Модель отражает принципы построения интерфейсов прикладных программ с платформой - операционной системой, через которую осуществляется взаимодействие с компонентами внешнего окружения. Считается, что прикладные программы непосредственно не взаимодействуют с внешним окружением, а связаны с ним только через операционную систему. Разработка приложений предполагается в кросс-режиме, то есть платформа разработки - инструментальная может не совпадать с платформой исполнения (применения) программ (объектной - целевой). Результат компиляции программы на инструментальной платформе может быть перенесен для исполнения на целевую платформу.

Определяющими являются два интерфейса между тремя базовыми компонентами: между прикладными программами и платформой - операционной системой (API) и между платформой и внешним окружением (EEI). Определены общие функции - услуги платформы для этих взаимодействий.

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

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

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

Стандарт ISO 13210:1998 - Методы тестирования для оценки соответствия стандартам POSIX - содержит общую методологию тестирования для проверки соответствия интерфейсов прикладных программ стандартам POSIX. Представлены принципы формирования наборов тестов и предлагается методика развития системы тестов для контроля создаваемых приложений на соответствие ISO 9945. В методе тестирования выделены: подготовка тестов; процедуры тестирования; оформление документов, удостоверяющих соответствие стандартам. Определены и кратко представлены три основных уровня сложности тестирования: исчерпывающий; достаточно полный; оценочный - для установления общих характеристик качества. Подчеркивается, что предлагаемые методы не гарантируют абсолютное соответствие стандартам, так как исчерпывающее тестирование невозможно по техническим и экономическим причинам. Приводятся рекомендации по:

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

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

Начало созданию операционных систем для микроЭВМ положила ОС СР./М. Она была разработана в 1974 году, после чего была установлена на многих 8-разрядных машинах. В рамках этой операционной системы было создано программное обеспечение значительного объема, включающее трансляторы с языков Бейсик, Паскаль, Си, Фортран, Кобол, Лисп, Ада и многих других, текстовые (Текстовые процессоры - это наиболее широко используемый вид прикладных программ. Они позволяют подготавливать документы гораздо быстрее и удобнее, чем с помощью пишущей машинки. Текстовые процессоры позволяют использовать различные шрифты символов, абзацы произвольной формы, автоматически переносят слова на новую строку, позволяют делать сноски, включать рисунки, автоматически нумеруют страницы и сноски и т.д.) и табличные процессоры, системы управления базами данных.

Стандарт MSX

Этот стандарт определял не только ОС, но и характеристики аппаратных средств для школьных ПЭВМ. Согласно стандарту MSX машина должна была иметь оперативную память объемом не менее 16 К, постоянную память объемом 32 К с встроенным интерпретатором языка Бейсик, цветной графический дисплей с разрешающей способностью 256х192 точек и 16 цветами, трехканальный звуковой генератор на 8 октав, параллельный порт для подключения принтера и контроллер для управления внешним накопителем, подключаемым снаружи.

Операционная система такой машины должна была обладать следующими свойствами: требуемая память - не более 16 К, совместимость с СР./М на уровне системных вызовов, совместимость с DOS по форматам файлов на внешних накопителях на основе гибких магнитных дисков, поддержка трансляторов языков Бейсик, Си, Фортран и Лисп. Таким образом, эта операционная система, получившая название MSX-DOS, учитывала необходимость поддержки обширного программного обеспечения, разработанного для СР/М, и одновременно ориентировалась на новые в то время разработки, связанные с DOS, графические пакеты (Система управления базами данных (СУБД) - позволяет управлять большими информационными массивами - базами данных), символьные отладчики и другие проблемно ориентированные программы.

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

Операционные системы типа DOS

ОС типа DOS стала доминирующей с появлением 16-разрядных ПЭВМ, использующих 16-разрядные микропроцессоры типа 8088 и 8086. С точки зрения долголетия ни одна операционная система для микрокомпьютеров не может даже приблизиться к DOS. С момента появления в 1981 году DOS распространилась настолько широко, что завоевала право считаться самой популярной в мире ОС. Несмотря на некоторые свои недостатки и на то, что большая ее часть основывается на разработках 70-х годов, DOS продолжает существовать и распространяться и поныне. Хорошо это или плохо, она, вероятно, будет доминировать на рынке операционных систем в течение ближайшего времени. В настоящее время для DOS разработан огромный фонд программного обеспечения. Имеются трансляторы (Транслятор - программа, автоматически преобразующая программу на языке программирования в последовательность инструкций. Разновидности трансляторов - компилятор, интерпретатор) для практически всех популярных языков высокого уровня, включая Бейсик, Паскаль, Фортран, Си, Модула-2, Лисп, Лого, АПЛ, Форт, Ада, Кобол, ПЛ-1, Пролог, Смолток и др.; причем для большинства языков существует несколько вариантов трансляторов. Имеются инструментальные средства для разработки программ в машинных кодах - ассемблеры, символьные отладчики и др. Эти инструментальные средства сопровождаются редакторами, компоновщиками и другими сервисными системами, необходимыми для разработки сложных программ. Кроме системного программного обеспечения для DOS создано множество прикладных программ.

Дисковая ОС (DOS)

ОС система DOS состоит из следующих частей:

Базовая система ввода-вывода (BIOS), находящаяся в постоянной памяти (постоянном запоминающем устройстве, ПЗУ) компьютера. Эта часть ОС является «встроенной» в компьютер Её назначение состоит в выполнении наиболее простых и универсальных услуг ОС, связанных с осуществлением ввода-вывода. Базовая система ввода-вывода содержит также тест функционирования компьютера, проверяющий работу памяти и устройств компьютера при включении его электропитания. Кроме того, базовая система ввода-вывода содержит программу вызова загрузчика ОС.

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

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

Дисковые файлы10.SYS и MSDOS.SYS (они могут называться по-другому, например IBMB.COM и IBMDOS.COM для PC DO; URBIOS.SYS и DRDOS.SYS для DR DOS, - названия меняются в зависимости от версии ОС). Они загружаются в память загрузчиком ОС и остаются в памяти компьютера постоянно. Файл 10.SYS представляет собой к базовой системе ввода-вывода в ПЗУ. Файл MSDOS.SYS реализует основные высокоуровневые услуги DOS.

Командный процессор DOS обрабатывает команды, вводимые пользователем. Командный процессор находится в дисковом файле COMMAND.COM на диске, с которого загружается ОС. Некоторые команды пользователя, например Type, Dir или Cop, командный процессор выполняет сам. Такие команды называются внутренними. Для выполнения остальных (внешних) команд пользователя командный процессор ищет на дисках программу с соответствующим именем и если находит её, то загружает в память и передает её управление. По окончании работы программы командный процессор удаляет программу из памяти и выводит сообщение о готовности к выполнению команды (приглашение DOS).

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

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

Версии DOS

Всего за несколько лет система МS DOS прошла путь от простого загрузчика до универсальной сложившейся операционной системы для персональных компьютеров, построенных на базе микропроцессоров Intel 8086. МS DOS поддерживает компьютерные сети и графические интерфейсы пользователя, всевозможные запоминающие устройства, служит основой для тысяч прикладных программ.. Система МS DOS, имеющая более 10 млн. зарегистрированных пользователей, постоянно «отбирает» пользователей у своих конкурентов. Предшественником МS-DOS была операционная система 86-DOS, написанная в середине 80-х гг. Тимом Петерсоном для компании Sеаttlе Соmputer Рroducts. В то время наиболее популярной системой для микрокомпьютеров на базе Intel 8080 и Zilog Z-80 была операционная система СР/М-80 фирмы Digital Research. Эта система обеспечивала доступ к разнообразным средствам прикладного программного обеспечения (текстовые процессоры, администраторы баз данных и т.д.). Для облегчения процесса переноса прикладных программ из 8-битной системы СР/М-80 в новую 16-битную среду системы 86-DOS последняя изначально строилась так, чтобы в ней имитировались все функции и виды операций СР/М-80. Вследствие этого структуры блоков управления файлами, префиксов сегментов программ и выполнимых файлов в системе 86-DOS почти идентичны структурам СР/М-80. Программы, существовавшие в СР/М-80, можно было легко преобразовать (обрабатывая файлы исходных программ с помощью специального транслятора) и далее запускать в системе 86-DOS либо сразу, либо выполнив несложное ручное редактирование. Ввиду того, что 86-DOS поставлялась на рынок как собственная операционная система семейства микрокомпьютеров фирмы Seattle Computer Research с интерфейсом S-100 на базе Intel 8086, в целом такой подход слабо повлиял на состояние дел в мире персональных компьютеров. Другие поставщики микрокомпьютеров на базе Intel 8086, вынужденные по очевидным причинам применять операционную систему конкурентов, с нетерпением ждали выпуска системы СР/М-86 фирмы Digital Research. В октябре 1980 г. кампания IВМ предложила фирмам, занимающимся разработкой программного обеспечения для микрокомпьютеров, начать поиск операционной системы для нового семейства персональных компьютеров. Фирма Microsoft не могла предложить собственной операционной системы, за исключением автономной версий Microsoft ВАSIС, однако она заплатила фирме Seattle Computer Products за право продавать систему Петерсона 86-DOS. За это Seattle Computer Products получила лицензию на право использовать и продавать языки программирования и все версии операционной системы для микропроцессора 8086, разработанные фирмой Microsoft. В июле 1981 г. Мicrosoft приобрела все права на систему 86-DOS, значительно переработала ее и дала название МS DOS. Когда осенью 1981 г. появились первые компьютеры IВМ РС, фирма IВМ предложила для них в качестве основной операционную систему МS DOS, названную РС DOS 1.0. Кроме того, фирма IВМ выбрала для микрокомпьютеров РС в качестве альтернативных операционных систем системы СР/М-86 (фирмы Digital Research) и Р-sуstem (фирмы Softech). Однако обе эти системы имели ряд недостатков: обладали малым для IBМ РС быстродействием, высокой стоимостью, отсутствием доступных языков программирования. Окончательно чаша весов склонилась в пользу системы РС DOS после того, как фирма IВМ с ее помощью реализовала все прикладные программные средства для IВМ РС, а также инструментарий, работающий под их управлением. Поэтому с самого начала разработчики программного обеспечения ориентировались на РС DOS, а системы СР/М-86 и Р-system не заняли сколько-нибудь значительного места на рынке программного обеспечения для IВМ РС.