Ранее я часто рассказывал об особенностях видеокарт из 90-х. В рамках прошлых статей, мы успели с вами рассмотреть внутреннюю архитектуру 3dfx Voodoo, узнать о кастомном графическом API в S3 ViRGE, и даже написать свою собственную небольшую демку под видеокарты из 90-х. Вместо рассказов о GeForce 256 и ATi 3D Rage, в сегодняшнем материале мне хотелось бы поговорить о видеокарте, которая обогнала своё время — и при этом всё равно провалилась. Как вы уже поняли — речь пойдет об Intel i740.

Каким был первый GPU от Intel, на что он был способен и в чём заключается его главная тайна — читайте в сегодняшней статье!

❯ Предисловие

История видеоускорителей Intel начинается, как это ни странно, с программ космических симуляций. Первые наработки 3D-ускорителей разрабатывали ещё в 70-х годах в стенах компании GE Aerospace, однако в 1992 году, General Electric решили продать своё аэрокосмическое подразделение компании Martin Marietta, которое в 1995 году стало называться Lockheed Martin. После появления PlayStation 1 и массовых игровых автоматов с 3D-графикой, было очевидно что рано или поздно 3D станет мейнстримом и в сегменте домашних компьютеров, а пока конкуренция была ещё достаточно мала, Lockheed Martin решила организовать подразделение под названием Real3D.

По сути, в 1995 году из конкурентов у Real3D была только Nvidia со своим мультимедийным акселлератором NV1 и... PowerVR с GPU Midas 3. Но NV1 не был просто 3D-ускорителем — это целый комбайн, который включал в себя контроллер геймпадов от SEGA Saturn, звуковую карту, 2D-ускоритель для GDI/DDraw-игр и, собственно, 3D-ускоритель. Стоил NV1 целых 300$ и его самая главная фишка в лице 3D-ускорителя оказалась полным провалом: дело в том, что по каким-то причинам инженеры Nvidia решили построить растеризатор на базе квадов, а не общепринятых треугольников. Из-за этого разработчикам приходилось серьезно переписывать рендереры своих игр, поэтому на NV1 вышло всего 6 игр. Кроме того, NV1 оперировал не классическими UV-координатами, а специальными «весами», которые диктовали GPU как правильно наносить текстуру на примитив.

Как и NV1, PowerVR Midas 3 был тоже прорывным и в некоторой степени экзотическим GPU. В отличии от чипа от Nvidia, он оперировал классическими треугольниками, однако растеризатор здесь работал по принципу TBDR — Tile Based Deffered Renderer. Если говорить простыми словами, то видеокарта разбивала экран на набор тайлов размером 32x32 каждый, считала видимость и перекрытие всех рисуемых в тайле треугольников и затем отсылала их растеризатору. Таким образом, Midas 3 очень сильно экономил филлрейт за счёт отсечения невидимых поверхностей, не требовал тяжелого Z-буфера и заметно снижал нагрузку на общую шину с видеопамятью. Однако TBDR очень не любит полупрозрачные поверхности, а также геометрию с альфа-тестом, поэтому производительность Midas 3 значительно падала при отрисовке заборов, решеток и прочих объектов с полностью прозрачными пикселями. К слову TBDR в отличии от квадов живёт и сегодня и применяется даже в вашей RTX5090, а GPU от PowerVR сильно повлияли на успех первых iPhone (причём MBX был прямым наследником Midas 3).

Поэтому в 1995 году, Real3D совместно с Intel и Chips (читатели, заставшие 386/486, сразу поймут что это за компания) начали разрабатывать потребительский GPU под кодовым именем Auburn. Главной фишкой Auburn была новая шина AGP, созданная специально для видеокарт. Концептуально и электрически AGP был практически идентичен PCI: использовалась всё та же параллельная шина (за исключением того, что AGP не делил линии с другими устройствами как PCI) с теми же логическими уровнями, на программном уровне AGP-устройства использовали регистры PCI-контроллера и PCI-й же Configuration Space, а регистры и память самого GPU точно также маппились в адресное пространство процессора с помощью MMIO. Однако AGP добавлял ещё несколько важных фишек:

