Apple Windows10 iCloud Windows Обновил Windows до Падших Создателей.

Проверил, как там iCloud. Не работает. Всё так же, крутится индикатор после Войти, e-mail приходит о том, что мой Apple ID использовался для входа. Увижу ли я когда-нибудь, как эта штука работает? Windows 2003 ей была слишком старая. Windows 10, похоже, перманентно слишком новая. Удивительно просто, как столько лет не могут починить.

Apple Иран Apple удалила все иранские приложения из App Store

Представитель иранской компании Digikala — крупнейшего в стране сайта электронной коммерции — рассказал, что примерно десять дней назад работа приложений была прекращена. По его словам, приложение Digikala было удалено из-за "нового типа санкций, которые были наложены на Иран".

Терпилам с айфончиками остаётся только утереться.

Apple SOM Copland carbon HIObject На накосе смог открыть, наконец, образы Copland, которые не кололись 7zip’ом. SOM DTK там внутри не обнаружил, а это, например, IDL для SOMObject. Но системные IDL там были в изобилии. Однако, что показалось мне странным, многие из них не содержат описание классов. Там только структуры и обратные вызовы.

Но были и те, что с классами, например, всё, что начинается на HI. Это была интересная наводка. Я вспомнил, что в накосе для более лёгкого портирования была (и сейчас есть, но только для 32х бит) система библиотек Carbon. Теперь, когда в экосистеме классической макос мне известно что-то объектное, кроме OpenDoc, стало логичным посмотреть, а куда это делось в Carbon. В статье на Википедии про Carbon прочитал такое:

HIObject — a completely new object-oriented API which brings to Carbon an OO model for building GUIs. This is available in Mac OS X v10.2 or later, and gives Carbon programmers some of the tools that Cocoa developers have long been familiar with. Starting with Mac OS X v10.2, HIObject is the base class for all GUI elements in Carbon. HIView is supported by Interface Builder, part of Apple's developer tools. Traditionally GUI architectures of this sort have been left to third-party application frameworks to provide. Starting with Mac OS X v10.4, HIObjects are NSObjects and inherit the ability to be serialized into data streams for transport or saving to disk.

Но какой может быть «completely new» в системе библиотек, которые нужны только для портирования? Это осколок былого величия, наскоро сделанная замена SOM. Вместо somBuildClass — HIObjectRegisterSubclass, вместо somDataResolve — HIObjectDynamicCast и т.п. Кстати, доступ к полям через HIObjectDynamicCast значит, что это нехрупкое ABI. Также, через QuickTime SDK, HIObject попал и на Виндоуз тоже, в собственно плеер, Сафари и айТюнс.

Apple xcode Попробовал собрать приложение для теста (TextEdit) и обнаружил, что оно на Mac OS X 10.11 El Capitan даже не запускается, собрано под 10.12 Sierra. Ну ладно, подумал я, и попытался переключить SDK и цель на 10.11. А нету SDK для 10.11! Xcode может работать на 10.11, но собрать может только для 10.12.

Весь Xcode прежней версии качать неохота было, качнул только утилиты командной строки. Поставил. Поставились. Теперь компилятор для 10.11 есть. А SDK нету. Так уж и быть, качнул Xcode 7.3.1. Поставил. Теперь есть и компилятор, и SDK для 10.11. Но только для них (не считая забекапленной 10.12, конечно). Странно, а вроде раньше по-другому было. В те дни, когда я думал, что 10.6.8 — потолок, я поставил Xcode 3, и там были 10.4u, 10.5, 10.6, то есть, начиная от самой первой x86’ой до самой последней поддерживаемой. А тут одна.

Вычитал такое:

I can copy MacOSX10.11.sdk from another host, but presumably Apple has something else in mind here.
Just to be clear, Apple policy since Xcode 7 has been to only distribute the newest SDK with Xcode.app.

Так, теперь понятно, как Эппл пасёт чебурашек. Ставим разработчиков в дурацкое положение, когда они не могут просто взять и собрать для минимальной достаточной версии OS, как это делается на Windows, со слабым связыванием опциональных фич. Если не предпринимать специальных действий, если не писать на Delphi, C++ Builder или GNAT Ada, а именно из Xcode, то получаются приложения с неоправданно завышенными системными требованиями. Пользователи вынужденно обновляют ОС и/или железо, Эппл собирает кассу, разработчикам с этого пирога ничего не перепадает.

