to post messages and comments.

Эмпирически выясняю, что нужно, чтобы запустить приложения под YellowBox, по возможности не устанавливая их. Самый свежий — это WebObjects, проверяю на нём. Опытным путём установлено, что перед тем, как запускать программы, нужно запустить все 4 служебных процесса в таком порядке:
%NEXT_ROOT%\Library\System\machd.exe -d
%NEXT_ROOT%\Library\System\nmserver.exe -d
%NEXT_ROOT%\Library\System\WindowServer.exe
%NEXT_ROOT%\Library\Frameworks\AppKit.framework\Resources\pbs.exe

Причём, обычный установщик YellowBox ставит первые два как службы (также можно вручную установить ключиком -install с правами админа) с указанием зависимости, а последние два — ставит в автозагрузку каждому пользователю, отсюда и их порядок после служб. Между последними двумя порядок либо не критичен, либо они как-то ждут друг друга, тут сложно понять. Ключик -d позволяет запустить службы как обычные процессы, таким образом, не требуя прав админа.

С точки зрения возможности выбрать в качестве кроссплатформенного движка не какой-нибудь дебильный Qt, Gtk+ или ещё куда ни шло VCL, wxWidgets и иже с ними, а всё же что-нибудь, основанное на спецификации OpenStep, это фиговенький, но всё же вариант для Windows. Сдаётся мне, Cocotron-то во многом получше будет, но там инструменты разработки кросскомпилируют с Mac OS X, да ещё с каким-то движком Objective-C, будто бы отличным от всех остальных, которые можно найти в природе. Что касается GNUStep, то эти ребята, когда я прочитал, как они «сделали» ARC, у меня просто волосы дыбом встали. Они додумались Boehm GC впихнуть в движок для всех программ без разбора. Если оно там теперь так и осталось неизвлекаемое, GNUStep начиная с этого момента можно считать безнадёжно сломанным, непригодным для серьёзной разработки. Надо отследить ревизию, в которой эти умники насвинячили, игнорировать всё, что было после, а то вдруг там начали появляться программные ошибки, а я считаю циклы владения безусловно программными ошибками, нарушением причинности, и, может быть, в таком виде от GNUStep ещё будет какая-то польза.

Необходимость разрабатывать кроссплатформенно плюс плохое качество библиотек, обычно берущихся для этого, плюс проблемы с реализациями OpenStep на не-Windows платформах — всё это поспособствовало тому, что я надолго ушёл из фронтенда на сервера и никак не могу вернуться, кроме как заработков на Delphi VCL Windows. А хочется.

Посравнивал даты файлов AppKit.dll, если установить OPENSTEP/Enterprise 4.2.4, WebObjects 4.0.1.3, YellowBox 5.1
Раньше мне казалось, что их развитие было именно в таком порядке, ведь в WebObjects 4.0.1 вроде бы как YellowBox 1.0, a 5.1 > 1.0. Но по датам получается следующее:
OPENSTEP/Enterprise 4.2.4 (Bastion5U1) : NextLibrary\Executables\AppKit.dll 1997-03-26
YellowBox 5.1 (Pluto1W1) : Library\Executables\AppKit.dll 1998-05-05
WebObjects 4.0.1.3 (Picasso2Z) : Library\Executables\AppKit.dll 1999-02-23

И это замечательно объясняет, почему версия SokoSave, собранная для WebObjects, не пашет под YellowBox.

Если просто взять и в Safari 5.1.7 for Windows целиком подменить Apple Application Support на новый из iTunes, оно не работает. По отдельности подменять objc.dll, CoreFoundation.dll, Foundation.dll получается, но вкладки начинают падать. Если попытаться подменить JavaScriptCore.dll и WebKit.dll, не запускается.

Удалось найти Mac OS X Server 1.0, в комплекте с которым на CD разработчика были WebObjects 4.0.1 и Yellow Box 1.0 для Windows (хотелось бы 5.1, но всё же это новее, чем OPENSTEP Enterprise for Windows), вот только без серийника нормально не поставить, можно только разпаковать. Кстати, похоже, это тот переломный момент, когда внутриэппловские фанбои Java настолько вдохновились, что переписали TextEdit с Objective-C на Java, благо у них мост между этими языками вплоть до Mac OS X 10.4 официально поддерживался. В OE/W ещё версия на Objective-C, а тут — на Java.
Против своей воли они всё-таки доказали, что производительность Java как была шлаком, так и остаётся, и пришлось, чтобы не позориться, TextEdit вернуть на рельсы Objective-C, и так оно и стало в современных Mac OS X.

Mежду SOM и Java такого же красочного сравнения не было, хотя одна из причин, по которым SOM перестали заниматься, это, как я предполагаю, ощущение, что Java решит все проблемы, которые раньше решали COM и SOM. Если бы не это ощущение, то Microsoft не удовлетворился бы ущербными COM, Java или .NET'ом, а слизнул бы SOM к себе в Windows в официальную поставку.

Ещё одна вещь, за которую Apple стоит сказать спасибо — это проваленный эксперимент со сборкой мусора в Objective-C. Видимо, фанбои сборки мусора в какой-то момент продавили своё решение, мол, ну пусть Java тормозная, но хоть Objective-C со сборкой мусора вдруг нормальным будет, ведь надо же иногда верить в чудеса. При этом трезво мыслящих людей в Apple хватило, чтобы не сделать это решение безповоротным.
Поступили довольно чисто: есть у исполняемых файлов пометка, нужен ли им сборщик мусора или хватит обычного счётчика ссылок, и если никому не нужен, то, как и раньше, действует счётчик ссылок.
Посмотрели, поигрались, и, судя по тому, что в очередной версии компилятора появился Automatic Reference Counting (аналог того, как Delphi обращается с COM интерфейсами), приняли единственно верное решение, послать эту сборку мусора и её фанбоев куда подальше. Нельзя не отметить мудрость инженеров в этом вопросе. Не всем дано признавать свои ошибки. Судя по тому, как поздно и как криво появился Windows Runtime (чем–то аналогичен SOM) и C++/CX (чем–то аналогичен DTS C++), у Microsoft длина тормозного пути на порядок больше (15 лет вместо 1.5).

А вот товарищи из Netlabs, которые проектировали NOM, видимо, не учли исторический опыт вклинить Java ну хоть на полшишечки, раз сделали сборку мусора изначально безальтернативной.