• Возможность передачи данных как по восходящему, так и по спадающему фронту — как в DDR. Это позволяло передавать данные в два раза быстрее без фактического увеличения скорости шины, которая в первых версиях работала на частоте в 66МГц — x2 от PCI.

• Технология GART, позволявшая замаппить кусок RAM для совместного использования GPU и CPU. Таким образом, GPU мог читать текстуры не только из собственной видеопамяти, но и из оперативной — что по теории Intel должно было решить проблему недостатка дорогой EDO-памяти для текстур и заметно удешевить видеокарты.

Как вы уже могли понять, основной упор в Auburn решили сделать на поддержку технологии GART. Суть её была такой, что на видеокарте располагается лишь минимальный объём видеопамяти (~4МБ) для хранения фреймбуфера и Z-буфера, в то время как для хранения текстур предполагается использовать системную память. Теоретически этот способ помогал заметно разгрузить шину GPU — VRAM в процессе растеризации, при этом распараллеливая обращения к текстурам через контроллер памяти в северном мосту. На бумаге это звучало хорошо...

❯ Разбираем архитектуру

Архитектура видеокарт в 90-х заметно отличалась от современных. Во первых, в GPU тех лет конвейер был фиксированным: все возможные операции по освещению, наложению тумана и текстурированию были заранее реализованы в железе и возможности вручную посчитать цвет фрагмента не было. Некоторым подобием шейдеров была возможность мультитекстурирования, которая позволяла за один проход наносить несколько текстур одновременно с разными операциями: например можно было наложить основную текстуру, маску и сферическую карту отражений, что позволяло сделать модельку машины, где кузов отражается, а матовые элементы — нет. Первой видеокартой с поддержкой мультитекстурирования была 3dfx Voodoo 2, однако там возможность нанесения нескольких текстур за один такт зависела от числа TMU — текстурных юнитов на видеокарте.

Во вторых, вплоть до GeForce 256 в видеокартах вообще не было вершинного конвейера. Вы же помните слова о том, что видеопамять используется только для фреймбуфера, а оперативная — для текстур? Так вот, в те годы видеокарты не хранили в себе геометрию и никак её не обрабатывали, ожидая на вход уже готовые и преобразованные треугольники. Таким образом, вся нагрузка по трансформации треугольников, перспективному делению, повершинному освещению и клиппингу (разбиения частично видимых треугольников «перед носом» на несколько более мелких) ложилась на центральный процессор, в то время как GPU оставалось лишь это всё растеризовать (и именно отсюда растут корни glBegin/glEnd). В GF256 уже появилась поддержка T&L и возможность размещать вершинные буферы в видеопамяти, что позволило уже через 2-3 года кратно увеличить полигональность моделей в играх.

Auburn, уже под финальным названием Intel i740, появился в начале 1998 года и должен был конкурировать с новым ATi Rage 128. На первый взгляд, это был суперсовременный и доступный GPU на момент выхода:

• В i740 был встроен 2D-ускоритель с аппаратным ускорением GDI и DirectDraw, поддержкой разрешения до 1280x1024 при 16-битном цвете и поддержкой как VGA, так и NTSC/PAL для вывода изображения на телевизор.

• Помимо 2D-ускорителя, в GPU был также аппаратный декодер DVD. Это уже очень серьезная заявка на успех с учетом того, что не каждый процессор в те годы мог программно декодировать MPEGII.

• 3D движок поддерживал все современные на тот момент возможности: Z-буфер, MSAA, затенение по методу Гуро, попиксельный туман, альфа-блендинг, альфа-тест, дизеринг, трилинейную фильтрацию. Из текстурных форматов поддерживалась палитровые, 1555, 565 и 4444 — никаких 24 и тем более 32 битных текстур.

