Apple's Switch to Intel 'Not Easy' for Developers, Adobe Exec Says
by , 8:00 AM EDT, September 1st, 2005
Apple's announced switch to Intel processors is a major challenge for developers and isn't as easy as Apple CEO Steve Jobs has made it out to be, according to Adobe CEO Bruce Chizen.
The Adobe chief told Cnet News.com that "moving the applications over is not that easy.
"Steve (Jobs) likes to trivialize the process and make it seem easy," he said. "Getting over to MacTel is work...You just can't turn a switch and get a MacTel product--and Steve knows that."
Mr. Chizen said the first MacTel-optimized versions of Adobe's creative products won't be available until the calendar fourth quarter of 2006 at the earliest. If that prediction holds true, it would mean some major software applications won't be available in time for the first Intel-based Macs that are expected to be released in the calendar third quarter of next year.
But Mr. Chizen prefaced his comments by saying he thinks the hard work will be a great benefit.
"I think in the long run it's going to be great because what the users will get is better performance...and greater value," he said. "At Adobe, we tend to optimize for Intel today on the Windows side. The fact that we'll be able to optimize for Intel cross-platform will make it even better for us."
It's not easy for Adobe. That doesn't mean it's not easy for anyone else.I don't know why people keep mentioning this like it's the only situation developers will be facing. That's already been shown to be not the case (thanks Wolfram Research).
Adobe's AltiVec code will have to be seriously rewritten to take maximum advantage of Intel, but haven't they already done that with their Windows versions, like they said? In any case, I would expect that most developers will not have to do much more than a simple recompile. If the OS and its calls already work on Intel, how much could really need to be redone? The typical developer codes in C and never deals with chip specifics.
If they were programing in Xcode like Apple has been telling everyone to do for the last couple of years, or if they just ported via Carbon. I seem to recall that Carbon apps, particularly ones that incorporated a lot of Altivec are going to need more work. But hey, Adobe's got lots of money right now, and they expect to make lots more in the future, right?
At first glance, it's easy to shrug off Chizen's comments; he's not an engineer (as far as I can tell), and he's not nearly specific enough. It may be the case that Mactel will be a difficult port for Adobe, but Wolfram Research and Bare Bones Software, et. al., have already given lie to his sweeping generalization.
That being the case, why did he say what he did? My concern is that he is setting expectations low, because Adobe may decide that they won't do the port right away. I can certainly live without Adobe products, but a high-profile holdout from Mactel will generate a bit of FUD.
CloseViewName:WebsnapPosts: 72Joined: 17 Jun 2005 Thu Sep 01, 2005 9:06 amSubject: They had time
Adobe had lots of time to change the suite to Cocoa from Carbon for it to run more efficiently on os x. The altivec I can understand, but the rest should not have still been carbon. One thing's for sure, when this is all done. All native run apps on Mactel will just scream because their code have had some thorough scrubbing.
It sounds like Adobe will ships its Creative Suite for Mactel well before the Professional x86 Macs are released. So I don't think there will be much of a problem there.
My rule: The longer a piece of software takes to load, the crappier it is. Adobe wins that one.
Plus, they've hated Apple for a long time, first as a waste of their valuable development time because the PC market is so much bigger, and later because they see Apple becoming a competitor.
Adobe's products are probably the worst case scenario: Carbon rather than Cocoa & extensive use of AltiVec optimization. If they're using CodeWarrior rather than XCode, the major headache is porting to XCode.
why should adobe have ported to cocoa? carbon is an official API to Mac OSX. cocoa is Obj-C which means that their Mac and Windows codebases would have to be different.
But the real cost of the switch is not in recompiling the applications, which ought to be reasonably simple, but in exhaustive testing: every possible combination of plugins and operating system versions and hardware setups and system utilities.
It's unlikely that a long time developer, particularly one that has code that pre-dates OSX *and* runs on Windows is using Cocoa and Apple's development tools. Adobe has made a huge investment in developing cross platform libraries that support their UI and graphics models. The code is written in C++ and compiled by CodeWarrior on the Mac and VisualStudio on Windows. Switching to Objective C and Cocoa would make it even more difficult for companies like Adobe to build cross-platform applications. I doubt that few (or any) legacy cross-platform applications are built using Apple's XCode. Mathematica, of course, with it's NeXT roots, has been a Platform Builder app since day one.
Calm down. There needs to be some way of differentiating between Intel-based Macs and PowerPC-based Macs, right? The reason why today's Macs aren't called MacBM or whatever is that no one is using non-PowerPC Macs, os there's no need to differentiate.
As this transition happens, there will be a need to differentiate between the two, so some kind of shorthand will develop. In a few years, we'll be back to talking about nothing but plain ol' Macs again.
Guest wrote: why should adobe have ported to cocoa? carbon is an official API to Mac OSX. cocoa is Obj-C which means that their Mac and Windows codebases would have to be different.
There is a large miss understanding among mac fans of what Carbon is. It is the right decision for Adobe to be using Carbon for their application, as all of the Adobe products are cross platform. Carbon was added in to OS X's API's for exactly this purpose.
Also there is nothing inherent about Carbon that makes it preform worse then Cocoa applications. Many of Apple's own applications are Carbon applications (e.g. Finder, iTunes, QuickTime). In fact there is additional overhead and a perfromance hit in Cocoa becuase of Objective-C's dynamic linker, every time a class member function (message in Obj-C) is called it is 50-60 extra instructions in Cocoa then it would normally be in Carbon. This is a hit well worth the flexibility that Dynamic loading gives you. Interface Builder would not have the functionality that it does now of making connections without this feature!
XCode compiles Carbon code written in C or C++ just fine. So the first step is just to move from CodeWarrior to XCode.
The second step is adapting to endianness. If your app runs on Windows (x86), most of that is already done. You just have to be careful: Many people have written code like "if (windows) { x86_byte_order; } else { MacOS X, ppc_byte_order; }. That test needs changing: "if (x86) { x86_byte_order; } else { ppc_byte_order; }".
Photoshop could be expected to have lots of code that is processor dependent, but not OS dependent: They might have a filter optimised for x86 (planned to be used on Windows) and optimised for Altivec (planned to be used on MaxOS X); now the x86 code needs to be used for all x86 systems including Macs, and Altivec needs to be used for all PowerPC systems, that is PPC Mac.
Adobe's cross platform applications are not written using clean, high level APIs like Cocoa. Instead they wrote a cross platform Mac/Windows environment and then have been moving that forward since the early 90s. Making a change like changing to a new processor is probably a major headache for Adobe. Their apps are huge! They probably have certain pieces hand optimized in assembly.
Microsoft is in a similar boat with office. They are using a custom windows emulation layer and then programming their Mac apps on top of that. It is much harder for them than, for example, my company.
Guest wrote: Please please stop calling it MacTel!!!
It's not MacBM or Macarola now is it? NO!
Of course there is no term "Macarola". Why would anyone have said that?!? Try and follow me here... we now have 2 very distinct hardware architectures that will be present in Apple Computers. I haven't lost you yet, have I? Perhaps maybe once in a while people will be attempting to communicate with each other and at some point one may wish to differentiate one of these architectures from the other while at the same time also indicating that they are referring to a Mac and not a Wintel machine. And I suppose the person might say MacTel as a shorthand way of doing this. But apparently this bothers you... to the point where you actually had to post and complain about it. I must assume this is due to the fact that you really wanted to post but could not think of anything intelligent to say related to the topic. But we're all really nice, so from now on we will all say "Apple Macintosh Personal Computers which contain an Intel manufactured central processing unit". Is that acceptable? My only goal here is to make you happy.
So much that you hear about this issue is either fanboy hyper-happiness or FUD-filled axe-grinding. This story, and the replies here, are fine examples.
"We [Adobe] will have trouble. Therefore the switch is terribly hard!"
or
"Wolfram and Bare Bones did it easily. Therefore the switch is trivial!"
The truth is, it's nowhere near as simple as the rosy just-a-recompile Steve Jobs and the Apple fanboys would like everyone to think. BUT it's also not going to be nearly as hard for most people as it will be for Adobe.
I speak as someone who codes exclusively in REALbasic and Objective-C/Cocoa (with Xcode, of course). In theory, it should be easier for me than just about anyone. But it's going to take more than just a recompile. I'm already getting headaches from the switch.
That said, I'll deal. Once I get in the groove and start writing my programs with cross-chip implementation in mind, I don't think I'll have much trouble. I mean, I already make some of my RB apps for Windows; it's an incredible pain in the rear to port most of my projects to Windows, but when I start one with that in mind, it's not really that hard, and implementing for Intel OS X will obviously be easier. So I think the problem will be a mostly one-time shock. That doesn't mean it's not going to be a big pain, though.
In fairness to Job's role-out, he never said the migration would be like "flipping a switch." What Jobs said was appropriate for the setting and what it meant for the developers reading between the lines. Chizen's misattribution speaks louder about Chizen then jobs.
The deeper issue for me is this nonsense whining from Adobe. More than a few posts here back up my experience regarding their products. Adobe's Mac products are rapidly devolving, particularly as their version numbers rise (more or less) Check MacFixIt out -- right now, CS2 is under heavy criticism for its slow performance. If poor performance is any bellwether about the quality of the underlining code, then, Chizen is at least qualified to understand problematic software development environments. (That comment is a cheap shot but I'm letting it stand)
The best option, one I eagerly await, is the maturation of software products out side of the Adobe/Macromedia stable, from committed Mac developers. For example, I use OmniGraffle whenever possible. It's not as mature as Illustrator or Freehand, but it's an excellent program with top-notch software support.
(Sorry for reposting but I thought I was logged in...)
In fairness to Job's role-out, he never said the migration would be like "flipping a switch." What Jobs said was appropriate for the setting and what it meant for the developers reading between the lines. Chizen's misattribution speaks louder about Chizen then jobs.
The deeper issue for me is this nonsense whining from Adobe. More than a few posts here back up my experience regarding their products. Adobe's Mac products are rapidly devolving, particularly as their version numbers rise (more or less) Check MacFixIt out -- right now, CS2 is under heavy criticism for its slow performance. If poor performance is any bellwether about the quality of the underlining code, then, Chizen is at least qualified to understand problematic software development environments. (That comment is a cheap shot but I'm letting it stand)
The best option, one I eagerly await, is the maturation of software products out side of the Adobe/Macromedia stable, from committed Mac developers. For example, I use OmniGraffle whenever possible. It's not as mature as Illustrator or Freehand, but it's an excellent program with top-notch software support.
What is the story here exactly? MacObserver is reporting something that isn't really news. Do the math. CS2 was released about 4 months ago. There is usually a year and a half or so between releases (absent anything to do with MacIntel). 18 months from April 2005 is the last quarter of 2006.
This is a non-event. Chizen is just flapping his gums because he can.
>> there is nothing inherent about Carbon that makes it preform worse then Cocoa applications <<
True. But because Carbon apps don't get a lot of the free functionality that Cocoa apps get, developers usually settle for partial compliance. This is why Carbon apps often feel half-a**ed and incomplete. Look at AppleWorks. Making a Carbon app behave like a Cocoa app takes about 5x the work.
Hmm - did Adobe phone anyone up to specifically bitch about the Mac move, or is this an excerpt from an interview where the move to Intel was discussed and someone gave their legitimate view? Ah, I forget, to criticism allowed.
OWC: Juice up your iPod w/NewerTech High Capacity Battery from $19.99 Free Installation Videos for most models. Pro Installation Service w/FedEx Shipping From $57.95 (Battery Included). - www.MacSales.com