| french | english |
 |
|
| Sign in | |
| 03-04-08 / 23:30 : Adobe, 64 bits and CS4 : rewrite in Cocoa (cjed) |
| 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) |
| Comments |
| Write a comment |