Система первого Mac’а: ресурсы, toolbox и эзотерика

Это очень поверхностное путешествие по первой Mac’овской операционной системе. Она не так проста, как кажется. И, или мне это только кажется, она чем-то очень похожа на самый первый iPhone. В обоих случаях преодоление силы гравитации, компромиссы и оригинальные инженерные решения, сделавшие невозможное возможным.

Продолжение, начало тут.

Прежде чем мы перейдем к описанию внутренностей Mac’овской операционной системы, скажу несколько слов в защиту железа первого Mac’а. Его конфигурация 128K/400K была абсолютно недостаточна, это факт, недостаточна именно для компьютера с графическим пользовательским интерфейсом – требовавшим значительно более дорогой элементной базы, чем можно было себе позволить.

Средний объем оперативной памяти тогдашних компьютеров был 64 К, а накопители на гибких дисках, используемые в индустрии, как правило, вмещали менее 200 K.

Ответвление ресурсов (Resource Fork)

Концепция разделения файлов на несколько частей придумана не Apple. Что-то отдаленно похожее использовалось в Xerox PARC, в Novell Networks и даже в Windows, но нигде эта идея не получила столь яркого и необычного воплощения, как в классической Mac’овской системе.

Файл в Mac’овской системе состоял из двух ответвлений, ответвления данных (Data Fork) и ответвления ресурсов (Resource Fork), любое из которых могло быть пустым. Все объекты файловой системы – документы, приложения и документы системы – состояли их этих двух ответвлений и активно их использовали.

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

А ответвление ресурсов строилось по правилам, определенным Apple Computer и автором менеджера ресурсов Брюсом Хорном.

Типы (группы) ресурсов обозначались константами типа OSType, значение которого было числом, но на экране отображалось как последовательность из 4 букв. Например, CODE, DLOG, ALRT, BNDL и много-много других.

Числовой идентификатор – двухбайтовое целое число со знаком, при этом все значения от 128 до 32767 предназначались для использования сторонними разработчиками. Значения от -32768 до -16385 были (и остались навечно) зарезервированы для чего-то неизвестного.

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

Кроме типа и идентификатора, ресурс можно назвать “человеческим” именем, но имя было необязательным. Имя можно было использовать для указания на запрашиваемый ресурс.

Размер ресурса, в первых версиях системы, был строго ограничен 32 килобайтами. Позже это ограничение было снято – специфический для Microsoft кодовый ресурс PCOD тянул в Excel 2.5 или в Word 5.1 на пару мегабайт. Но, даже в 32 килобайта можно вложить много чего, хотя в ресурсах первой системы для самого первого Mac’а их размеры были намного скромней.

Система управления памятью в Mac’овской системе была новаторской и передовой в 1984-м, она же (не изменившаяся за 12 лет) выглядела совершенно архаичной в 1996-м, в сравнении с аналогичной системой в Windows. Но в 1984-м она, особенно её особый подход к загрузке в оперативную систему ресурсов, была на высоте. Если настройки ресурса разрешали, он удалялся из оперативной памяти при первых признаках её нехватки. Структура, которой он был представлен в приложении, отвечала за загрузку его в память по первому требованию.

Ресурсы были бы чем-то скучным, если бы не ResEdit, бесплатное приложение от Apple.

Оно открывало совершенно неожиданный и фантастический вид на изнанку Mac’овских приложений и документов. Ниже приведена оборотная сторона приложения TeachText, бесплатного и даже с открытым исходным текстом, простенького текстового редактора для классической системы. В 1984 году его еще не было, но MacWrite, MacPaint и ResEdit выглядели примерно так.

Ресурс BNDL, например, связывал приложение с иконкой (иконками) самого себя, а также с типами редактируемых им файлов, и он же присваивал этим типам файлов иконки.

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

На иллюстрации (цветное яблочко в меню – это снято в какой-то из 7-х версий системы) в BNDL приложения TeachText добавляется поддержка еще одного типа файлов, ttwo. На самом деле TeachText (код типа приложения ttxt) умел работать с файлами типа TEXT и с защищенными от записи файлами типа ttro. Добавление нового типа поддерживаемых файлов только в BNDL практически бессмысленно: поддержка осуществляется в коде.

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

В документе, например, того же TeachText (Creator code = ‘ttxt’, File code = ‘TEXT’) ресурсы, скорее всего, показывали размер и положение документа в момент его закрытия, чтобы все можно было начать ровно с того места, на котором в прошлый раз всё закончилось.

Ответвления ресурсов не вошли в функциональность Mac OS X. Apple Computer, в последние годы прошлого тысячелетия, не имела никакого влияния на индустрию. Её считали все еще гибнущей компанией. Технически преобразование файлов с двумя ответвлениями в директорию с файлом (копией ответвления данных) и директорией (копией ресурсов) было несложно, и поддерживать такие комплексы в системах без ветвлений – тоже не ядерная физика.

Apple не смогла бы добиться движения навстречу с другой стороны. Без поддержки на чужих системах никакое техническое решение не сработало бы. Кроме того, у компании было очень плохо с ресурсами, остро не хватало времени – и его не стали тратить на то, без чего можно было обойтись. В NeXTSTEP использовался отдаленно похожий, но другой подход к организации приложений, он был перенесен в Mac OS X один в один.

Toolbox, System и эзотерика

Экспертов (не “экспертов”, разочарованных отсутствием инопланетянина в корпусе Mac’а), знакомых с графическими пользовательскими интерфейсами не с чужих слов, удивляло другое: как Apple смогла заставить всё это работать в 128 K оперативной памяти и на 400 К дисковой. Магия?

