Mac OS X

Из говна и палок

На поведение Windows при вставлении-вынимании флешки я уже жаловался: событие не прилетает, нужно поллить. Потом жаловался и на OS X - событие прилетает, но до того, как устройство появляется в списке томов. Тоже поллинг.

Но действительность на OS X превосходит ожидания.

Если мы размонтируем устройство сами, через FSUnmountVolumeSync(), то поллинг работает нормально: прилетает callback, дальше по таймеру несколько раз читаем список томов, из списка размонтированный том пропадает, все отлично.

А вот если размонтировать через Finder, то жизнь ГОРАЗДО...

WM_DEVICECHANGE на OS X

Продолжение к WM_DEVICECHANGE и все все все (потому и заголовок такой), только на маке.

На OS X, казалось бы, все хорошо, там есть такое:

DARegisterDiskAppearedCallback(m_session, kDADiskDescriptionMatchVolumeMountable, mountCallback2, this);

Ну и дальше в том же духе. И на всовывание USB-карточки прилетает callback.

Дальше мы хотим узнать, что же нам всунули, идем получать список маунтов:

CFURLEnumeratorRef enumerator = CFURLEnumeratorCreateForMountedVolumes(NULL, kCFURLEnumeratorSkipInvisibles, NULL);

Фигак, а нашего тома в этом списке еще нет.

Причем,...

Загадка DPI

Вот значит вроде порешал проблему:
  • Все шрифты теперь в pt, а не в px
  • Практически все иконки - в SVG (осталась, буквально, одна, но отчего-то в Qt stylesheets не работает svg, хотя по доке - должна, ну соберусь с силами и буду генерировать ее на скаку)
  • Размеры окон, там где надо (автомат работает так, что мне не нравится) - в em
  • чего-то еще вылезло, но вот не могу уже вспомнить
И все на винде заработало прилично. Несу на мак. Собираю. Ой.

И вот гложет меня теперь вопрос:

Отчего на одинаковом мониторе (виртуальном, 1920x1200, никакого HiDPI, никаких специальных настроек, операционки поставлены по дефолту) 9pt шрифт на винде (приблизительно) соответствует по размеру 14pt на маке?. Один и тот же шрифт. Тахома.

Я прийшов, тебе нема

Вот есть такой вызов, strnlen:

     size_t
     strnlen(const char *s, size_t maxlen);

DESCRIPTION
     The strnlen() function attempts to compute the length of s, but never scans beyond the
     first maxlen bytes of s.
И он есть, например, в Mac OS X 10.7 и новее.

Берем код с этим вызовом, собираем с -mmacosx-version-min=10.5 (должен получиться совместимый c 10.5 код, да?) на 10.8, несем на 10.6, запускаем.

Все падает.

И ладно бы падало с внятным сообщением, вот не могу залинковать такое. Нет, SIGSEGV, нулевой указатель (на функцию?).

После этого начинаешь любить Win32 особенно остро.

Про Mac OS X и совместимость (и ленивый линкер)

По случаю выхода XCode5 взялся я проверять, а что у этой штуки с backward compatibility, не сломалось ли чего, будет ли работать на Mac OS 10.5, к примеру...

И, надо сказать, результаты меня расстроили (помимо необъяснимой проблемы с VMWare

Для начала я наткнулся на широко известную проблему с ___bzero, на которую все кто мог уже наступили:

dyld: lazy symbol binding failed: Symbol not found: ___bzero
  Referenced from: ....
  Expected in: /usr/lib/libSystem.B.dylib

Лечение нашлось быстро: -mmacosx-version-min=10.5 эту проблему лечит.

Дальше стало хуже:

posix_memalign(), если попросить у нее мегабайтиков 100 (меньше не пробовал), на 10.5 не справляется. Причем, сайт developer.apple.com полагает, что эта функция появилась только в 10.6. Удивительное рядом - она вызывается, правда результат ее вызова неудовлетворительный (в коде поведение одинаковое что при ейной ошибке, что при исполнении без ошибок но и отсутствии аллокации, в детали не вдавался).

Сделал K (меньше N) экспериментов, убедился что на 10.5 malloc (у меня!) возвращает всегда 16-byte aligned, временно сделал затычку (ну и написал в TODO, что надо бы анонимный mmap() в это место).

Варез начал запускаться и местами работать. А местами - падать (не при запуске, в процессе). Потому что нашлось сразу две новые фишки:

  • __ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l (или, если человеческим языком, то std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)). Каковой __ostream_insert на самом деле используется в std::string, а std::string - в std::runtime_error.
  • У этой самой макоси - ленивая линковка, поэтому падает оно не при запуске, со словами "символ не нашелся", а на рантайме (weak linking).

