Adobe, 64 bits and CS4 : rewrite in Cocoa

Posted: September 3, 2008 in Apple, IT/Dev
Tags:

Adobe announced that the 64 bits version of CS4 for mac (being developed) will ship after the Windows version, due to Apple abandon of Carbon 64 bits support in XCode. Then the software will have to be rewritten fully, in Cocoa (only framework to support 64 bits now). Developers initially refused to do so when the Yellow Box of Rhapsody was presented in 1996 (NextStep APIs for MacOSX Server and Windows, renamed later as Cocoa and enhanced at the MacOSX 10.0 client release early 2001), what leads to MacOSX client and Carbon framework (corresponds to updated MacOS9 APIs – some ToolBox instructions deprecated, and others modified to be reentrant).

However Adobe had ten years to prepare its software base code for migration, and Apple clearly stated more than three years ago that Cocoa programming was the future for MacOSX applications. Moreover, Adobe Lightrooom (beta 2 actually) is written in Cocoa… and then still supports 64 bits (it is a new application however). There is also to consider that updating CS3 to support (deprecated) Carbon 64 bits would have still required a lot of rewritting.

Globally editors of multi-platform apps rarely embrace specific technology of target systems, and prefer to use abstraction layers that map to procedural APIs of each OS. This isn’t possible with a fully object oriented framework like Cocoa (uses a true object messaging system – ResponderChain). On another hand, frameworks like Windows MFC (lags way behind Cocoa/Next in terms of architecture and concepts (MFC is finally procedural APIs, far from really object oriented) slows the progress of modern mac applications (in fact at start – early 90s – Photoshop and Illustrator were mac only… at that time it was System 7 procedural APIs).

An alternate solution (except for user interface management, that has to be done through Cocoa Interface Builder and responder chain, that is the AppKit framework objects) would be to use Cocoa CoreFoundation APIs (procedural versions of instructions of Cocoa FoundationKit objects). That is probably what Adobe plans to do, as a full rewritting using all Cocoa object paradigms will require years (even considering Cocoa development is way faster than procedural development like Carbon). This has to be balanced with the fact that an image editing software like Photoshop uses – except for the UI – a lot of functions (filters, etc.) that are typically C code, and that won’t be ported (can be called from Objective-C objects, as well as C++ code). However if Adobe decides to replace these libraries with recent Cocoa frameworks APIs (ImageKit, etc.), the rewritting will be more important (but they probably won’t do that, because code base synchronisation with Windows version would then be even more painfull).

Some interesting links (some provided infos may not be valid as for now) :

Discussion about Apple’s Carbon White Paper (announced in 1998 orientations for Carbon/MacOSX : deprecated Toolbox instructions, etc.)

Cocoa or Carbon ? (may,2000, just before the MacOSX Public Beta)

Carbon vs Cocoa (AppleInsider forum, 2002)
it is possible for a Carbon app to be better threaded than a Cocoa app. Much of Cocoa’s AppKit is not reentrant (meaning that it’s not safe to make calls to the same method within multiple threads at once), and as a result there is an awkward arrangement built into the application frameworks where only one thread draws into the view (the window, essentially), and this thread also contains the main event loop. This is why Cocoa windows stop rendering when you hold the mouse down on the scrollbar thumb (but only that window stops updating, not the whole app or the whole system). It’s quite possible to make a Carbon app that doesn’t exhibit that behavior.)

Cocoa vs Carbon (2002)

Short Carbon history (from 2000).

Facts are not that simple : for the MacOSX release (and for some years later), as stated, Apple had to put its efforts on Carbon, and even some new MacOSX APIs were only accessible from Carbon applications (these APIs were later progressively wrapped by Cocoa objects – thanks to the ability of Objective-C to call C and C++ -, that is non-native Cocoa – ie not CoreFoundation procedural APIs). The MacOSX Finder was first developed using parts of System 8/9 Finder (when the APIs used were provided by Carbon), in fact the base code used intially the PowerPlant framework from Metrowerks, another set of APIs to consider (migrate and validate to Carbon).
Since some years the Finder is being rewritten progressively in Cocoa, notably in Leopard (new Finder). Newly introduced APIs are mainly Cocoa, and Carbon doesn’t evolve so much.

Finally Apple seems to have found a mean to promote Cocoa, as Safari and iTunes for Windows (and probably upcoming Apple applications) still use CoreFoundation procedural APIs, ported to Windows (come from the YellowBox).
And hopefully, thanks to Google (GWT), will we soon only see superb applications using a great object and reentrant language, javascript !!!! :):):) Although the programming is done using java in GWT, the javascript generation engine is proprietary (owned by Google and not open), the generated javascript is limited in functionnalities and will always be slower than native compiled language (as javascript has to be interpreted by the browser). The new disk access features (Gears) added to Google Docs also brings security concerns (see also this site about Google)

Advertisements
Comments
  1. badbase says:

    Hi,

    I am not sure that you ae correct when you write “This isn’t possible with a fully object oriented framework like Cocoa”. I can’t see what the restriction is. If you look at xplatform frameworks like wxWidgets and Qt – both are C++ frameworks and both have cocoa ports. If you look at projects like Adam and Eve (Adobe’s widget toolkit and layout toolkit they acknowlege that they could do a cocoa port) though one is not currently available.

    From what I know about Adobe they have their own application frameworks, and indeed their own UI paradigms – for them it probably makes the best sense just to port a framework to whatever underlying architecture exists on target platform.

    best regards

    badbase

  2. Hi badbase,

    In fact my point was it is harder to map a general purpose framework (has its own paradigms, but most of the time these frameworks don’t go farther than C++ concepts, so no true messaging) to a true object oriented runtime like the Objective-C runtime. Even mapping Java applications to Cocoa would be difficult, as Cocoa uses heavily the messaging delegation (that pattern is usable in all object oriented languages, but it isn’t present in the execution environment). Cocoa benefits from runtime resolution and delegation, not the same than compile time delegation. This leads to (for example) to dynamic bindings of UI objects, what can’t be managed by a compatibility framework.

    So Adobe or other multi-platform frameworks will never gain so much using Cocoa objects instead of CoreFoundation procedural APIs : as I explained, most of new Cocoa objects up to Leopard were only Carbon APIs wrapping objects, as Apple developped new OSX features in Carbon first (this is the opposite now). Leaving aside what makes Cocoa very powerful (the Objective-C runtime) greatly reduces the interest of these frameworks. Do you remember Metrowerks CodeWarrior PowerPlant framework that Adobe used for their mac ports, Photoshop, etc. until recently (they moved to Carbon but I heard that they simply modified the PowerPlant internal OSX mapped APIs to Carbon APIs for deprecated ones). If i’m right PowerPlant also allowed to produce Windows executables.

    I’m using audio applications developped with Qt (as for quick multi-platform development), and what can I say is that their performance (UI responsiveness, audio) is far behind a native Cocoa or Carbon designed application. The executables generated by Qt do use Carbon and/or Cocoa APIs behind the scene (in fact their assembly because we are then after compile time), but not at the full extent, beacuse the way they combine these APIs isn’t optimal (not the common workflow of a Cocoa application).

    I agree I undeline an extreme though, most of the time frameworks like Qt will do the job… but I prefer using the best technology on each platform. As we know QuickTime is bad on Windows, whereas Office and Flash are horrible (performance wise) on OSX.

    best to you,
    Jerome

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s