Журнал «Компьютерра» № 20 от 30 мая 2006 года

Журнал Компьютерра

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

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

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

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

И

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

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

Кому это нужно кто это выдержит

Как уже было сказано, самая первая версия стандарта POSIX – он же IEEE 1003 – была подготовлена в 1985–90 годах под руководством IEEE, Института инженеров по электротехнике и электронике, международной некоммерческой организации, занимающейся как раз стандартизацией различных технологий.

Этот стандарт включал две части: 1003.1 определяла требования к системным вызовам самой ОС, а 1003.2 (появившаяся в 1992 году) – требования к «окружению», то есть к программам-утилитам, которые должны присутствовать в POSIX-совместимой системе. Еще одна часть стандарта – требования к системе реального времени, в 1993 году вышедшая как 1003.4, а в 1996-м – разделенная и переименованная в 1003.1b (собственно система реального времени) и 1003.1c (управление параллельными процессами). Стандарт был также принят международной организацией по стандартизации как ISO/IEC 9945.

Тем временем закончились Unix-войны. Усталая AT&T на все плюнула и продала все связанные с Unix права, патенты и исходные коды фирме Novell; та тоже недолго мучилась и продала Unix частями: все права на торговую марку и название ушли в упомянутую выше X/Open, а права на исходный код – в печально знаменитую SCO Group (которой эти права не принесли счастья).

А вот из X/Open, в которой объединились ведущие поставщики Unix для создания общего стандарта[Собственно, именно это, а не уход AT&T, положило конец Unix-войнам], вышел толк. Объединившись в 1996 году с Open Software Foundation, под общим названием The Open Group, заполучив в свои ряды практически всех основных unix-игроков, некоммерческая организация занялась разработкой общей спецификации Unix (Single UNIX Specification), которая и вышла в 1998 году. Некоторое время Single UNIX Specification и POSIX существовали параллельно (причиной тому – бытовавшая в IEEE странноватая практика продавать копии стандартов за большие деньги и запрещать их свободное распространение); однако, в конце 90-х была создана специальная Austin Group, занятая объединением двух стандартов. В результате, в 2001 году вышла Single UNIX Specification 3, которая является одновременно и POSIX-стандартом IEEE.

Будучи по сути одним и тем же документом, SUS и POSIX преследуют различные цели: POSIX, как уже было сказано выше, это стандарт, которому должна соответствовать операционная система для переносимости программ; в то время как SUS – стандарт, которому нужно соответствовать, чтобы иметь право употреблять торговую марку UNIX.

И здесь мы возвращаемся к началу статьи и вопросу «что есть Unix». На сегодня все *n?x-системы (в том числе и BSD-клоны, в названии которых нет ни "n", ни "x") принято делить на:

Unix по происхождению: это ОС, которые основываются на оригинальном исходном коде Unix, разработанном в AT&T. Эти ОС совершенно необязательно соответствуют каким-либо стандартам. Этот тип, как правило, включает различные «исторические» версии Unix (созданные еще до появления всяких стандартов).

Unix по праву имени: системы, которые прошли сертификацию The Open Group и имеют право употреблять торговую марку UNIX в своем названии и/или описании. При этом совершенно не обязательно использовать оригинальный код AT&T. В основном это коммерческие дистрибутивы: HP-UX, Solaris и т. п., у авторов которых есть необходимость доказать пользователю «качество» системы и достаточное количество денег и времени, чтобы пройти непростой процесс сертификации.

Unix по функциональности: системы, которые не соответствуют ни пункту (1), ни пункту (2), но тем не менее в большой степени похожи на юникс и совместимы с ним. Сюда входят практически все варианты Linux; сюда же можно отнести открытые BSD-клоны (FreeBSD, OpenBSD и т. д.), которые, хотя и основаны на оригинальном BSD, произошедшем от AT&T Unix, активно развиваются и близки к существующим стандартам. Linux и BSD, разрабатываемые энтузиастами, как правило, достаточно близки к стандартам, но их авторы не горят желанием тратить деньги и время на официальное подтверждение этого факта.

Интересно, что само имя UNIX не рекомендуется употреблять «не по делу», применительно к несертифицированным системам и без значка ®, поскольку оно является зарегистрированной торговой маркой. Зачастую, говоря о *nix-системах, употребляют написание «Unix» или «unix» – вроде бы они зарегистрированными марками не являются[С вопросом больших-маленьких букв в этом слове связан забавный казус: слово «Unix», являясь аббревиатурой, в самых старых документах пишется маленькими буквами с большой "U"; Деннис Ритчи объясняет этот факт просто: «у нас только-только появилась новая пишущая машинка, на которой большие и маленькие буквы различались, и нам очень нравилось с ней играться»].

LSB

Несмотря на некоторую отвлеченность Linux от Single UNIX Specification, у линуксоидов тоже есть свои стандарты. Во-первых, стандартно ядро (в силу своей единственности); во-вторых, всякий Linux в меру сил POSIX-соместим; в-третьих, существует LSB.

LSB – это Linux Standard Base; стандарт, расширяющий POSIX, цель которого – увеличить совместимость Linux-дистрибутивов. Помимо вопросов, оговариваемых POSIX’ом, LSB определяет «правильное» расположение основных папок в файловой системе (/bin/ для программ, /etc/ для конфигурационных файлов и пр.), некоторые расширения системы X Windows, систему распространения пакетов[Кстати, система распространения пакетов – одна из крайне спорных частей LSB. Дело в том, что их существует как минимум две («как минимум» – известных и употребляемых во многих системах): rpm (произошедшая от RadHat Linux) и deb (произошедшая от Debian); причем deb гораздо старше и считается более зрелой, но стандарт навязывает использование rpm] и т. п. В отличие от POSIX, LSB в большой степени определяет облик Linux, а не только интерфейс взаимодействия ОС и прикладного софта.

Сертификацией на соответствие LSB занимается та же The Open Group, впрочем, слово «Linux», к счастью, можно использовать и без сертификации. Из распространенных дистрибутивов сертифицированными являются SUSE и RadHat.

Университеты: Виды бесплатного сыра

Авторы: Алексей Ковязин, Кузьменко Дмитрий

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