Однако нашёл ещё такое и такое. То есть, несмотря на ужимки Эппл, возможность собирать как лучше для людей имеется.

И это отличный источник входных файлов для BridgeSupport и анализатора, которым я также собираюсь прочесать GNUStep (до и после отравления TGC) и Cocotron на предмет пересечения. Где что появилось, где устарело, где изчезло. Пока что это мутная толща воды, и в неё надо забуриться.

Apple BridgeSupport Как же не люблю, когда всё пропадает из Интернета. Ну было же великое событие, появление BridgeSupport, до которого описание было только в заголовочных файлах Objective-C и не было аналога COM TLB, SOM.IR и т.п. Для Qt что-то такое уже было, для Gtk+ было, и только Cocoa была последней крепостью. И эта крепость пала. Всё это было в Mac OS X 10.5 Leopard, а у меня был Mac OS X 10.4 Tiger, но я следил за этими событиями, в частности, ставил MacPorts, и через него всё замечательно ставилось и на Тигре тоже. Недальновидные разработчики не могли придумать ничего лучше моста в Python и Ruby. Чуть более дальновидные на его основе сделали взамен устаревшего встроенного моста Cocoa-Java новый RoCocoa. И совсем то, что доктор прописал, было в первую очередь поступить с этой метаинформацией как в COM TLB, то есть, конечно же, привязки для Delphi и Ada, а уж потом всякие скрипты-шкрипты.

Apple ЭмуляцияCPU PowerPC Пока не установил МакОС, из которого выпилили эмуляцию PowerPC, я даже не подозревал, сколько у меня таких программ. Причём, каких! Игры!

Ricochet Lost Worlds, Marble Blast Gold, Luxor 2, Luxor Mahjong, Monster Fair Pinball, Nanosaur — всё это оказалось PowerPC. Кто говорил про обязательные нативные порты, теперь посрамлён. Можно пользоваться программами в эмуляции и даже не знать об этом, пока эмуляцию не отключат. А если не отключать, так и вообще хорошо.

Apple ElCapitan MacOSX Запарился мигрировать всё с Хакинтоша, на котором Ассистент миграции вообще не может в сеть (Mac OS X 10.4.10 Tiger). В принципе, там был порт FireWire, но какой с него толк для миграции, если на Хакинтоше нет Open Firmware и Эпловской разновидности EFI, в которую нужно загрузить донора. Короче, полный голяк. Некоторое время полюбовался на Mac OS X 10.6.8 Snow Leopard на купленном устройства. Там всё ещё узнаваемый стиль Аква и шрифт Lucida Grande. Антиалиасинг без хинтинга и мыла. Всё такое приятное, круглое, пластмассовое.

Сделать образ диска, с которого запущена операционка — это оказалась творческая задача. В Хакинтоше у меня два диска, и можно бекапить первый на второй. Очень мудро я в своё время поступил, разбив основной ЖД на кучу мелких разделов, хоть как-то себе жизнь облегчил. Ещё бы привод DVD никуда не делся, я б прямо с Хакинтошного DVD загрузился бы и Дисковой Утилитой сделал образ как надо. Но привода нет. А hdiutil в Single Mode не заработал. Пришлось dd'шечкой делать. На 10.6.8 образ в таком формате сходу не подключился (нет таблицы разделов), но его оказалось возможным сконвертировать, и этот сконвертированный уже работал лучше. Его подмонтировал, запустил Ассистент Миграции, выбрал вариант «с другого раздела», и этот виртуальный образ был в списке кандидатов.

Apple MacOSX macOS Этот макОС — какой-то новый Турбо Паскаль

Exception Type:        EXC_ARITHMETIC (SIGFPE)
Exception Codes:       EXC_I386_DIV (divide by zero)
Exception Note:        EXC_CORPSE_NOTIFY

SOLVED: My MacBook Pro didn't have a battery installed. I had to remove it b/c it got bloated one day. I installed a new battery and the upgrade didn't crash. Upgraded successfully to El Capitan.

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

