Comments on: О 64-битном Photoshop

By: MAXiK

MAXiK — Thu, 17 Apr 2008 04:21:17 +0000

А еще надо помнить о том, что МакОСь это юникс и с кэшированием у нее все куда лучше чем у винды.
Я когда купил 8 гигов, поставил ФШ и увидел что он только 4 видит.. в начале расстроился. А потом посмотрел как это все работает. Пока до реального скрэч диска дело дойдет…
У меня знакомый редактирует файлы для билбордов, они по 1.5-2 гига весят и он ни каких проблем с производительностью не испытывает. В то время как под виндой 200-300 мегов это уже тормаза страшные, даже если там памяти как грязи.

By: wasker

wasker — Wed, 16 Apr 2008 19:18:16 +0000

По поводу пункта 4 вы, мягко говоря, не правы. Все API появляются сначала в ОС, а потом уже во всех остальных местах. Никто никого не “кидает” — слишком дорого такие выкрутасы обойдутся. Вот, ознакомьтесь, новые API Vista: http://tinyurl.com/6pf684

Кроме того, скажем, для MFC (это который нативный Win32/64 C++) недавно вышел Feature Pack, который добавляет, например, фичи вроде ribbon в “обычные”, нативные приложения. В .NET 3.x “из коробки” такого нет.

By: alexuk2004

alexuk2004 — Tue, 15 Apr 2008 20:46:42 +0000

Мне кажется все это отмазки и нежелание адобе вкладывать ресурсы в мак. Бум надеятся кто нибудь их с этого рынка подвинет пока очухаются.
В сравнимом по сложности продукте – Mathematica, есть и универсальность и 64 битность.
А уж на чем математика писалась, это вообще история – Вольфрам хвастался что там еще есть код который он писал (наверно очень мало :) ).

By: Pavlo Boyko

Pavlo Boyko — Tue, 15 Apr 2008 20:44:43 +0000

1. Переход на Cocoa совсем не обязательно влечет за собой “переписывание с нуля”. Серьезных изменений требует только имплементация юзер интерфейса. При этом используются мощные RAD инструменты, количество кода уменьшается, он становится более гибким и оптимальным.

2. У Adobe уже есть Lightroom, написанный на Cocoa. Я уверен, что 70% его кода – самого ценного, того что отвечает за обработку изображения – взято из Photoshop-а AS IS. Ну не написали же они его заново на Cocoa.

3. То что Carbon лишь переходной фреймворк не имеющий будущего было известно 8 лет назад.

4. Microsoft поступает с разработчиками не лучше чем Apple: они объявили что только .NET является теперь “родным” для Windows и что новые возможности системы будут доступны только в нем. А .NET не имеет ничего общего с MFC, Win32 API и стандартным C++. И почему все пинают Apple? При том что Carbon никогда и не был “родным”.

5. В Adobe работают разные команды. Обратите внимание на разное качество продуктов, и даже на разные иконы фолдеров: http://www.onedigitallife.com/2008/03/27/adobe-drops-giant-turd-on-director-community/ Впрочем разное отношение к проектам наблюдается в любой большой компании.

6. Учитывая все выше сказанное я могу предположить что все публичные оправдания с наездами на Apple – лишь попытки прикрыть неумелое руководство, или полное отсутствие финансирования развития маковской версии.

7. В 64-битном коде действительно нет большой необходимости. Проблема “длинных” файлов была на маке решена еще во времена классики (QuickTime содержит набор “64-битных” функций где-то с 3й версии). Правда, справедливости ради, надо сказать, что обычный юзер легко может получить гигапиксельное изображение при попытке создать панораму состоящую из нескольких десятков кадров.

By: http://bukab.livejournal.com/

http://bukab.livejournal.com/ — Tue, 15 Apr 2008 11:02:28 +0000