Конкретную проблему я порешал, запретив использование RawSpeed на 10.5 (и posix_memalign() и __ostream::insert - обе проблемы были в RawSpeed), но осадок остался.

Дивлюсь я на небо, та думку гадаю:

  1. (деструктивная часть): "Программа запускается и как-то работает" в этой вашей Макоси не означает ничего. Мы просто могли не дойти до места, где потребуется (и не найдется) нужный символ. Тестирование обычным способом становится веселым.
  2. (конструктивная): а как бы проверить, что все символы, которые у моей софтины (и всех используемых библиотек вообще-то) в действительности присутствуют? Погуглил все известные слова, не нашел.

Q: mDNSResponder/Bonjour через роутер

Было у меня все тихо-мирно: в одной локальной сети жили несколько Ma/Hackintosh-ей, был в сети AppleTalk-сервер на FreeBSD, сервисы на котором анонсировались через mDNSResponder.

И все работало. В частности, и Time Machine и Макосовский инсталлятор видели тома на сервере (бонжуром) и все было прекрасно.

Но. Настал день, когда топологию сети пришлось поменять. Сейчас некоторых Ma/Hackинтоши живут в другом сабнете, роутятся через роутер (через который раньше ходили в интернет, а теперь ходят в мой LAN, я его развернул внутрь).

Естественно, на роутере все NAT-ы и файрволлы теперь повыключены, он прозрачен.

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

Вопрос: а как добиться счастья? Может Port Forwarding какой нужен? Или конкретные какие-то мультикасты фигачить в другой сабнет (правда, этот Netgear, кажется, мультикасты не умеет форвардить). Что ему надо то?

Пока бэкаплюсь на конкретный том, бэкапы работают, а вот при необходимости с бэкапа подняться - будет неудобно, инсталлятор, насколько я помню, возможности скормить свой afp://-том не дает.

Q: mmap() ?

А я вот извиняюсь, а Windows умеет mmap()-ать файлы с сетевого диска?

А макос?

Ну то есть у меня какое-то ощущение из прошлого, что нет, нельзя, но в доках такого ограничения не нашел.

Про Mac и 32 бита

Ваяю потихоньку новый варез для фотографов (пока не скажу какой). Делаю его на Qt5, вот так вот решил.

В связи с этим встает вот такой вот вопрос:

  • Qt5 не билдится как Universal Binary, обещают починить, но там есть препятствие в лице v8 (насколько понял из чтения мейлинг-листов).
  • Qt5 поддерживает Mac OS X начиная с 10.6. Эта самая 10.6 вроде бы требует 64-bit capable CPU (это по комментариям в Qt-шном багтрекере, где обсуждают отсутствие UB). Хотя в Википедии пишут, что 64-bit only - только с 10.7
  • Посмотрел в статистике RawDigger: 32-битных Маков 1%. Не от числа вообще компьютеров а от числа маков. У меня, понятно, статистика смещенная и кривая, но какая уж есть.
Собственно, вопрос: а что будет, если я в мак-версии дропну 32-битность? Целевая аудитория вареза - фотографы, как обычно. Теоретически, это заденет модели 2006-го года и некоторые макмини 2007, но их же должен быть вот тот самый 1%?

По-моему, этот вопрос мы уже обсуждали в этом бложике "вообще", но может у кого есть объемная статистика?

Q: OS X 10.7.5 + Time Machine?

Граждане маководы!

А кто-нибудь из вас уже столкнулся с Time Machine is broken after 10.7.5 update и подобным?

В том смысле, что вот тайм-машина перестала нормально работать, а затем выключение Spotlight помогло?

Я пока в первой фазе: TimeMachine не работает, а выключение Spotlight - не помогло. Ну вот буквально, за последние минут 10 сбэкапило аж 434 килобайта из тех 4.5Gb, кои собирается бэкапить.

И это я делаю чистый эксперимент: поставил 10.7.4 (на отдельный раздел на хакинтошной машине), успешно ее побэкапил за какое-то человеческое время (не замерял, но это были не часы, а может минут 10 на полный бэкап), накатил 10.7.5 Combo и сижу, наслаждаюсь этими 434кб за 10 минут.

Бэкаплюсь на AFP, подключен по гигабиту, мегабайт 50 в секунду файлового IO там есть.

Кто виноват, что делать и где водка?

Про Look and Feel

Пользователи мак-версии RawDigger вероятно заметили уже, что окошко гистограмм очень широкое.

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

А вот как это отрисовывает Qt под разными ОС (окно завернуто в минимальную ширину):

По клику откроется полный размер.

