This is a great example of why a design firm like mine would skip a version of CS. And there's no way we'd switch to PCs to avoid waiting for a suite of 64 bit apps.
Certainly Adobe is out there to make money. And for the last several years they've probably been very distracted just trying to keep up with Apple's shifting direction. First the move to Intel meant that they had to switch compilers and IDEs for their entire Macintosh suite, then debug everything for two processors. Now with Apple doing an about-face on Carbon64 support, they have to do another fire drill. It's amazing they get stuff out for the Mac at all, let alone have time to do Mac-specific things with the way Apple treats its developers.
Well, ever since Rhapsody, the writing was on the wall. Apple never wanted to do Carbon, it was always YellowBox aka Cocoa that was going to inherit the throne.
Big developers like Adobe and Microsoft were going ape about having to port to an API that would give the Mac a major leverage in capability, but would undermine these big guys' cross-platform crap. It's much easier to wrap Carbon and Win APIs into wrappers of an internal cross-platform API than it's to do the same with Cocoa and Win APIs. (One reason being that both Win and Carbon APIs are ultimately derived and inspired by the original Mac API, while Cocoa is a fundamental redesign.
So since the big guys didn't go along willingly, Apple was forced into a ruse. They at a time of weakness were forced to give in and do Carbon, and ever since they have both provided push and pull incentives to go from Carbon to Cocoa. Any developer who like Adobe pretends they though they could have gotten away with sticking to Carbon forever was either blind or hoping that their size and importance would force Apple to do as they ask for.
Unfortunately for them, Apple is in a position of strength now, and so they use that to pull the plug on future versions of Carbon. It'll go the way of QuickDraw3D, QuickDraw, Classic, MacOS 9, etc.
Anyone who thinks or hopes differently has been kidding himself for the last decade.
It has been clear from the beginning that Carbon wouldn't be around for ever.
Further, the fact that images continue to grow and are expected to exceed 4GB, is unavoidable. Didn't Adobe see this problem coming?
They could have saved a lot of time because development under Cocoa is
much faster (because the system takes care of a lot of things behind the scenes that under Carbon need to be hard coded)
Name one 'thing' of this nature.
Carbon apps are often faster than Cocoa apps. In fact, this is usually the case.
I use both APIs, and while Cocoa is usually quicker to develop the claim that Cocoa apps are "much faster" is absurd. It's like expecting Gnome apps to run faster than GTK ones.
Quote:
much more robust
As already pointed out in previous posts, they would have gotten the transition from PPC to Intel almost without effort, had they switched to Cocoa
This is not an issue with programs which are already multiplatform, and isn't much of an issue with most other Carbon apps.
The sad fact is Apple yanked 64bit Carbon just before it hit beta for political reasons. It has nothing to do with feasibility or practicality and everything to do with what stick is up Lord Steve's ass at the moment.
Another sad fact is that Cocoa can't replace Carbon for all things, and for a variety of reasons:
? Cocoa is a higher level API than Carbon written in a different language. It would make as much sense to replace Carbon with Swing. This affects not only Photoshop, but all non-Cocoa APIs, which are many because Cocoa is not an all-encompassing framework. Carbon had deficits here, too, which is why Apple's 'Core' APIs were made and are being extended. Cocoa is better thought of as a good replacement for PowerPlant or MacApp. ObjC is better than C++, hallelujah, but why remove the C hooks altogether?
? Cocoa was written in the UNIX methodology which has human interface repercussions. There is no Cocoa FSRef equivalent, there is no Cocoa alias equivalent, and there is no Cocoa equivalent for a lot of low-level event handling. There are perfectly good reasons why Cocoa still uses Cocoa events, Menu manager, etc. (which, magically, have no issues running as 64bit). Apple still has yet to get to grips with missing APIs and the general schizophrenic nature of OS X. Apple has quite the GALL to demand developers use incomplete APIs.
? The world is changing, and the new paradigm is platform independence. Instead of leading the way by making Cocoa available everywhere, Apple decided to keep it to themselves meanwhile expunging Carbon which only makes OS X a less relevant platform. The bridge to .NET still sucks and Apple obviously doesn't consider such things relevant while it keeps making itoys for Steve to play with his gay friends. If Apple (or rather Steve) continues on its imperial path of trying to force ObjC down the throats of the barbarians, they will find themselves without even a remnant to remember what Mac OS X ever was.
? There is absolutely NO damned reason to drop Carbon! We have excellent code which uses Carbon every day, and in many cases follows Apple's HI guidelines BETTER than Cocoa equivalents. The lack of a complete Cocoa Mac API has caused a lot of cross-fertilization and dependence on Carbon, but that's better than the alternative of only having Cocoa apps.
What it boils down to is mindless zealotry by fools who have never written Carbon apps.
Unfortunately for them, Apple is in a position of strength now, and so they use that to pull the plug on future versions of Carbon. It'll go the way of QuickDraw3D, QuickDraw, Classic, MacOS 9, etc.
Anyone who thinks or hopes differently has been kidding himself for the last decade.
If Apple doesn't want Carbon, why not give it to Adobe?
Ah, but the truth is Apple can't seem to get off the Carbon diet itself. For all the rhetoric about getting people to use Cocoa, Apple still uses Carbon, including in Cocoa itself!
Why?
Carbon isn't half-bad, in spite of the venom reserved for it every time this discussion crops up. Carbon has a lot of cool stuff which has still yet to emerge in either Cocoa/Foundation or Core* APIs. Unlike OPENSTEP, Mac OS X's language of common denomination is C (thank gawd). The Core* APIs are in C. The kernel modules are in C (with IOKit modules written in a C++ subset). There is no Core Interface because parts of HIToolkit work well here. There is no Core Events because we already have Carbon Events. There is no Core Menus etc.
To put it another way, does it really make sense to draw menus with ObjC calls? Why? Just to make it slower and more memory intensive? Just to make it harder for people not using ObjC? I like Cocoa a lot, but there's no reason to force Adobe et al. to use it. What difference does it make to you or I?
There needs to be a C equivalent unless you're going to rip out the whole ABI and do it the OPENSTEP way all over again, or perhaps replace it with .NET or something (which, BTW, would be easier in OS X than OPENSTEP).
Now the 64bit versions of these have become private. Why? Politics. Now that "Apple is in a position of strength" they can screw a large portion of its users so long they keep buying iPods.
Carbon apps are often faster than Cocoa apps. In fact, this is usually the case.
I use both APIs, and while Cocoa is usually quicker to develop the claim that Cocoa apps are "much faster" is absurd. It's like expecting Gnome apps to run faster than GTK ones.
This is not an issue with programs which are already multiplatform, and isn't much of an issue with most other Carbon apps.
The sad fact is Apple yanked 64bit Carbon just before it hit beta for political reasons. It has nothing to do with feasibility or practicality and everything to do with what stick is up Lord Steve's ass at the moment.
Another sad fact is that Cocoa can't replace Carbon for all things, and for a variety of reasons:
? Cocoa is a higher level API than Carbon written in a different language. It would make as much sense to replace Carbon with Swing. This affects not only Photoshop, but all non-Cocoa APIs, which are many because Cocoa is not an all-encompassing framework. Carbon had deficits here, too, which is why Apple's 'Core' APIs were made and are being extended. Cocoa is better thought of as a good replacement for PowerPlant or MacApp. ObjC is better than C++, hallelujah, but why remove the C hooks altogether?
? Cocoa was written in the UNIX methodology which has human interface repercussions. There is no Cocoa FSRef equivalent, there is no Cocoa alias equivalent, and there is no Cocoa equivalent for a lot of low-level event handling. There are perfectly good reasons why Cocoa still uses Cocoa events, Menu manager, etc. (which, magically, have no issues running as 64bit). Apple still has yet to get to grips with missing APIs and the general schizophrenic nature of OS X. Apple has quite the GALL to demand developers use incomplete APIs.
? The world is changing, and the new paradigm is platform independence. Instead of leading the way by making Cocoa available everywhere, Apple decided to keep it to themselves meanwhile expunging Carbon which only makes OS X a less relevant platform. The bridge to .NET still sucks and Apple obviously doesn't consider such things relevant while it keeps making itoys for Steve to play with his gay friends. If Apple (or rather Steve) continues on its imperial path of trying to force ObjC down the throats of the barbarians, they will find themselves without even a remnant to remember what Mac OS X ever was.
? There is absolutely NO damned reason to drop Carbon! We have excellent code which uses Carbon every day, and in many cases follows Apple's HI guidelines BETTER than Cocoa equivalents. The lack of a complete Cocoa Mac API has caused a lot of cross-fertilization and dependence on Carbon, but that's better than the alternative of only having Cocoa apps.
What it boils down to is mindless zealotry by fools who have never written Carbon apps.
Rip out all the Carbon. This clusterf*** of C programming APIs that was the streamlining of over 5,000 APIs that were in a state of disarray at Apple during the merger has been a real dead weight.
I suggest Apple release Carbon to the Open Source Community to maintain if they want it. But once it's gone, it's a big weight off the system and the design of the system can move to where the rest of it is and was intended to be.
I also understand the drive to deprecate some APIs. Apple did the same thing when System 7 was released, and it was a good thing. For example, files were no longer to be referred to by their path.
Now we're devolving.
I also understand why QuickDraw has been deprecated. At least QuickDraw has an alternative which is superior in nearly every way (and available in C).
Cocoa is still the OPENSTEP API trying to masquerade as a Mac API. Apple could have taken positive steps to improve it, but instead it seems to be the API which was chiseled in stone by the gods and can't have any of its calls deprecated. Unreal!
Rip out all the Carbon. This clusterf*** of C programming APIs that was the streamlining of over 5,000 APIs that were in a state of disarray at Apple during the merger has been a real dead weight.
Since the API hasn't changed since then, why is it a dead weight? It's no more a dead weight than stdlib.
Quote:
I suggest Apple release Carbon to the Open Source Community to maintain if they want it. But once it's gone, it's a big weight off the system and the design of the system can move to where the rest of it is and was intended to be.
I'd endorse releasing the code whole-heartedly, but what chance have we that this will ever happen? In fact, when has this ever happened? QuickDraw3D lived on as quesa, but without any of the original source.
Apple even ported large portions of it to Windows so QuickTime would work, but told everyone not to use it because they didn't want Mac apps ported to Windows (unless it was THEIR apps). The same happened to Foundation for Windows.
I do find your phrase "where the rest of it is and was intended to be" highly amusing. Mac OS X was and will always be a work in progress. It's a tool, and Photoshop users (and developers) happen to use that tool, but only so long it is useful for them. Removing tools while providing poor alternatives makes no sense.
Wistful nostalgia for a funky system called OPENSTEP reminds me of Amiga fan.
Now that article was was saying "No 64bit in CS3" - but they didn't say it was coming in CS4 either - so something happened here, and Apple pulling 64 bit out of Carbon may have been retaliatory, because Photoshop is the biggest Carbon app that would use Carbon 64.
Adobe is really asking - no - begging for Apples wrath by doing 64 bit just on Windows. They wouldn't dream of giving Mac the advantage in any release.
The question now is, is Apple pissed enough over the whole situation to compete with the Creative Suite.
All I'm saying is it tends to be a little difficult for some developers who believed that Carbon would be supported.
I personally think the Cocoa move was inevitable and a good thing.
But still if Apple tells you Carbons good to go and then changes that....Owcha mamma for some
But if it is easier to write for and you get better performance out of Cocoa, why wouldn't you want to move toward that. It isn't like they are totally getting rid of carbon, it is still there, they just aren't going to be 64-Bit, considering much of Carbon's code still has a ton of Classic code in it, it makes perfect sense that it can't go 64-Bit. Not a huge deal now, but eventually Carbon WILL disappear completely. Apple isn't blaming anyone and I can't figure out why people here think Apple did this just to spite Adobe, they have nothing to gain from that. But Adobe shot themselves in the foot when they did not develop in Cocoa years ago, before the complete product line got so big. It is easier to do this stuff when it is smaller. I can understand it will be a lot of work, but CS4 won't be for a while, and perhaps Adobe will be able to breakthrough and do the transition faster than they are guessing. Frankly, I just don't understand why they didn't push for Cocoa some time ago, things just run so much better in it. Apple IS gaining marketshare and I still believe no matter how much work rewriting for cocoa is, it has to be better than developing for Vista.
I said 5x-- that's the number Adobe is quoting. You're talking 10s on Windows and a minute on the Mac. Or a minute on Windows and 5 minutes on the Mac.
It might not cause people to shift en-masse, but if you're already a mixed Mac/PC shop, buying a Mac for Photoshop in the next two years is pretty silly. Buy the Windows PC.
Adobe isn't going to lose many sales over this, but Apple sure will.
Why can't you buy a Mac and run XP/Vista on it? Doesn't the whole switch to Intel thing help the mixed shops run one hardware base? You want faster, nothing is faster for Windows than putting it on a Mac. Maybe I just don't get it.....
Wait, aren't Apple's Pro Apps 64-bit capable? I thought Final Cut Pro and others were.
This problem does not affect only Adobe. I am a composer and use the Vienna Symphonic Library's Vienna Instruments sample library which has its own dedicated sample player. This sample player is one of the most brilliantly designed, flexible and intuitive applications I've ever seen.
Like other developers who attended the WWDC 2006, the folks at VSL believed that Apple would do as it promised and release a 64 bit version of Carbon - -which would have made creating 64 bit versions of VSL's software for both OSX and Windows relatively easy. (VSL is a small company and needs to produce both OSX and Windows versions of their products to survive. While Macs dominate in the music industry in the US, PCs dominate it in Europe.)
The result is that VSL has already released a 64 bit Windows version of their software, while Mac users will have to wait for many more months to have 64 bit OSX version. Luckily enough, for Mac users the VSL folks have created a workaround. The user can copy and recopy the Vienna Ensemble host application, giving each iteration a different name so that one can run multiple instances of the host application each with 2.5GBs of samples loaded. (This is because each iteration creates its own memory partition.) However, the 64 bit Windows version has been successfully tested with 30 GB of samples running in one instance, a much more elegant way of doing things. And then there is the fact that, even if there were an OSX compatible version of the Vienna Instruments software, it might be problematic to run it as a plugin in the still 32 bit version of Logic that Apple currently produces.
In this instance, Apple's decision to abandon a 64 bit version of Carbon, has had negative impact on a small but profoundly creative developer - - and on professional end users. Quite a number of musicians who use this library have purchased MacPro desktops, but run (although they don't really like doing so) Vista 64 as the OS just so they can gain direct access to large amounts of RAM for this library.
Why can't you buy a Mac and run XP/Vista on it? Doesn't the whole switch to Intel thing help the mixed shops run one hardware base? You want faster, nothing is faster for Windows than putting it on a Mac. Maybe I just don't get it.....
But if it is easier to write for and you get better performance out of Cocoa, why wouldn't you want to move toward that. It isn't like they are totally getting rid of carbon, it is still there, they just aren't going to be 64-Bit, considering much of Carbon's code still has a ton of Classic code in it, it makes perfect sense that it can't go 64-Bit.
What an absurd post.
First of all it isn't always easier to write in Cocoa, especially when you have your own platform neutral interface code in C++. If you're writing a Mac-only app, then 9 times out of 10 it's easier to write in Cocoa. This isn't the case here. You don't get "better performance" by using Cocoa, either.
What on earth do you mean by "considering much of Carbon's code still has a ton of Classic code in it"? This makes no sense whatsoever. What would you define as "Classic" code? Is it code which didn't make it into QuickTime for Windows?
64 Carbon was a reality. It was functioning and ready to go into beta testing (released to developers as a working preview). It was axed.
Quote:
Not a huge deal now, but eventually Carbon WILL disappear completely. Apple isn't blaming anyone and I can't figure out why people here think Apple did this just to spite Adobe, they have nothing to gain from that. But Adobe shot themselves in the foot when they did not develop in Cocoa years ago, before the complete product line got so big. It is easier to do this stuff when it is smaller. I can understand it will be a lot of work, but CS4 won't be for a while, and perhaps Adobe will be able to breakthrough and do the transition faster than they are guessing. Frankly, I just don't understand why they didn't push for Cocoa some time ago, things just run so much better in it. Apple IS gaining marketshare and I still believe no matter how much work rewriting for cocoa is, it has to be better than developing for Vista.
Why does everybody feel pressured to post about something they don't have a clue about?
Do you code for Carbon? Do you code for Cocoa? Do you code for Vista?
In this instance, Apple's decision to abandon a 64 bit version of Carbon, has had negative impact on a small but profoundly creative developer - - and on professional end users. Quite a number of musicians who use this library have purchased MacPro desktops, but run (although they don't really like doing so) Vista 64 as the OS just so they can gain direct access to large amounts of RAM for this library.
Indeed. It's obviously not a sane business decision. Most pro apps are written in Carbon. Most Cocoa apps are silly toys in comparison. That isn't because Cocoa is inherently inferior, but because it is relatively unknown, doesn't have low-level hooks, is MacOS-only, and is missing functionality. This autocratic hard-handedness is best reserved for the knuckle-heads who refuse to improve Cocoa.
Mac OS X is a tool. Removing functionality is insanely stupid.
I said 5x-- that's the number Adobe is quoting. You're talking 10s on Windows and a minute on the Mac. Or a minute on Windows and 5 minutes on the Mac.
It might not cause people to shift en-masse, but if you're already a mixed Mac/PC shop, buying a Mac for Photoshop in the next two years is pretty silly. Buy the Windows PC.
Adobe isn't going to lose many sales over this, but Apple sure will.
Lots of commotion about nothing by folks most of whom are obviously not Mac graphics pros on strong Mac Pro boxes. I use PSCS3 on a Mac constantly. Statements like "You're talking 10s on Windows and a minute on the Mac. Or a minute on Windows and 5 minutes on the Mac." are absolutely ludicrous. Far less than 0.1% of PS usage is on files that huge. A DSLR image capture from a Nikon D2x or D3 starts life at ~20 MB size; the example used for 5x speed increase is for 3.75 GB size; largely a theoretical example! In graphics work 1 GB files are not that uncommon, but 3.75 GB sized files are very uncommon.
It is very, very difficult to create files that slow on a Mac Pro with 16 GB or more of RAM even today and on OS 10.5.2, because the OS works with PS to take advantage of way more than the ~3 GB RAM that PSCS3 can directly address. Future OS versions and MP versions will no doubt do an even better job accessing RAM irrespective of what CS4 directly addresses.
PSCS3 is already fast enough on a properly equipped Mac Pro that folks like me do not even consider PS when optimizing a new box setup. Instead I optimize for Aperture, a killer newish app but a hardware hog. The only thing I do specifically for PS is make sure an independent fast scratch drive is available.
CS4 full 64-bit vs. 32-bit on Macs is just not a big deal. <yawn> An Adobe engineer had a blog last year on the subject:
By the way, in the spirit of sharing info where public, I'll note that we surveyed 1,600 Photoshop customers last summer & found that roughly 4% were using a 64-bit version of Windows. --J.
in response to this comment:
Quote:
Unlike the Mac OS which runs out of the box 32-bit and 64-bit Intel and PPC, there is no such compatibility with Windows. You either buy 32-bit Vista or 64-bit Vista and apps appropriate to each, which means I can count the number of 64-bit Vista users on my toes. That just sounds like a complete waste of effort.
By the time CS5 with 64 bit is out, cloud computing is up and running, so do we really need CS5.
Please be realistic how fast is the fast, I am a designer and photographer, it is not the speed of the cpu or whatever that is holding back the job, it is the human factor in other words us.
Adobe has been known and still is producing bloatware and i don't use indesign but forced to use photoshop and photoshop 10 is more than enough to accomplish any job so do I need to upgrade the answer is no.
Will Apple lose sales over this, they might. Will Mac users be looking for alternatives to Adobe stuffs, the answer is definitely. The important point is will Aperture be as good as photoshop I believe it will, we will see over the years.
And will cloud computing answers all our problem I hope so and the faster the bandwidth the faster my computer computes, no more 64 bit computers (being a layman I may be wrong here)
I suppose this thread was fated to turn into a Carbon vs. Cocoa slugfest, since discussing 64bitness is just boring.
The simple fact here is that Adobe did not get unfairly shafted by Apple. By ignoring the call to start re-coding their star app for over a decade, they left themselves wide open to this.
And we can add Intuit to that list also. Those geniuses only got started very recently too.
I understand the point that strobe is making, pointing out that Carbon is more complete and battle tested than Cocoa, and that optimizations need to be made so that Cocoa apps run just as smooth and fast as what we're accustomed to.
But Apple ate their own dog food here for ten years, coding their own huge apps like Finder, iTunes and Final Cut with Carbon. This is a big part of why Carbon APIs are so developer-ready.
If Apple doesn't make this break now, the platform will end up with two average APIs, instead of one great one. This is the best decision for the future of the platform, and griping from a few developers who claim not to have seen the writing on the wall won't change that.
Hopefully, those developers who have already embarked down the Cocoa road are being pro-active in letting Apple know precisely what's missing in Cocoa. I'm sure Apple has a clue though, since they've known about this issue for a year and Phenomenon and the next generation of Final Cut can't be that far away.
So once again Adobe are saying that if we want to take full advantage of the current OS we'll need to wait on the next iteration of their software.
Great. So what's new?
If CS4 doesn't provide support for 64-bit then what will it provide, stability with 10.5?
The commercial arts market is ripe for a new developer to come in and wipe the floor with the likes of Adobe. Adobe has become lazy, and lazy companies have a habit of falling from favour (just look at Quark).
Either Apple has to start writing it's own commercial arts software, or Adobe has to write its own OS.
Comments
This will only hurt Adobe.
Certainly Adobe is out there to make money. And for the last several years they've probably been very distracted just trying to keep up with Apple's shifting direction. First the move to Intel meant that they had to switch compilers and IDEs for their entire Macintosh suite, then debug everything for two processors. Now with Apple doing an about-face on Carbon64 support, they have to do another fire drill. It's amazing they get stuff out for the Mac at all, let alone have time to do Mac-specific things with the way Apple treats its developers.
Well, ever since Rhapsody, the writing was on the wall. Apple never wanted to do Carbon, it was always YellowBox aka Cocoa that was going to inherit the throne.
Big developers like Adobe and Microsoft were going ape about having to port to an API that would give the Mac a major leverage in capability, but would undermine these big guys' cross-platform crap. It's much easier to wrap Carbon and Win APIs into wrappers of an internal cross-platform API than it's to do the same with Cocoa and Win APIs. (One reason being that both Win and Carbon APIs are ultimately derived and inspired by the original Mac API, while Cocoa is a fundamental redesign.
So since the big guys didn't go along willingly, Apple was forced into a ruse. They at a time of weakness were forced to give in and do Carbon, and ever since they have both provided push and pull incentives to go from Carbon to Cocoa. Any developer who like Adobe pretends they though they could have gotten away with sticking to Carbon forever was either blind or hoping that their size and importance would force Apple to do as they ask for.
Unfortunately for them, Apple is in a position of strength now, and so they use that to pull the plug on future versions of Carbon. It'll go the way of QuickDraw3D, QuickDraw, Classic, MacOS 9, etc.
Anyone who thinks or hopes differently has been kidding himself for the last decade.
It has been clear from the beginning that Carbon wouldn't be around for ever.
Further, the fact that images continue to grow and are expected to exceed 4GB, is unavoidable. Didn't Adobe see this problem coming?
They could have saved a lot of time because development under Cocoa is
Name one 'thing' of this nature.
Carbon apps are often faster than Cocoa apps. In fact, this is usually the case.
I use both APIs, and while Cocoa is usually quicker to develop the claim that Cocoa apps are "much faster" is absurd. It's like expecting Gnome apps to run faster than GTK ones.
As already pointed out in previous posts, they would have gotten the transition from PPC to Intel almost without effort, had they switched to Cocoa
This is not an issue with programs which are already multiplatform, and isn't much of an issue with most other Carbon apps.
The sad fact is Apple yanked 64bit Carbon just before it hit beta for political reasons. It has nothing to do with feasibility or practicality and everything to do with what stick is up Lord Steve's ass at the moment.
Another sad fact is that Cocoa can't replace Carbon for all things, and for a variety of reasons:
? Cocoa is a higher level API than Carbon written in a different language. It would make as much sense to replace Carbon with Swing. This affects not only Photoshop, but all non-Cocoa APIs, which are many because Cocoa is not an all-encompassing framework. Carbon had deficits here, too, which is why Apple's 'Core' APIs were made and are being extended. Cocoa is better thought of as a good replacement for PowerPlant or MacApp. ObjC is better than C++, hallelujah, but why remove the C hooks altogether?
? Cocoa was written in the UNIX methodology which has human interface repercussions. There is no Cocoa FSRef equivalent, there is no Cocoa alias equivalent, and there is no Cocoa equivalent for a lot of low-level event handling. There are perfectly good reasons why Cocoa still uses Cocoa events, Menu manager, etc. (which, magically, have no issues running as 64bit). Apple still has yet to get to grips with missing APIs and the general schizophrenic nature of OS X. Apple has quite the GALL to demand developers use incomplete APIs.
? The world is changing, and the new paradigm is platform independence. Instead of leading the way by making Cocoa available everywhere, Apple decided to keep it to themselves meanwhile expunging Carbon which only makes OS X a less relevant platform. The bridge to .NET still sucks and Apple obviously doesn't consider such things relevant while it keeps making itoys for Steve to play with his gay friends. If Apple (or rather Steve) continues on its imperial path of trying to force ObjC down the throats of the barbarians, they will find themselves without even a remnant to remember what Mac OS X ever was.
? There is absolutely NO damned reason to drop Carbon! We have excellent code which uses Carbon every day, and in many cases follows Apple's HI guidelines BETTER than Cocoa equivalents. The lack of a complete Cocoa Mac API has caused a lot of cross-fertilization and dependence on Carbon, but that's better than the alternative of only having Cocoa apps.
What it boils down to is mindless zealotry by fools who have never written Carbon apps.
i wasnt at wwdc, i was living in a field 8000 miles away, but Apple still managed to make it clear to me (and anyone else with ears and/or eyes) also.
Carbon was a temporary measure, and thats that.
Careful now, you might be accused of telling the truth and Adobe having to admit it lied and strong-armed Apple for years.
Unfortunately for them, Apple is in a position of strength now, and so they use that to pull the plug on future versions of Carbon. It'll go the way of QuickDraw3D, QuickDraw, Classic, MacOS 9, etc.
Anyone who thinks or hopes differently has been kidding himself for the last decade.
If Apple doesn't want Carbon, why not give it to Adobe?
Ah, but the truth is Apple can't seem to get off the Carbon diet itself. For all the rhetoric about getting people to use Cocoa, Apple still uses Carbon, including in Cocoa itself!
Why?
Carbon isn't half-bad, in spite of the venom reserved for it every time this discussion crops up. Carbon has a lot of cool stuff which has still yet to emerge in either Cocoa/Foundation or Core* APIs. Unlike OPENSTEP, Mac OS X's language of common denomination is C (thank gawd). The Core* APIs are in C. The kernel modules are in C (with IOKit modules written in a C++ subset). There is no Core Interface because parts of HIToolkit work well here. There is no Core Events because we already have Carbon Events. There is no Core Menus etc.
To put it another way, does it really make sense to draw menus with ObjC calls? Why? Just to make it slower and more memory intensive? Just to make it harder for people not using ObjC? I like Cocoa a lot, but there's no reason to force Adobe et al. to use it. What difference does it make to you or I?
There needs to be a C equivalent unless you're going to rip out the whole ABI and do it the OPENSTEP way all over again, or perhaps replace it with .NET or something (which, BTW, would be easier in OS X than OPENSTEP).
Now the 64bit versions of these have become private. Why? Politics. Now that "Apple is in a position of strength" they can screw a large portion of its users so long they keep buying iPods.
Name one 'thing' of this nature.
Carbon apps are often faster than Cocoa apps. In fact, this is usually the case.
I use both APIs, and while Cocoa is usually quicker to develop the claim that Cocoa apps are "much faster" is absurd. It's like expecting Gnome apps to run faster than GTK ones.
This is not an issue with programs which are already multiplatform, and isn't much of an issue with most other Carbon apps.
The sad fact is Apple yanked 64bit Carbon just before it hit beta for political reasons. It has nothing to do with feasibility or practicality and everything to do with what stick is up Lord Steve's ass at the moment.
Another sad fact is that Cocoa can't replace Carbon for all things, and for a variety of reasons:
? Cocoa is a higher level API than Carbon written in a different language. It would make as much sense to replace Carbon with Swing. This affects not only Photoshop, but all non-Cocoa APIs, which are many because Cocoa is not an all-encompassing framework. Carbon had deficits here, too, which is why Apple's 'Core' APIs were made and are being extended. Cocoa is better thought of as a good replacement for PowerPlant or MacApp. ObjC is better than C++, hallelujah, but why remove the C hooks altogether?
? Cocoa was written in the UNIX methodology which has human interface repercussions. There is no Cocoa FSRef equivalent, there is no Cocoa alias equivalent, and there is no Cocoa equivalent for a lot of low-level event handling. There are perfectly good reasons why Cocoa still uses Cocoa events, Menu manager, etc. (which, magically, have no issues running as 64bit). Apple still has yet to get to grips with missing APIs and the general schizophrenic nature of OS X. Apple has quite the GALL to demand developers use incomplete APIs.
? The world is changing, and the new paradigm is platform independence. Instead of leading the way by making Cocoa available everywhere, Apple decided to keep it to themselves meanwhile expunging Carbon which only makes OS X a less relevant platform. The bridge to .NET still sucks and Apple obviously doesn't consider such things relevant while it keeps making itoys for Steve to play with his gay friends. If Apple (or rather Steve) continues on its imperial path of trying to force ObjC down the throats of the barbarians, they will find themselves without even a remnant to remember what Mac OS X ever was.
? There is absolutely NO damned reason to drop Carbon! We have excellent code which uses Carbon every day, and in many cases follows Apple's HI guidelines BETTER than Cocoa equivalents. The lack of a complete Cocoa Mac API has caused a lot of cross-fertilization and dependence on Carbon, but that's better than the alternative of only having Cocoa apps.
What it boils down to is mindless zealotry by fools who have never written Carbon apps.
Rip out all the Carbon. This clusterf*** of C programming APIs that was the streamlining of over 5,000 APIs that were in a state of disarray at Apple during the merger has been a real dead weight.
I suggest Apple release Carbon to the Open Source Community to maintain if they want it. But once it's gone, it's a big weight off the system and the design of the system can move to where the rest of it is and was intended to be.
Now we're devolving.
I also understand why QuickDraw has been deprecated. At least QuickDraw has an alternative which is superior in nearly every way (and available in C).
Cocoa is still the OPENSTEP API trying to masquerade as a Mac API. Apple could have taken positive steps to improve it, but instead it seems to be the API which was chiseled in stone by the gods and can't have any of its calls deprecated. Unreal!
Rip out all the Carbon. This clusterf*** of C programming APIs that was the streamlining of over 5,000 APIs that were in a state of disarray at Apple during the merger has been a real dead weight.
Since the API hasn't changed since then, why is it a dead weight? It's no more a dead weight than stdlib.
I suggest Apple release Carbon to the Open Source Community to maintain if they want it. But once it's gone, it's a big weight off the system and the design of the system can move to where the rest of it is and was intended to be.
I'd endorse releasing the code whole-heartedly, but what chance have we that this will ever happen? In fact, when has this ever happened? QuickDraw3D lived on as quesa, but without any of the original source.
Apple even ported large portions of it to Windows so QuickTime would work, but told everyone not to use it because they didn't want Mac apps ported to Windows (unless it was THEIR apps). The same happened to Foundation for Windows.
I do find your phrase "where the rest of it is and was intended to be" highly amusing. Mac OS X was and will always be a work in progress. It's a tool, and Photoshop users (and developers) happen to use that tool, but only so long it is useful for them. Removing tools while providing poor alternatives makes no sense.
Wistful nostalgia for a funky system called OPENSTEP reminds me of Amiga fan.
So why is the PC getting 64-bitness if the Mac can't?
The confusing thing is - here Adobe makes it clear that 64bit isn't coming anytime soon: http://www.news.com/8301-10784_3-6146229-7.html
Now that article was was saying "No 64bit in CS3" - but they didn't say it was coming in CS4 either - so something happened here, and Apple pulling 64 bit out of Carbon may have been retaliatory, because Photoshop is the biggest Carbon app that would use Carbon 64.
Adobe is really asking - no - begging for Apples wrath by doing 64 bit just on Windows. They wouldn't dream of giving Mac the advantage in any release.
The question now is, is Apple pissed enough over the whole situation to compete with the Creative Suite.
All I'm saying is it tends to be a little difficult for some developers who believed that Carbon would be supported.
I personally think the Cocoa move was inevitable and a good thing.
But still if Apple tells you Carbons good to go and then changes that....Owcha mamma for some
But if it is easier to write for and you get better performance out of Cocoa, why wouldn't you want to move toward that. It isn't like they are totally getting rid of carbon, it is still there, they just aren't going to be 64-Bit, considering much of Carbon's code still has a ton of Classic code in it, it makes perfect sense that it can't go 64-Bit. Not a huge deal now, but eventually Carbon WILL disappear completely. Apple isn't blaming anyone and I can't figure out why people here think Apple did this just to spite Adobe, they have nothing to gain from that. But Adobe shot themselves in the foot when they did not develop in Cocoa years ago, before the complete product line got so big. It is easier to do this stuff when it is smaller. I can understand it will be a lot of work, but CS4 won't be for a while, and perhaps Adobe will be able to breakthrough and do the transition faster than they are guessing. Frankly, I just don't understand why they didn't push for Cocoa some time ago, things just run so much better in it. Apple IS gaining marketshare and I still believe no matter how much work rewriting for cocoa is, it has to be better than developing for Vista.
I said 5x-- that's the number Adobe is quoting. You're talking 10s on Windows and a minute on the Mac. Or a minute on Windows and 5 minutes on the Mac.
It might not cause people to shift en-masse, but if you're already a mixed Mac/PC shop, buying a Mac for Photoshop in the next two years is pretty silly. Buy the Windows PC.
Adobe isn't going to lose many sales over this, but Apple sure will.
Why can't you buy a Mac and run XP/Vista on it? Doesn't the whole switch to Intel thing help the mixed shops run one hardware base? You want faster, nothing is faster for Windows than putting it on a Mac. Maybe I just don't get it.....
You're right, my mistake.
Wait, aren't Apple's Pro Apps 64-bit capable? I thought Final Cut Pro and others were.
This problem does not affect only Adobe. I am a composer and use the Vienna Symphonic Library's Vienna Instruments sample library which has its own dedicated sample player. This sample player is one of the most brilliantly designed, flexible and intuitive applications I've ever seen.
Like other developers who attended the WWDC 2006, the folks at VSL believed that Apple would do as it promised and release a 64 bit version of Carbon - -which would have made creating 64 bit versions of VSL's software for both OSX and Windows relatively easy. (VSL is a small company and needs to produce both OSX and Windows versions of their products to survive. While Macs dominate in the music industry in the US, PCs dominate it in Europe.)
The result is that VSL has already released a 64 bit Windows version of their software, while Mac users will have to wait for many more months to have 64 bit OSX version. Luckily enough, for Mac users the VSL folks have created a workaround. The user can copy and recopy the Vienna Ensemble host application, giving each iteration a different name so that one can run multiple instances of the host application each with 2.5GBs of samples loaded. (This is because each iteration creates its own memory partition.) However, the 64 bit Windows version has been successfully tested with 30 GB of samples running in one instance, a much more elegant way of doing things. And then there is the fact that, even if there were an OSX compatible version of the Vienna Instruments software, it might be problematic to run it as a plugin in the still 32 bit version of Logic that Apple currently produces.
In this instance, Apple's decision to abandon a 64 bit version of Carbon, has had negative impact on a small but profoundly creative developer - - and on professional end users. Quite a number of musicians who use this library have purchased MacPro desktops, but run (although they don't really like doing so) Vista 64 as the OS just so they can gain direct access to large amounts of RAM for this library.
Why can't you buy a Mac and run XP/Vista on it? Doesn't the whole switch to Intel thing help the mixed shops run one hardware base? You want faster, nothing is faster for Windows than putting it on a Mac. Maybe I just don't get it.....
But if it is easier to write for and you get better performance out of Cocoa, why wouldn't you want to move toward that. It isn't like they are totally getting rid of carbon, it is still there, they just aren't going to be 64-Bit, considering much of Carbon's code still has a ton of Classic code in it, it makes perfect sense that it can't go 64-Bit.
What an absurd post.
First of all it isn't always easier to write in Cocoa, especially when you have your own platform neutral interface code in C++. If you're writing a Mac-only app, then 9 times out of 10 it's easier to write in Cocoa. This isn't the case here. You don't get "better performance" by using Cocoa, either.
What on earth do you mean by "considering much of Carbon's code still has a ton of Classic code in it"? This makes no sense whatsoever. What would you define as "Classic" code? Is it code which didn't make it into QuickTime for Windows?
64 Carbon was a reality. It was functioning and ready to go into beta testing (released to developers as a working preview). It was axed.
Not a huge deal now, but eventually Carbon WILL disappear completely. Apple isn't blaming anyone and I can't figure out why people here think Apple did this just to spite Adobe, they have nothing to gain from that. But Adobe shot themselves in the foot when they did not develop in Cocoa years ago, before the complete product line got so big. It is easier to do this stuff when it is smaller. I can understand it will be a lot of work, but CS4 won't be for a while, and perhaps Adobe will be able to breakthrough and do the transition faster than they are guessing. Frankly, I just don't understand why they didn't push for Cocoa some time ago, things just run so much better in it. Apple IS gaining marketshare and I still believe no matter how much work rewriting for cocoa is, it has to be better than developing for Vista.
Why does everybody feel pressured to post about something they don't have a clue about?
Do you code for Carbon? Do you code for Cocoa? Do you code for Vista?
In this instance, Apple's decision to abandon a 64 bit version of Carbon, has had negative impact on a small but profoundly creative developer - - and on professional end users. Quite a number of musicians who use this library have purchased MacPro desktops, but run (although they don't really like doing so) Vista 64 as the OS just so they can gain direct access to large amounts of RAM for this library.
Indeed. It's obviously not a sane business decision. Most pro apps are written in Carbon. Most Cocoa apps are silly toys in comparison. That isn't because Cocoa is inherently inferior, but because it is relatively unknown, doesn't have low-level hooks, is MacOS-only, and is missing functionality. This autocratic hard-handedness is best reserved for the knuckle-heads who refuse to improve Cocoa.
Mac OS X is a tool. Removing functionality is insanely stupid.
I said 5x-- that's the number Adobe is quoting. You're talking 10s on Windows and a minute on the Mac. Or a minute on Windows and 5 minutes on the Mac.
It might not cause people to shift en-masse, but if you're already a mixed Mac/PC shop, buying a Mac for Photoshop in the next two years is pretty silly. Buy the Windows PC.
Adobe isn't going to lose many sales over this, but Apple sure will.
Lots of commotion about nothing by folks most of whom are obviously not Mac graphics pros on strong Mac Pro boxes. I use PSCS3 on a Mac constantly. Statements like "You're talking 10s on Windows and a minute on the Mac. Or a minute on Windows and 5 minutes on the Mac." are absolutely ludicrous. Far less than 0.1% of PS usage is on files that huge. A DSLR image capture from a Nikon D2x or D3 starts life at ~20 MB size; the example used for 5x speed increase is for 3.75 GB size; largely a theoretical example! In graphics work 1 GB files are not that uncommon, but 3.75 GB sized files are very uncommon.
It is very, very difficult to create files that slow on a Mac Pro with 16 GB or more of RAM even today and on OS 10.5.2, because the OS works with PS to take advantage of way more than the ~3 GB RAM that PSCS3 can directly address. Future OS versions and MP versions will no doubt do an even better job accessing RAM irrespective of what CS4 directly addresses.
PSCS3 is already fast enough on a properly equipped Mac Pro that folks like me do not even consider PS when optimizing a new box setup. Instead I optimize for Aperture, a killer newish app but a hardware hog. The only thing I do specifically for PS is make sure an independent fast scratch drive is available.
CS4 full 64-bit vs. 32-bit on Macs is just not a big deal. <yawn> An Adobe engineer had a blog last year on the subject:
http://blogs.adobe.com/scottbyer/
-Allen Wicks
By the way, in the spirit of sharing info where public, I'll note that we surveyed 1,600 Photoshop customers last summer & found that roughly 4% were using a 64-bit version of Windows. --J.
in response to this comment:
Unlike the Mac OS which runs out of the box 32-bit and 64-bit Intel and PPC, there is no such compatibility with Windows. You either buy 32-bit Vista or 64-bit Vista and apps appropriate to each, which means I can count the number of 64-bit Vista users on my toes. That just sounds like a complete waste of effort.
Please be realistic how fast is the fast, I am a designer and photographer, it is not the speed of the cpu or whatever that is holding back the job, it is the human factor in other words us.
Adobe has been known and still is producing bloatware and i don't use indesign but forced to use photoshop and photoshop 10 is more than enough to accomplish any job so do I need to upgrade the answer is no.
Will Apple lose sales over this, they might. Will Mac users be looking for alternatives to Adobe stuffs, the answer is definitely. The important point is will Aperture be as good as photoshop I believe it will, we will see over the years.
And will cloud computing answers all our problem I hope so and the faster the bandwidth the faster my computer computes, no more 64 bit computers (being a layman I may be wrong here)
The simple fact here is that Adobe did not get unfairly shafted by Apple. By ignoring the call to start re-coding their star app for over a decade, they left themselves wide open to this.
And we can add Intuit to that list also. Those geniuses only got started very recently too.
I understand the point that strobe is making, pointing out that Carbon is more complete and battle tested than Cocoa, and that optimizations need to be made so that Cocoa apps run just as smooth and fast as what we're accustomed to.
But Apple ate their own dog food here for ten years, coding their own huge apps like Finder, iTunes and Final Cut with Carbon. This is a big part of why Carbon APIs are so developer-ready.
If Apple doesn't make this break now, the platform will end up with two average APIs, instead of one great one. This is the best decision for the future of the platform, and griping from a few developers who claim not to have seen the writing on the wall won't change that.
Hopefully, those developers who have already embarked down the Cocoa road are being pro-active in letting Apple know precisely what's missing in Cocoa. I'm sure Apple has a clue though, since they've known about this issue for a year and Phenomenon and the next generation of Final Cut can't be that far away.
Great. So what's new?
If CS4 doesn't provide support for 64-bit then what will it provide, stability with 10.5?
The commercial arts market is ripe for a new developer to come in and wipe the floor with the likes of Adobe. Adobe has become lazy, and lazy companies have a habit of falling from favour (just look at Quark).
Either Apple has to start writing it's own commercial arts software, or Adobe has to write its own OS.