Apple ПК Затарился макбуком. Пятый комп уже получается. Теперь смогу скомпилировать Cocotron и пощупать движок Objective-C 2.0. И заказов смогу больше принимать.

Apple YellowBox objectiveC Эмпирически выясняю, что нужно, чтобы запустить приложения под 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. А хочется.

Apple ComputeStick MacOSX Жаль, у Эпл нет официального решения в виде HDMI-свистка. Хотел пятый комп именно в таком формате взять попробовать, но по всему выходит, что если хочу там макос, то опять будет хакинтош.

@vt тут топит за то, чтоб я выбросил Мозиллу. А я бы и рад, но Сафари под Винду давно сдулся, а Эпл Мэйл и вовсе никогда не было.

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

Apple SOM Copland macOS SOM для Copland
Распаковал образы Mac OS 8.0 (кодовое имя Copland), — той, которая, как и Windows 95 должна была обновить ОС Макинтошей до современной, с вытесняющей многозадачностью. Но что-то с ядром у них не заладилось, и пришлось выпускать Mac OS 8.5 на базе старого ядра с кооперативной многозадачностью. Но если в обычной Mac OS был Apple SOM, то несколько лет назад я предположил, что и в Copland он автоматически прошёл. Сегодня проверил. Да, так и есть.

Вообще я ожидал найти средства разработчика и посмотреть IDL, но средств разработки на имеющихся образах не оказалось. Извлёк ядро SOM, посмотрел другие бинарники, видно, что они его подключают. Естественно подразумеваемая компонента операционной системы. Применительно к Copland никто и не заморачивался тем, чтобы про это написать.

Apple llvm objectiveC cocoa Я как–то проводил инвентаризацию, как бы теоретически можно было писать под Cocoa для Windows:
1. Реализация Cocoa берётся из iTunesInstaller.exe
2. Компилятор либо LLVM, либо LLVM в роли ObjC => C транслятора, затем другим транслятором
3. Оставались только заголовочные файлы, которые, наверное, надо брать из XCode, вот только какой версии, не очень было понятно. Учитывая, как реализована совместимость на уровне машинных кодов в Objective-C, в принципе, можно брать самую новую и просто не использовать слишком новые методы.
Нашёл время провести более детальный анализ того, что же именно содержит Apple Application Support. Во–первых, собственно Objective-C портированных библиотеки там 2: Foundation.dll и CoreFoundation.dll. В закрытых версиях Apple есть несколько типов CoreFoundation, которые без конвертации можно привести к указателю на Objective-C (toll-free bridging). Похоже, что это оно. Если поставить iCloud, там ещё можно отрыть AOSKit.dll, экспортирующий какие–то Objective-C классы. Никаких AppKit нет.
Что касается версии, я немного позанимался дихотомией и пришёл к выводу, что Apple Application Support из iTunes примерно соответствует версиям Lion/Mountain Leopard. Если скачать с сайта ADC xcode462_cltools_10_76938260a.dmg, он же Command Line Tools (OS X Lion) for Xcode — April 2013.dmg, достать оттуда 7-zip'ом Foundation.h и взять этот же файл из command_line_tools_for_osx_mountain_lion_april_2014.dmg, то видно, что, например, добавился #import <Foundation/NSHashTable.h>, и я вижу OBJC_CLASS_$_NSHashTable в Foundation.dll, и для некоторых других новых классов тоже, но не всех. А из Maverick (commandlinetoolsosx10.9forxcode6.2.dmg) я ничего добавленного уже не вижу.
Все остальные библиотеки реализованы более менее без Objective-C. Несколько библиотек, вижу, импортируют несколько вызовов objc.dll, но, похоже, только лишь для того, чтобы поработать с blocks и libdispatch.dll.
Таким образом, реально из iTunes можно взять:
1. Коллекции и связанные с ними Property List сериализаторы
2. Quartz (CoreGraphics), которым, в частности, можно рисовать текст нормально, как на Mac OS X, без радужного замыливания
3. «Официальный» порт libdispatch
Может, ещё какие не–Objective-C библиотеки, коих там куча.
AppKit, видимо, только через GNUStep, Cocotron или YellowBox. Свои интерфейсы Safari и iTunes, видимо, как–то через C'шные библиотеки отрисовывают поверх C'шного Quartz.

