Журнал «Компьютерра» № 20 от 30 мая 2006 года - Компьютерра. Страница 32

В начале 1980-х годов в результате очередного антимонопольного судебного процесса AT&T была разделена на несколько подразделений, в результате чего у корпорации оказались развязаны руки (в смысле получения прибыли от торговли компьютерами). И вновь – тяжело предположить, как бы сложилась судьба Unix без этого события: с одной стороны, агрессивный маркетинг AT&T способствовал быстрому и эффективному распространению ОС; с другой – новая стратегия лицензирования (без исходного кода) положила начало разделению разработки Unix на несколько разных независимых веток и многолетнему противостоянию этих веток (так называемые unix wars).

Одной из «веток» стал разработанный в Беркли «берклиевский набор софта» (Berkeley Software Distribution, BSD), по прежнему распространявшийся свободно и с исходниками. Возможно, именно этот факт повлиял на DARPA[На всякий случай: DARPA – Defense Advanced Research Projects Agency (Агентство перспективных исследований при Министерстве обороны США) – так или иначе поддерживало огромную часть исследований, которые сформировали образ современных IT] при выборе – кому бы дать денег для разработки протокола TCP/IP. Дали. Разработали (4.2BSD, август 1983 года). Этот фактор (совместно со многими другими) повлиял на огромную популярность и быстрое распространение BSD. Ну а Билл Джой, с которого начиналась эта версия Unix, тем временем создал собственную фирму под названием «Солнышко».

Оригинальная Unix System V от AT&T, созданная в Беркли BSD, Sun OS от Sun Microsystem и еще несколько дистрибутивов, основанных на System V и BSD, вступили в сложное взаимодействие, включавшее и конкуренцию, и заимствование полезных фич, и юридические споры – в общем, было весело. Однако все это привело к размытию образа Unix и потере ориентиров в стиле «лебедь, рак и щука». Попытки исправить ситуацию привели к очередному пату: AT&T и Sun скоординировались и создали System V version 4, а многие независимые производители, которым не понравился этот альянс гигантов, объединились в Open Software Foundation[Не путать с Free Software Foundation – ничего общего!] и попытались создать «свой» Unix по имени OSF/1 (в общем, это была неудачная попытка)[Вообще говоря, у них там все еще сложнее получилось: сначала группа независимых поставщиков Unix создала группу по его стандартизации X/Open, в ответ на это объединились AT&T и Sun; а уже это привело к появлению Open Software Foundation].

Этот жизнерадостный период (конец 80-х – начало 90-х), называемый Unix wars, имел много интересных последствий: считается, что пока юниксопроизводители воевали друг с другом, Windows захватил десктопы, а внезапно появившийся Linux – сердца простых юниксоидов, которым скандалы производителей были до фени. Впрочем, в данном контексте нам будут намного интереснее другие последствия противостояния.

А последствия были такие: программистам стало очень печально жить. Как водится, в результате маркетинговых войн (когда каждый стремится сотворить систему круче чем у прочих) совместимость различных клонов Unix пошла на убыль. То есть программа, написанная под какую-нибудь Sun OS, совершенно не обязательно станет работать под какой-нибудь другой BSDI (хотя, по идее, и то и другое – Unix). Менеджерам-маркетологам этот вопрос был, в общем, без разницы («а так даже лучше – чего это наши программы будут работать под ОС конкурента?»), но, к счастью, культура Unix всегда определялась скорее программистами и продвинутыми пользователями, нежели менеджерами.

В 1985 году за дело взялась серьезная организация IEEE, которая ведает большой частью американских и международных стандартов. При участии многих выдающихся профессионалов к 1990 году появился стандарт POSIX (о происхождении аббревиатуры – см. эпиграф; официальная расшифровка – Portable Operating System Interface[X в аббревиатуре – что-то вроде «привет юниксоидам»]).

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

Соответственно своей цели (обеспечить переносимость прикладных программ), POSIX не предъявляет никаких требований к архитектуре операционной системы. POSIX определяет только взаимодействие между программой и ОС в стиле «системный вызов по имени А с параметром Б должен выполнить В и вернуть результат Г или ошибку Д». Это означает, что «POSIX-совместимая операционная система» не является синонимом «Unix». Например, в исходный код Linux (чтобы там ни думала себе SCO) не входит ни единой строчки из изначального AT&T Unix. Тем не менее программы, работающие в System V или BSD, без проблем запустятся в Linux. Торвальдс достиг этого результата действиями «в лоб»: взял стандарт POSIX и реализовал его. Получилось[Когда Oracle портировала свою БД (уже работавшую на Sun Solaris, наследнике Sun OS) на Linux, кто-то задал оракловским инженерам вопрос типа «и что, трудно было?» Ответ был характерен: «мы запускали make» (в смысле – собрали программу из исходников, и все заработало)].

Я вам больше скажу – Windows NT совместима с одной из частей POSIX (1003.1b, real-time extensions, описывающей переключение процессов, синхронизацию потоков и т. п.). И если скачать с сайта Microsoft набор утилит Services for Unix (SFU) – брюки превращаются… во вполне POSIX-соместимую систему (то есть теоретически любая Unix-программа на Windows+SFU должна собраться и запуститься без проблем). И еще более того – поддержка SFU корпорацией Microsoft как отдельного продукта практически прекращена – потому что он теперь будет входить в стандартную поставку Windows. Такие форточки.

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

Образцовым примером проприетарного API является, как несложно предположить, Microsoft Windows API. Его наиболее «любимые» программистами характеристики стали уже притчей во языцех:

Далеко не все API документировано, в результате чего прикладные программы, разработанные Microsoft, имеют возможности по интеграции с ОС, недоступные другим программам.

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

Увлеченность «новыми» технологиями: часть Windows API основывается, как и POSIX, на базовых типах и принципах языка C; другую часть невозможно использовать без знания Microsoft COM.

И просто непродуманность. Хрестоматийный пример: разрабатывая под Windows программу, работающую в командной строке, задачу вызова другой программы и перехвата ее вывода можно решить одним-единственным вызовом перекочевавшей из POSIX функции popen. Но вот разрабатывающий оконное приложение программист обязан пользоваться уже другим API, простейший пример использования которого занимает около двух страниц кода: инициализация внутренних структур, запрос и установка параметров, подготовка окружения.

К слову, и на Windows API существует международный стандарт ECMA-234; эмулятор WinAPI для POSIX-систем Wine опирается именно на этот стандарт.