Сверху вниз:
  • Mac Native (и такой spacing так и задуман) - ширина окна 1088 пикселов и меньше не делается.
  • Результат применения setStyle(QStyleFactory::create("windows")); - 908 пикселов, на 20% меньше.
  • Win7 Native (без каких-то настроек spacing) - 821 пиксел, еще на 10% меньше.
Эксперимент не полностью чистый: маковский десктоп 1920x1200 и никаких настроек шрифтов не делалось, на винде шрифты увеличены (115%), а разрешение монитора 2560x1600. В полностью одинаковых условиях винды, скорее всего, будут еще компактнее (пробовать страшно, потрогав размер шрифта у винды есть риск обратно не вернуться).

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

Update: Добрые люди подсказали про Qt::WA_MacMiniSize. Результат - 859 пикселов ширины. Чуть хуже винды, но непринципиально. Хотя, конечно, спинбоксы по мне выглядят чуть мелковато.

RawDigger 0.9.10 - версия для Mac

Продублирую анонс на radigger.ru тут, с небольшими комментариями.

Обещал Mac-версию в течение марта? получите.

Это альфа-версия, потому что ей от роду - неделя (даже меньше). Ее, конечно, тестировали, под оный мак немножко правили, но бетой ей раньше чем через месяц-два не быть, просто не по понятиям. Кроме того, маковская специфика (хоткеи, например) в документации не отражена, просто не успели.

Отличия от Windows-версии:

  • Функциональность соответствует версии 0.9.10 для Windows за исключением Drag-n-Drop на иконку приложения (Drag-n-drop в открытое окно программы - работает).
  • Все функциональные Ctrl-кнопка стали Command-кнопка, за исключением Ctrl-H (показ окна гистограммы всего изображения), которая стала Option-H. Патамучта Command-H уже занято.
  • Порядок следования кнопок в Preferences немножко отличается от Windows-версии (но все элементы находятся на своих табах). Это нормально, этот новый порядок будет и в очередной Windows-версии.
  • Текущая версия - только 64-bit. Universal-binary варианты (Intel 32/64, а может быть и PPC 32/64) будут позже. Все понятно что делать, но Qt пересобрать придется, а это серьезное такое (по времени) развлечение.
  • Тестировалось на Mac OS X 10.6 и 10.7. Работает.  На 10.5 протестировать не удалось т.к. она оказалась на 32-битном процессоре (точнее, та виртуальная машина, которую я готовую скачал - 32-битная по мнению Mac OS).
  • Английская версия будет через несколько дней. Анонсировать русскую версию в англоязычных форумах не надо. А то обидимся совсем. Тот шабаш, что был с анонсами русской 0.9.6 - не понравился вовсе.

Про разработку под Макос имею сказать отдельно:

Картинка дня

Кто не понял про что это - смотрите теги :)

Qt - рулит. Ну то есть я не разобрался (пока?) с динамическими библиотеками, Frameworks и прочими страшными словами, поэтому с LibRaw слинковался статикой.

Ну, естественно, повылезало всякого, но умеренно:

Qt+Xcode = ?

Делаем так:

qmake -spec macx-xcode somefile.pro
Дальше напускаем туда (на получившийся pbproj) Xcode 4.2, Xcode с грохотом падает. Ну то есть известная проблема, как выясняется, но ведь ей минимум полгода?

Качаю Xcode 3.2 (4гига однако, еще где-то час).

Чтобы два раза не вставать. Я правильно понимаю, что если я соберу некий варез как 64-битный, то он не будет работать на Intel Macs с Core Solo (т.е. на очень старых Mac Mini) ну и естественно на PPC. А на всех остальных - будет, независимо от битности ОС, верно?

Q: переносимые имена файлов в локальных кодировках (C++)

А вот, извиняюсь, вопрос.

Вот есть имя файла в национальной кодировке и я его хочу fopen(). На Винде и на Маке одним куском кода (хе-хе).

Насколько я сумел это изучить, ситуация такая:

  • Win32: или я отдаю в fopen() 8-битную кодировку (1251), или в _wfopen() в wchar_t (UCS-16?)
  • Mac: отдаем в fopen() UTF-8 и нам щастье
  • Linux: не знаю, пока руки не дошли.
Но это все с русским, который представим в виде 8-бит. А с китайским? Сдается мне, что в винде это только через _wfopen() получится.

Вопрос: есть какой-то совместимый способ, одинаковый на всех помянутых системах, или так и придется #ifdef WIN32...?

О Хакинтошах: Оглавление

Читаю логи сайта, вижу как мечутся по моему уютному бложику пришедшие с поисковиков по "хакинтошным" запросам. Кажется полезной идеей сделать оглавление и поместить ссылку на него в основные посты раздела. То же самое будет со временем сделано и для других больших тематик, собственно я сам постепенно начинаю путаться (но поиск спасает).

