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).

...macnut. That's exactly what I was thinking.

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.

DarelRex@gmail.com

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.

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.

Please please stop calling it MacTel!!!

It's not MacBM or Macarola now is it? NO!

Quote

Guest wrote:
Macarola

I feel a song coming on...

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.

Quote

Guest wrote:
My rule: The longer a piece of software takes to load, the crappier it is.

That's why more and more people are moving towards the "calculator-only" method of computing.

Saves TONS of time.

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.

"Please please stop calling it MacTel!!!

It's not MacBM or Macarola now is it? NO!"

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.

It's Macintel

Quote

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.

LOL

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.

Quote

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.

My Mother used to make the best macorola.

"Getting over to MacTel is work...You just can't turn a switch and get a MacTel product--and Steve knows that.""

Ironically, Steve Jobs demonstrated Rosetta by running the PPC version of Photoshop on an x86 Intel.

So, he really DID just turn a switch and get a MacTel product. I thinks that's kinda funny.

Quote

Please please stop calling it MacTel!!!

It's not MacBM or Macarola now is it? NO!

You’re absolutely right. MacTel is a telephone. It’s Macintel! (With a little “i”.)

You'll see that the term Mactel is currently owned by Apple.

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.

How about intellimac....

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.