Чтобы добавлять сообщения и комментарии, .

@OCTAGRAM:
OCTAGRAM

Посравнивал даты файлов 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.

@OCTAGRAM:
OCTAGRAM

octagram.name
Ну вот, теперь моя коллекция YellowBox полна. Кроме 5.1 DR2, наверное, ещё 5.0 DR1 не хватает, но, мне кажется, разница не столь разительна.

@OCTAGRAM:
OCTAGRAM

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

@OCTAGRAM:
OCTAGRAM

Удалось найти 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 ну хоть на полшишечки, раз сделали сборку мусора изначально безальтернативной.