Xcode – это не редактор кода, это целый набор утилит для сборки, и, скажем так, порядок и правила сборки задаются в файле проекта Xcode. А Adobe, как и многие разработчики, которые работают под маком еще с классики, использовали CodeWarrior (в то время не было достойных альтернатив) – там, кроме всего прочего, компилятор другой, не gcc. Самая трудоемкая часть в переводе проекта на UB – это как раз перевод на Xcode.

By: alexmak

alexmak — Tue, 15 Apr 2008 08:49:35 +0000

я не путаю, просто формулировка не совсем верная – да, действительно можно делать UB и без Xcode, но зато совершенно точно UB нельзя делать в CW, на котором до этого собирались продукты Adobe.
Ну и я знаю, что после объявления перехода на интел немало программистов Apple было откомандировано в офис Adobe для помощи перехода с CodeWarrior на Xcode. Да и я как-то себе с трудом представляю проекты объема CS, которые ведутся в текстовом редакторе vi. Может быть, Mozilla и использует какие-то другие средства, но у adobe огромную часть времени перехода на UB занял именно переход на Xcode. да и потом собрать фотошоп и иже с ним, в котором огромное количество legacy code, на UB тоже непросто – это не какавные проги, большинство которых простым recompile можно было собрать

By: http://klim.doslash.org/

http://klim.doslash.org/ — Tue, 15 Apr 2008 08:42:49 +0000

Wherever possible, it is recommended that you develop applications using the Cocoa environment.

Ага, был не прав. Действительно, родной язык Cocoa — ObjectiveC, а Carbon’а — с++. Так что действительно при наличии c++ кода проще писать используя carbon, нежели мучаться с c++ cocoa’шными binding’ами.

Что касается перехода на архитектуру. С переходом на Intel оказалось, что писать программы в Universal Binary можно только используя Xcode

Вы путаете понятия. XCode — это среда разработки, по сути редактор кода. Для сборки используется gcc. Никто не мешает писать код в любом другом редакторе (vi, eclipse cdt, что угодно) и собирать его тем же gcc, который отлично поддерживает сборку UB. Вот, например, Mozilla собирается в UB без всякого xcode.

Единственная проблема, которая тут может возникнуть, это отсутствие UI’шного дизайнера для Cocoa (в xcode он точно есть).

By: alexmak

alexmak — Tue, 15 Apr 2008 08:11:32 +0000

Про Карбон это не я так считаю – в одном из доков Apple на developer.apple.com под названием “Porting to Mac OS X from Windows Win32 API”, есть такая формулировка:

Wherever possible, it is recommended that you develop applications using the Cocoa environment. However, Carbon is a good choice when your application is already implemented in C or C++ code that has been written in a procedural (as opposed to object-oriented) style.

Что касается перехода на архитектуру. С переходом на Intel оказалось, что писать программы в Universal Binary можно только используя Xcode. Продукты Adobe до этого момента писались на CodeWarrior, и поэтому когда оказалось, что надо делать UB, то им пришлось переносить свои проекты сначала с CW на Xcode, а затем только начать портировать приложения.

By: http://klim.doslash.org/

http://klim.doslash.org/ — Tue, 15 Apr 2008 07:45:03 +0000

Для кросс-платформенных приложений, таких как Photoshop, Google Earth или Maya, Carbon вообще оставался практически единственной возможной альтернативой, при которой можно было продолжать разрабатывать приложения для нескольких платформ сразу

Что-то не совсем ясно. Вы считаете, что Carbon более удобен для разработки кросс-платформенных приложений, чем Cocoa?

. Затем Apple “обрадовала” всех разработчиков переходом на Intel-процессоры, при котором Adobe пришлось не только переделывать поддержку архитектуры, но и менять инструменты разработки на Xcode

Переход на новую архитектуру не стоит ничего почти. Только переписать ассемблерный код, которого в CS, уверен, почти что и нет.

Про XCode вообще непонятно. Все утилиты для сборки (gcc, linker, etc…) интерфейс не поменяли. Переход на xcode и архитектура почти вообще никак не связаны.