Восхитительная на вкус шоколадная корочка

поверх ванильной операционной системы...

Из переписки юниксоидов

Когда мы готовили прошлый номер, случился анекдот. Схватив верстку своего репортажа про бета-версии NT и OS/2, я не удовлетворился фразой"... OS/2 уже получила среду выполнения Java-программ" и приписал между строк "вдобавок к REXX". После этого литературный редактор, вносивший правку, принял "к" за V и добавил очевидно забытый мною знак препинания. Получилось: "вдобавок и REXX – среду выполнения Java-программ".

Мне хотелось подчеркнуть наличие REXX как преимущество OS/2 перед NT. Но только в принципе, только как подход, потому что сам REXX мне не нравится. С точки зрения сегодняшних представлений о программировании это типичная окаменелость. Когда-то главным условием реализации интерпретатора этого языка, предназначенного для встраивания в другие программы, были малые размеры. Получилась очень странная среда, которая всегда ведет себя не так, как ожидаешь.

Много позже один американский немец придумал для тех же целей язык TCL. Это весьма впечатляющий проект, особенно по качеству исполнения, превосходящему все виденное в университетских разработках. Сам автор, кстати, упоминает REXX, как идейного предшественника. Да ведь и блистательная Java родилась, как язык для программирования программ.

Еще совсем недавно исследователи AT&T работали над безопасной версией TCL, предназначавшейся в точности на роль, занятую нынче Java. Ну, может, с тем отличием, что Java предстала взорам публики на Web-страничках, а разработчики Safe TCL не подчеркивали именно эту сторону применения языка. В Интернете есть множество более важных случаев, когда хотелось бы, чтобы один компьютер мог программировать другой, но без риска засадить в него заразу.

Это я все к тому, что совершенное нашим литературным редактором невольное скрещивание REXX и Java – акт, несомненно, санкционированный на небесах.

Однако и в unix, и в OS/2 языки программирования программ изнутри и снаружи – разные, и не достигли должного уровня сращивания со средой. По-настоящему надо бы иметь единый язык и встроить его в ОС, как раньше и было.

Создатели unix демонстративно отсоединили командный интерфейс пользователя, так называемый shell, от ядра системы (и гордились этим). Пользователи – а ими были в основном программисты-первопроходцы, способные перерезать друг другу глотки, споря о достоинствах языков – получили свободу выбора. Знаете, как они воспользовались ею?

В современных unix существует полдюжины несовместимых между собой вариантов shell, похожих до того, что по тексту программы не всегда можно догадаться, на чем она написана. Импортируя программную систему, включающую в себя командные файлы на shell (a это почти всегда так), часто приходится бежать искать интерпретатор, который мог бы их выполнить. И хоть бы кто попробовал создать оригинальный командный язык, непохожий на npa-shell.

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

Встраиваемый в программы стандартный интерпретатор – сильная идея. По крайней мере, никто из разработчиков после этого не заявит, что ему не хватает возможностей. Однако shell никогда не предназначался для встраивания, a TCL появился много позже, и это совершенно другой язык.

В OS/2 роль shell играет разновидность худосочного COMMAND.COM, a REXX вставлен, как фирменная реликвия, или, если угодно, приманка для стариков, помнящих его еще по мэйнфреймам. Тут о концептуальном единстве тем более не приходится говорить.

Наиболее примечательная особенность Windows – отсутствие командного интерфейса ОС как такового (не надо про Мае: это завело бы слишком далеко). COMMAND.COM в классических "виндах" существует лишь как программа DOS и вовсе не годится для управления системой. Если из Windows запустить DOS, а из него – программу для Windows, то она тупо ответит... сами знаете что.

"Полуос" многие полюбили как раз за то, что его легко вывернуть наизнанку и сделать текстовый интерфейс основным. Коммандер в "родном" полуосном сеансе спокойно распознает и запускает любые приложения – хоть для DOS, хоть для Windows, хоть для РМ. Если его самого заменить на что-то более съедобное – атакихвариантов множество, в том числе есть и порты shell'oв – система становится очень похожа на unix с X, но при этом отлично выполняет приложения DOS и Windows. Правда, сами DOS и Windows, входящие в состав полуос, демонстративно не переделаны и почти не умеют взаимодействовать с системой, в которую они погружены.

Microsoft не случайно спроектировала Windows именно так. Эта система, вне всякого сомнения, представляла собою вызов профессиональному сообществу. А вот DOS в Windows 95 переделали. Желающие могут устроить себе окошко с обычным досовским нортон-коммандером и запускать из него 32-разрядные приложения с графическим интерфейсом. Так меняется Microsoft в последние годы.

Давным-давно научно-технические пользователи подключали к своим компьютерам PDP и VAX-11 одновременно по два терминала -простой текстовый и графический (обычно Tektronix). Все, что видит пользователь unix на экране, которым управляет X-Window, до сих пор выглядит и ведет себя так. Как ни смешно, именно на этот бессмертный образец общественность заставила наконец равняться разработчиков новых Windows.

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

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

Напоследок вот еще одно полезное (особенно для SOHO) ископаемое: СОМ-порт. Устроены они на PC из рук вон скверно, однако для полуос это почтенный ресурс, а винды, даже самые новые, их снобистски третируют, как анахронизм, от которого надо бы избавиться, да все никак не удается.

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