В отсутствие AppKit самое интересное (для меня) остаётся в libdispatch. И libdispatch, и libuv решают похожие задачи, но кто из них лучше? У libdispatch на Windows, кроме «официального» порта есть два неофициальных, и неплохо бы было, чтобы кто–нибудь посравнивал их между собой на предмет проблемы C10k.

Apple Mac Обзор OS X
Джон Сиракуза:

Около 15 лет назад я написал первый обзор для сайта «энтузиастов PC» Ars Technica. Около 15 лет спустя я написал последний. При том, что Apple несомненно выпустит очередную версию OS X на WWDC в этом июне, я не собираюсь делать обзор ни для Ars Technica, ни для любого другого журнала, включая вебсайт, который вы сейчас читаете.

Том Хольверда:

Лучший обозреватель в своём деле уходит.

Apple iTunes DAAP Современный iTunes 12 уже чёт не хочет так просто коннектиться по DAAP к домашнему серваку. Просто не показывает домашнюю библиотеку и всё. А ещё совсем недавно работало, и это самая крутая фишка iTunes, как мне кажется.

Очень давно в iTunes появилось ограничение на коннект только по локалке, но реализовано это было только на сервере. То есть, если запускаю rinetd и пробрасываю порт именно к rinetd, то iTunes у меня дома думает, что соединение пришло из локалки, а iTunes–клиент видит Bonjour запись с IP из левой сети, но, пофиг на всё, он к этому IP коннектится. Всё это я описал на daap.toom.su Судя по тому, что даже, если IP локальный анонсить просто для эксперимента, и он не появляется, дело не в этом, а там теперь анонсить надо как–то хитро, с определённой TXT–записью правильно заполненной. Не исключаю проблем с сетевым стеком. Может быть, что–то где–то блокируется. Желающие могут попробовать подключиться к 193.34.160.200:7089. Там iTunes 7, так что не–iTunes клиенты, насколько мне известно, не смогут подключиться.

Пока что складывается впечатление, что Apple сделала чудесный FireWire, но потом сами же и закопали, и теперь всего–лишь USB, ну ещё, правда Power-over-Ethernet есть, но как–то я его не наблюдаю вместо USB портов, а вот FireWire был. Помню, маялся с Philips Xenium 4@4u, и из–за того, что там USB, через который каждый работает как ему вздумается, ни в Интернет не смог выйти с Mac OS X, ни с внутреннего диска поскачивать–позагружать. А вот если бы у Philips Xenium 4@4u был FireWire, я бы подключил его в соответствующий порт, и сеть бы на нём работала как через NAT, и файловое хранилище по самбе я бы смог из Mac OS X подключить. FireWire, Ethernet WiFi работают более–менее стандартизованно, а USB и BlueTooth каждый реализует как вздумается. Покупаешь как кота в мешке, то ли заработает, то ли не заработает.

Теперь, похоже, Apple хочет закопать DAAP. Наверное, считает хорошей идеей, чтобы его заменил какой–то там DLNA. Или не считает? Там уже собственно яблочники начинают замечать нелады.

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

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

Apple IBM Microsoft borland Delphi Типичный Borland. Пока не пнёшь, не полетит. Вот Microsoft выписал живительный пинок, ограничив COM строки юникодом, только так и появились WideString. Что бы Borland делал без такого пинка?

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

docwiki.embarcadero.com

You might consider using the {$IFDEF AUTOREFCOUNT} directive in order to have the best code for both scenarios: ARC and traditional. AUTOREFCOUNT defines code that uses automatic reference counting, such as code for the Delphi mobile compilers. This is an important directive, different from {$IFDEF NEXTGEN} (the directive that defines the new language features of the mobile compilers). AUTOREFCOUNT might be useful in the future, in case ARC is implemented on top of the Delphi desktop compilers as well.

Как тут не вспомнить пропагандистский миф

Земля наша велика и обильна, а порядка в ней нет: придите княжить и володеть нами.

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

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