• На бумаге GPU работал на частоте в 133МГц, имел приличный филлрейт в ~55 мегапикселей, мог растеризовывать до ~350к треугольников в секунду (или около 11к треугольников на один кадр — это не так мало, как кажется. В HL ~4к треугольников на кадр к примеру).

• И самое главное — никаких собственных GAPI, полный ориентир на OpenGL и Direct3D.

Всё это было выполнено на техпроцессе в 350нм и при скромной розничной цене в 120$. Звучит как что-то невероятное, однако на практике FPS в играх был не особо высокий из-за использования GART: видеокарте постоянно приходилось бороться с процессором за возможность доступа к оперативной памяти, из-за чего страдала пропускная способность как со стороны GPU, так и со стороны процессора. Добавьте к этому невысокую частоту FSB и самой SDRAM и получаем просадки растущие не только от объёма геометрии в кадре, но и количества наносимых текстур, благо i740 не поддерживал мультитекстурирование.

Очевидно что в 1998 году, большинство 3D-акселлераторов проектировались как игровые и i740 стал провалом в геймерском сегменте из-за невысокого FPS в играх. Ситуация становилась ироничной из-за того, что Intel выпустила специальную PCI-версию, для которой отдельно разработала чип-мост, перенаправляющий обращения к GART с северного моста на дополнительные чипы SGRAM распаянные на плате. PCI-версия стоила значительно дороже и нивелировала все плюсы i740, хоть и работала в играх чуть быстрее, что иронично.

Однако огромным плюсом были адекватные драйвера для OpenGL и Direct3D. До 1998 года, большинство видеокарт были ориентированы в первую очередь на свои собственные проприетарные графические API — у 3dfx был Glide, у S3 — Metal (не тот что у Apple), а у ATi — CIF, в то время как i740 был ориентирован на стандартные API. При этом все три API взваливали задачу написания аллокатора текстур, математической библиотеки и вершинного конвейера на программиста, что заметно увеличивало порог входа для разработки 3D-игр. У GL и D3D же это всё было готово «из коробки», благодаря чему большинство игр уже в 1999 году перешли на DirectX. Для понимания почему так произошло — окромя Nvidia, ни у одного производителя GPU в 90-х не было адекватных драйверов для OpenGL. У 3dfx был обрубок под названием MiniGL специально для Quake, у ATi драйвера были кривыми вплоть до ~2001 года, а у S3/SiS вообще всё с этим было максимально плохо, поэтому и победил DirectX.

Ещё одна причина почему победил в DirectX

Во времена DirectX 6 было два режима D3D — Immediate и Retained. Immediate больше всего похож на современные графические API, поскольку сразу оперировал программными командными буферами, и аппаратными вершинными/индексными буферами, что позволило прозрачно для игр использовать T&L и заметно поднять их производительность.

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

Касательно конкретных фишек у i740 всё тоже было не идеально. Во первых, как я и говорил ранее, i740 не имел поддержки мультитекстурирования, что требовало двухпроходной отрисовки уровней — сначала геометрия с текстурой, затем та же самая геометрия с лайтмапой. Больше всего это было актуально для Half-Life и Quake. Во вторых, i740 не поддерживал Stencil-буфер и соответственно стенсильные тени в реальном времен. Можно было только очень костыльно реализовать самые примитивные Shadowmap'ы без фильтрации, но выглядели они отвратительно.

И в третьих — i740 не поддерживал текстурную компрессию, которая позволила бы заметно выиграть в производительности. Дело в том, что блочные алгоритмы типа DXT позволяют хранить блок из 16 пикселей всего в 8 байтах (двух машинных словах) и отлично кэшируются, что помогло бы разгрузить шину... но имеем что имеем. В играх i740 показывал себя в целом очень даже неплохо, но уступал решениям от ATi и Nvidia, а ещё по каким-то причинам GPU не использовался в ноутбуках (скорее всего из-за отсутствия поддержки LVDS).