Предуведомление: если у вас процессор не Intel Core, а более старый Intel, Intel Atom или AMD, то вы попали не по адресу, скорее всего вам тут не помогут.

Установка в виртуальной машине

Установка на физическом железе

Time Machine, мелкие заметки о поддержании в работоспособном состоянии

Разное

Hackintosh 10.7: восстановление с Time Machine

[Оглавление раздела Hackinthosh]

С восстановлением OS X целиком с Time Machine backup на родных Маках никаких проблем нет: Time Machine должна быть видна через mDNS (Bonjour), грузимся с инсталляционного диска/флэшки (можно даже с того, с которого на данном маке поставиться нельзя) и все восстанавливаем.

С Хакинтошами все выглядит сложнее:

  • Загружаемый на PC инсталляционный диск с OS X Lion - на сегодня не существует.
  • Кроме восстановления системы, нужно еще восстанавливать загрузчик.
В результате экспериментов, родился и проверен следующий метод:

Time Machine server на FreeBSD: backup, restore, полный restore...

[Оглавление раздела Hackinthosh]

Как многие знают, Time Machine на Mac OS X 10.7 не поддерживает SMB

Пришлось осилить AFP и к нему mDNSResponder. И если с AFP все тривиально, то с mDNSResponder пришлось помудохавозиться, ибо документации к нему в сети сыскать не удалось, исключительно методом тыка разбирался.

Идеальное решение должно уметь:

  • Бэкап TimeMachine на FreeBSD-сервер.
  • Пофайловое восстановление с TimeMachine за нужную дату.
  • Накатка целого бэкапа из инсталлятора Lion/Snow Leopard

Нижеприведенный текст - для FreeBSD, для Linux/Solaris будет отличаться процедура установки пакетов, а настройка должна быть примерно такая же.

Mac OS X 10.7 Lion: Hackintosh

[Оглавление раздела Hackinthosh]

Поапгрейдить штатными средствами Хакинтош на OS X 10.7 нельзя, сделать инсталляционный диск/флэшку для 10.7 и обычного PC вроде бы тоже пока нельзя (? я не нашел).

Чтение форумов дает кучу весьма противоречивой информации, из которой скомпилировалось следущее (за основу взято вот это: xMove + MultiBeast: Install OS X 10.7 Lion on any Supported Intel Core 2 or Core i based PC).

У меня (но на вполне mainstream-железе) оно сработало.

Магия: VMWare + Hackintosh + Sandy Bridge

[Оглавление раздела Hackinthosh]

Чтобы Mac OS X работал под VMWare под новыми интеловскими горшками, надо в .VMX-файл добавить строчку:

cpuid.1.eax = "0000:0000:0000:0001:0000:0110:1010:0101"

Установка Snow Leopard на PC с помощью USB-флэшки

[Оглавление раздела Hackinthosh]

hackintosh1.jpg На неделю позже, чем обещал, но я добил этот текст!

После успешной установки Snow Leopard на PC я оказался завален почтой, общая суть которой сводилась к тому, что Prasys пишет не очень понятно, да и английского не розумию, напиши пожалуйста на русском (если честно, то после чтения Хакинтошных форумов у меня тоже временами складывается впечатление, что я тоже не понимаю английского).

Рекламируемый мной Empire EFI необычайно удобен, если все работает. Впрочем, судя по чехарде версий на сайте автора (за 2 недели с 1.00 до 1.07R2), да и по моему опыту, оно работает далеко не всегда.

Одна из наиболее частых проблем связана, к несчастью, именно с DVD-приводами. Современные чипсеты Intel не содержат старого (параллельного) контроллера ATA (PATA), интерфейс к старым DVD, дискам и т.п. делается контроллерами третьих фирм (чаще всего JMicron). В этом месте начинается секс с драйверами (kext, kernel extension), таймаутами, настройками и т.п.

Описанный ниже способ установки с USB-флэшки не использует DVD. Помимо этого, метод обладает рядом других достоинств:

  • Ставится быстрее. Большинство современных флэшек гораздо быстрее оптических приводов, особенно по скорости позиционирования.
  • Модификация загрузочных блоков, расширений и т.п. не требует перезаписи CD/DVD, а значит экспериментировать можно быстро.

Правда для изготовления загрузочной USB-флэшки нам потребуется работающая Mac OS. При реальной установке я все манипуляции делал на настоящем Маке, но при подготовке данного текста повторил это упражнение в Snow Leopard, установленном в виртуальной машине.

Pages

Subscribe to Mac OS X