Графические интерфейсы давно уже были не просто теорией. Они существовали не только в виде лабораторных гомункулусов, их уже пробовали на роль коммерческих проектов, в Xerox PARC (Alto и другие) и на самой Apple (Lisa). Попытки были восхитительны, но с точки зрения банальной эрудиции ни к чему, кроме разочарования, не привели. Концепция была признана порочной, бессмысленной и нереальной. Красивой, да. Увлекательной. Но только не делайте этого!

Mac был плоть от плоти типичный компьютер своего времени. Раза в два более мощный и упакованный, чем средний в те времена аппарат для домашнего пользователя. Но ничего сверхъестественного: 32-битный процессор, мышь, 24-битная адресация и 16-битная шина. Круто, но не более того. Были машинки и помощнее.

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

В технической документации этот комплекс разделен на две части: тулбокс и системные утилиты. Тулбокс – это и есть тот самый графический пользовательский интерфейс. Это различные “менеджеры”, такие как QuickDraw, менеджеры событий, окон, меню. Все, что не вошло в тулбокс, – файловая система, управление памятью, взаимодействие с внешними и внутренними устройствами и т. п. – называлось системными утилитами.

Низкоуровневые системные утилиты писались на asm, языке ассемблера Motorola 68000. Кстати, вполне приличный язык, жалко, что он уже никому не нужен. Типичный ассемблер, но… Стоп. На asm я написал свою первую Mac’овскую программу.

Менеджеры тулбокса разрабатывались и доводились до совершенства на Apple Pascal, это объектно-ориентированная вариация Паскаля, разработанная Никлаусом Виртом и Ларри Теслером. Затем, превращенные Apple Pascal в машинный код (тот же asm, практически), части этого менеджера оптимизировались (по размеру) вручную. Вообще-то, это одна из строго запрещаемых практик – вносить изменения в машинный код – но иначе Mac’а бы не было.

Занимался выжиманием кода (без потерь функциональности) Энди Херцфелд. Это чем-то напоминает перегонку спиртосодержащих жидкостей… В некоторых случаях, в результате “ректификации”, исполняемый код был уменьшен в 3-4 раза. Эзотерическая практика. Это требует, причем одновременно, педантизма и творчества.

Плюсы очевидны: огромную по объему тучу программного обеспечения втиснули в тесную реальность недорогого компьютера. Минусы, я думаю, тоже понятны. Представьте себе, что в тщательно отлаженный код на Паскале потребуется внести серьезное изменение, а такое случается в каждом сложном проекте… Целый модуль, а то и вообще всё заново!

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

Эзотерическую практику вспомнили при разработке Ньютона. Роль Apple Pascal играл Dylan, роль asm – C++.

Значительную часть сжатого кода планировалось разместить на микросхеме ПЗУ. Такой код постоянно доступен (не требует загрузки в оперативную память) и не занимает места на диске. Объем памяти микросхемы ПЗУ должен был составить 64K.

Минусы очевидны: для снижения цены, микросхема ПЗУ с зашитым в ней кодом должна выпускаться огромными тиражами. При выявлении серьезной проблемы исправить её на микросхеме невозможно. Только выпустить заново. Дорого, но и это еще не всё. Даже собрать новый образец для тиражирования – задача не одного дня.

А что делать с “плохими” микросхемами? Заставить тех, кто уже купил Mac, тащить его к дилеру? Или пользователь должен собственноручно выдирать старую микросхему и впаивать на её место новую?

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

QuickDraw

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

QuickDraw не просто рисовала, она заставляла элементы интерфейса реагировать на действия пользователя: объекты на экране мерцали, меняли “цвет”. После многократной оптимизации и сжатия (вручную) QuickDraw занимала совсем немного места. Меньше, чем какой-нибудь калькулятор в наши дни. Большая часть QuickDraw располагалась в ПЗУ.

Билла привел в Apple Джеф Раскин, человек, которого считают “отцом Mac’а”. Аткинсон во время учебы в университете записался на курс лекций Джефа Раскина о теоретических основах графического пользовательского интерфейса. Важнейшей частью графического интерфейса, естественно, является графическая библиотека. В лекциях Раскина такая библиотека называлась QuickDraw. Графическую библиотеку Mac’а Билл назвал в честь Джефа Раскина.

С первым Mac’ом поставлялись две программы – MacPaint и MacWrite. MacPaint, вообще-то, Билл Аткинсон написал для тестирования и отладки графической библиотеки.

Аткинсон разрешил (!) компании распространять его MacPaint, если за него Apple не будет брать деньги. Apple согласилась. Вот он какой, стальной оскал капитализма!

Последние дни проекта Macintosh

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

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

Джобс внимательно выслушал всех и сказал “За несколько недель вы не успеете сделать то, что не доделали за месяцы работы. Mac надо выпускать, сейчас или никогда. Со всеми недостатками, которые у него есть и которые не удастся исправить в ближайшие дни”.

В самый последний день, в 7:00 утра, за образцом для тиражирования на ПЗУ должен был приехать курьер. После этого момента у команды наступал недельный отпуск.

Последний баг был обнаружен в 6:30 того исторического утра.

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

Джобс, в 7 утра примчавшийся в офис, ознакомился с проблемой и, сказав “всем спасибо”, отправил команду отдыхать до 24 января. Первые пользователи с первые месяцы нашли в Mac’е множество проблем, но эту, последнюю, так и не заметили.

То, что стало известно как System Software 1.0, на самом деле в команде считалось очень поздней бета-версией, 0.97.