Результаты в играх были неплохими, но не более того. В Quake 3 i740 в AGP-версии выдавала солидные 30 FPS (а PCI-версия всего 20), в то время как в Quake 1 кадровая частота местами подлетала почти до 50 FPS. В Carmageddon II приходилось наслаждаться 20-22 FPS на обеих версиях, зато Mortal Kombat 4 шел в 50 на PCI версии и 60 на AGP. В MS Flight Simulator 98, i740 вытворял чудеса и выдавал более 60 FPS - это уже FPS уровня современного геймера.

Несмотря на все свои недостатки, i740 не отправился в помойку: несмотря на провал на розничном рынке, i740 стоил очень недорого на оптовом для OEM, что и обеспечило ему большую популярность в готовых сборках. А годом позднее, GPU был интегрирован в чипсет Intel i810, где и раскрыл свой бюджетный потенциал во всю. Его основными конкурентами стали SiS Mirage Graphics на базе SiS 6326 (обычно была слабее Intel'ов), VIA Unichrome на базе легендарного S3 Savage, и такая экзотика, как Trident CyberBLADE XP. В 2004'ом, Intel выпустила современный и относительно крутой GPU под названием GMA900 с поддержкой Direct3D9 и продвинутым шейдерным конвейером, но... об этом как-нибудь в другой раз.

❯ Заключение

Вот такой была первая видеокарта от Intel. И, судя по всему, из года в год Intel повторяет историю точь в точь: разрабатывают продвинутый GPU с поддержкой всех современных технологий, но спотыкаются об использование RAM в качестве основной памяти и кривоватые драйвера. Хотя сейчас с появлением Intel Arc ситуация кратно улучшилась. А что вы думаете о GPU от Intel? Пишите своё мнение в комментариях!

В будущем хотелось бы написать статью про что-то из Trident'ов, PowerVR, Trident'ов или ранних 3dfx, но к сожалению пока возможности купить их нет. Но там будь что будет :)

Ну а я надеюсь, что вам было интересно. Подписывайтесь на блог, чтобы не пропускать новые статьи каждую неделю! А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статьи) можно найти на моём YouTube канале.

А если вы хотите что-нибудь подарить из железа и увидеть о нём статью — пишите мне в Telegram. Меня очень интересуют самые разные гаджеты: начиная от игровых консолей и любых связанных с геймингом устройств, телефонов, смартфонов, КПК, заканчивая ретро-компьютерами и ноутбуками. Кто знает, может героем следующей подобной статьи окажется ноутбук из 90-х? :)

После обзоров устройства не продаются, а остаются в моей коллекции. Когда-нибудь я хочу сделать музей, где к каждому устройству можно будет приложить QR и почитать мою статью. Кто знает, вдруг на следующей неделе я также подробно расскажу про девайс из вашей юности? :)

Кстати, у меня есть GameBoy Advance SP, под который я очень хочу написать игру. Однако мой экземпляр был залит водой и кофе. Может у кого-то есть донор с дохлой платой, откуда я смог бы взять контроллер питания? У меня AGS-101.

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

Новые модели от Hisense

На презентации продемонстрировали несколько моделей новой линейки — UR8S, UR9S и флагманский Hisense 116UX.

Особенность новинок — технология RGB MiniLED. Теперь телевизор точнее управляет цветом и светом, поэтому изображение выглядит ярче, контрастнее и естественнее.

Менеджер по продуктам ТВ- и аудиокатегории Hisense Шон Ли:

«Запуск технологии RGB Mini-LED на российском рынке является новым этапом в развитии Hisense. Мы задали новый стандарт визуального опыта, который уже получил признание на глобальном уровне».

Больше всего внимания собрал Hisense 116UX. Это телевизор с трехметровой диагональю. На таком экране особенно хорошо заметны детали: яркие сцены остаются насыщенными, темные — глубокими, а изображение выглядит объемным и живым. За качество картинки отвечает фирменный процессор Hisense, а встроенная многоканальная акустика создает эффект домашнего кинотеатра без дополнительных колонок.

Вместо лекций — живое общение

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

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

Линейка уже поступила в продажу. Доступны модели UR8S в нескольких размерах экрана, серия UR9S и флагманский 116UX. Телевизоры можно приобрести у крупных российских ритейлеров и на популярных маркетплейсах.

Привет! Это Dessly!

🎯 Независимая студия Leyline собрала команду из бывших ведущих дизайнеров Hearthstone и авторов The Bazaar. Их новый проект — Guildrun, одиночный автобатлер с рогалик-элементами, релиз которого намечен на конец 2026 года.

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

Это не просто битва, а полноценное расследование с собственным сюжетом.

Напоминаем, что пополнить баланс Steam быстро и без лишних сложностей можно через Dessly.com

👉 Dessly делает процесс пополнения Steam кошелька максимально удобным, быстрым и безопасным!

Свобода экспериментов и гибкая прокачка

🎯Разработчики намеренно отказались от PvP, поэтому вам не придётся гнаться за модными стратегиями и копировать чужие билды. Каждое прохождение генерируется случайно — меняются герои, бонусы и события, что поощряет смелые эксперименты.

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

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

Что уже можно опробовать и почему играть комфортно

🎯Уже сейчас доступна демоверсия, в которую заложили приличный объём контента: 25 героев, 180 специализаций, свыше 300 реликвий и больше 100 предметов. Этого хватит, чтобы оценить глубину настройки и понять, затягивает ли механика.

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

Такой подход оценят те, кто любит вдумчивость и не терпит спешки.

Будущее игры: сложность, бесконечный режим и поддержка

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

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

Где и на каком языке играть

🎯Guildrun выйдет исключительно на ПК в Steam. Для русскоязычных игроков подготовлен текстовый перевод на русский язык, так что разбираться в тонкостях прокачки и сюжета будет легко даже без знания английского.

🔥 Не тяни кота за подписку — жми "Подписаться" прямо сейчас! → VK Dessly

О чем речь

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

Даже краткая аннотация из википедии легко вгоняет в диссонанс современных MacOS‑разработчиков:

GNUstep — свободная реализация Cocoa (ранее OpenStep) — объектно-ориентированного API (Objective-C) для объектно-ориентированных операционных систем.

Objective‑C (основной язык разработки под MacOS и iOS) и свободная реализация Cocoa (главный UI/UX фреймворк Apple) — расскажите об этом типичному разработчику под Mac, потратившему несколько тысяч долларов на покупку железа Apple и платную подписку на XCode, увидите как у человека начинается нервный тик.

Еще можно троллинга шутки ради сдать тестовое задание на позицию «MacOS Developer»:

#import <AppKit/AppKit.h>
int main(int argc, const char *argv[])
{
return NSApplicationMain (argc, argv);
}

Код выше ничем не отличается от стандартного main() на обычном маковском Objective-C, при этом никакого отношения к Apple и MacOS не имеет.

Даже если немного усложнить и углубиться в реализацию:

@implementation CalcBrain: NSObject
-(id) init
{
[super init];
result = 0;
enteredNumber = 0;
operation = none;
fractionalDigits = 0;
decimalSeparator = NO;
editing = YES;
face = nil;
return self;
}

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

Вот так выглядит «showcase» GNUStep — тестовое приложение с демонстрацией функционала:

История

Разумеется история появления такого чуда не менее прекрасна и удивительна:

Проект был начат Паулем Кунцем (Paul Kunz) с командой из Стенфордского Центра линейного ускорителя (Stanford Linear Accelerator Center) которым был нужен порт HippoDraw из NeXTSTEP на другую платформу. Вместо того, чтобы переписывать программу с нуля, используя ее архитектуру, разработчики решили переписать слой NeXTSTEP, от которого зависело приложение. Это была первая версия libobjcX.

Именно так выглядит настоящий хардкор в разработке:

взять и переписать часть операционной системы ради портирования одного приложения.

«Как тебе такое, Илон Маск?» (ц)

Справедливости ради стоит заметить, что в те былинные времена графические библиотеки были сильно проще, а само действо происходило в «закрытом НИИ» и на государственные гранты. Что конечно несколько отличается от современных потогонных реалий и перегретого рынка разработки ПО.

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

Разрыв шаблона номер один

На дворе далекий 1994й год, времена модемов, досок BBS, ФИДО и первых персональных компьютеров.

А кое-где уже cуществовал самый настоящий Graphical Interface Builder:

Вот в качестве иллюстрации снимок с ЭЛТ монитора тех лет:

Это не шутка, самый настоящий конструктор интерфейсов был реализован еще в далеком 1988 году:

Gorm (Graphical Object Relationship Modeller) is a graphical user interface builder application. It is part of the developer tools of GNUstep. Gorm is the equivalent of Interface Builder that was originally found on NeXTSTEP, then OPENSTEP, and finally on Mac OS X. It supports the old .nib files as well as its own .gorm file format.

Был создан и работал задолго до рождения большинства читающих сейчас эту статью. Вот вам для иллюстрации еще один снимок тех лет, с местной «косынкой»:

А теперь внимание на даты:

A preview release of NeXTSTEP (version 0.8) was shown with the launch of the NeXT Computer on October 12, 1988

Мне тогда было 5 лет а на дворе был Советский Союз. Для сравнения, вот так примерно в те времена выглядел весь софт в СССР а затем и в РФ:

Так что шаблон «раньше был страшный черный MS DOS и текстовые интерфейсы» только что треснул.

Еще один замечательный и интересный пример:

Видите на снимке выше открытый текстовый документ, с разными шрифтами, кернингом и лигатурой?

Как бы это не было удивительно, но данный функционал был реализован невероятно, даже шокирующе давно — вот так выглядел в 1988 году его далекий предок:

Расширение файла .wn не что иное как формат текстового процессора WriteNow:

WriteNow is a word processor application for the original Apple Macintosh and later computers in the NeXT product line. The application is one of two word processors that were first developed with the goal that they be available at the time of the Mac product launch in 1984, and was the primary word processor for computers manufactured by NeXT.[2

Так что корни современных текстовых процессоров уходят невероятно далеко в прошлое, дальше чем вы думали.

Разрыв шаблона номер два

Компания NeXT давно закрыта, никакие ее продукты уже давно не продаются, даже само API OpenStep — фактически заброшено, а «свободная реализация» в виде GNUstep на сегодняшний день выглядит как оживший труп из далекого прошлого.

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

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

Windows Bridge for iOS (codenamed "Islandwood") is an open-source middleware toolkit that allows iOS apps developed in Objective-C to be ported to Windows 10 by using Visual Studio 2015 to convert the Xcode project into a Visual Studio project.[7][9][10] An early build of Windows Bridge for iOS was released as open-source software under the MIT License on August 6, 2015, while the Android version was in closed beta.[7]

This "WinObjC" project is open source on GitHub. It contains code from various existing implementations of Cocoa Touch like Cocotron and GNUstep as well as Microsoft's own code that implements iOS frameworks using UWP methods. It uses a version of the LLVM clang compiler.[11]

Вот такие дела: Microsoft использовал исходный код GNUStep для создания конвертера проектов XCode под Windows. Причем проект очень даже живой.

Но выглядит это.. весьма своеобразно:

Сборка и запуск

Праздник «старой школы» был бы неполным без рассказа о том как собрать и запустить GNUstep своими силами.

Для написания статьи использовался Mageia Linux, но инструкции актуальны и для всех других дистрибьютивов и ОС.

Поскольку проект GNUstep находится в полузаброшенном состоянии, не стоит пытаться ставить его из пакетов — в большинстве дистрибутивов эти пакеты не имеют ментейнера и присутствуют «для галочки», просто потому что собираются.

Вместо этого, мы соберем GNUstep непосредственно из исходников.

tools-make

Начать придется со своей специфичной и уникальной системы сборки:

The makefile package is a simple, powerful and extensible way to write makefiles for a GNUstep-based project. It allows the user to write a project without having to deal with the complex issues associated with configuration, building, installation, and packaging. It also allows the user to easily create cross-compiled binaries.

Да, я тоже был удивлен, но наверное не так сильно, поскольку многие старые проекты (например оригинальный CDE) имеют собственные системы сборки.

Забираем это чудо:

git clone https://github.com/gnustep/tools-make.git

Собираем:

cd tools-make
./configure --prefix=/opt/gnustep
make
make install

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

Еще это означает, что придется добавлять путь /opt/gnustep в переменные окружения, либо в LD_LIBRARY_PATH либо в PATH:

export PATH=/opt/gnustep/bin:$PATH

libs-base

Следующим шагом собираем commons — общую библиотеку классов:

The GNUstep Base Library is a library of general-purpose, non-graphical Objective C objects. For example, it includes classes for strings, object collections, byte streams, typed coders, invocations, notifications, notification dispatchers, moments in time, network ports, remote object messaging support (distributed objects), and event loops.

Стоит помнить, что речь идет об использовании этих библиотек для сборки, поэтому необходимо устанавливать версии пакетов «для разработчиков» — с заголовочными.h файлами.

Забираем исходный код проекта:

git clone https://github.com/gnustep/libs-base.git

Запускаем сборку:

./configure --prefix=/opt/gnustep
make
make install

libs-gui

Следующий шаг — сборка еще одной общей библиотеки, в этот раз графической, отвечающей за интерфейс:

The GNUstep gui library is a library of graphical user interface classes written completely in the Objective-C language; the classes are based upon Apple's Cocoa framwork (which came from the OpenStep specification). These classes include graphical objects such as buttons, text fields, popup lists, browser lists, and windows; there are also many associated classes for handling events, colors, fonts, pasteboards and images.

Каких-либо проблем с этими библиотеками не было, поскольку они все старые и очень стабильные. Забираем исходники:

git clone https://github.com/gnustep/libs-gui.git

Собираем:

./configure --prefix=/opt/gnustep
make
make install

libs-back

Еще одна библиотека, в этот раз — с реализацией «бекэнда» графического рендера. Забираем исходный код:

git clone https://github.com/gnustep/libs-back.git

Собираем:

./configure --prefix=/opt/gnustep
make
make install

Перед запуском конечных приложений на GNUstep необходимо выполнить:

defaults write NSGlobalDomain GSBackend libgnustep-xlib

Эта команда установит бекэнд по-умолчанию, сама настройка будет сохранена в каталоге ~/GNUstep

На этом сборка самого фреймворка GNUstep завершена и можно наконец запускать примеры.

Примеры

Выложены в официальный репозиторий Github, вместе с самим проектом GNUstep, все примеры отлично собираются и запускаются.

Забираем исходники:

git clone https://github.com/gnustep/tests-examples.git

Каждый пример является отдельным проектом, собираемым через специфичный make GNUstep, поэтому для сборки необходимо иметь путь /opt/gnustep в переменной PATH.

Вот так выглядит в работе пример графического редактора:

Также стоит рассказать о еще двух интересных проектах из мира древних и усопших.

Gorm

Тот самый «interface builder», которым я столько восхищался в начале статьи:

Gorm (Graphical Object Relationship Modeller) is a graphical user interface builder application. It is part of the developer tools of GNUstep. Gorm is the equivalent of Interface Builder that was originally found on NeXTSTEP, then OPENSTEP, and finally on Mac OS X. It supports the old .nib files as well as its own .gorm file format.

В запущенном виде он выглядит как-то так:

И сейчас мы будем его собирать, забираем исходный код:

git clone https://github.com/gnustep/apps-gorm.git

Напоминаю про специфичный make для GNUstep и необходимость наличия /opt/gnustep в переменной PATH, сама сборка выполняется вот так:

make

К сожалению autotools для этого проекта нет, поэтому попытка использования make install приведет к установке в системный каталог /usr/lib, что разумеется не очень надо.

Поэтому для теста было решено запускать бинарник gorm сразу из места сборки:

export LD_LIBRARY_PATH=/opt/gnustep/lib:./InterfaceBuilder/obj:./GormObjCHeaderParser/obj:./GormCore/GormCore.framework/Versions/0
./Applications/Gorm/Gorm.app/Gorm

За что я конечно буду гореть в аду для программистов. Но потом.

Projectcenter: IDE для GNUstep

Да, у них в могиле есть даже свой собственный IDE:

IDE — Integrated Development Environment. PC manages code and builds applications, frameworks and libraries, use GORM for Interface editing.

И его тоже я смог собрать и запустить, выглядит в работе он как-то так:

Забираем:

git clone https://github.com/gnustep/apps-projectcenter.git

Сборка аналогична описанной выше сборке проекта Gorm, по тем же причинам я снова произвел «закат солнца вручную» для запуска:

export LD_LIBRARY_PATH=/opt/gnustep/lib:./Framework/ProjectCenter.framework/Versions/0.7.0
./ProjectCenter.app/ProjectCenter

Совместимость

После размещения статьи на ЛОРе, читатели задали интересный вопрос по поводу совместимости с оригинальной и современной Cocoa. Был взят минимальный пример и немного адаптирован:

#import <Cocoa/Cocoa.h>
int main()
{
[NSAutoreleasePool new];
[NSApplication sharedApplication];
[NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
id menubar = [[NSMenu new] autorelease];
id appMenuItem = [[NSMenuItem new] autorelease];
[menubar addItem:appMenuItem];
[NSApp setMainMenu:menubar];
id appMenu = [[NSMenu new] autorelease];
id appName = [[NSProcessInfo processInfo] processName];
id quitTitle = [@"Quit " stringByAppendingString:appName];
id quitMenuItem = [[[NSMenuItem alloc] initWithTitle:quitTitle
action:@Selector(terminate:) keyEquivalent:@"q"] autorelease];
[appMenu addItem:quitMenuItem];
[appMenuItem setSubmenu:appMenu];
id window = [[[NSWindow alloc] initWithContentRect:NSMakeRect(10, 10, 200, 200)
styleMask:NSTitledWindowMask backing:NSBackingStoreBuffered defer:NO]
autorelease];
[window setTitle:appName];
[window makeKeyAndOrderFront:nil];
[NSApp activateIgnoringOtherApps:YES];
[NSApp run];
return 0;
}

И.. оно заработало! Пусть и с минимальными переделками, но заработало.

Вот так выглядит запущенное приложение на Linux:

Современность

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

Но только все графические примитивы и паттерны использования, заложенные в GNUstep — устарели, слабо представляю как такой UI/UX возможно соотнести с современным использованием десктопа, даже профессионального.

А вы смогли бы пользоваться таким ПО каждый день?

Версия для.. Windows

Ну и наконец последний разрыв шаблона на сегодня:

вы можете легко и просто поставить GNUstep.. на Windows.

Вот так это выглядит в работе:

Даже готовый инсталлятор есть, так что ничего не помешает «прикоснуться к прекрасному с минимальными усилиями».

Эпилог

Разумеется как NEXTstep так и GNUstep ныне являются чистой историей, поскольку даже заложенные в них подходы к построению UI/UX — концептуально устарели. Устарели настолько, что пользоваться таким интерфейсом даже автору (видевшему многое) — откровенно тяжело.

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

Тем не менее, о существовании такого проекта стоит знать, хотя‑бы для понимания — насколько далеко в прошлое уходят корни современных технологий.

Но рабочие станции конечно были очень красивые, для тех-то лет:

P.S.

Статья была опубликована на Хабре, более трешевый оригинал которой доступен в нашем блоге.