Adobe Photoshop CS4 Will Be 64-Bit For Windows Only

HighWizard notes that Adobe Systems has shared the first scrap of information about its next version of Photoshop, CS4, and it's a doozy: there will be a 64-bit version of the photo-editing software, but only for Windows Vista and not for Mac OS X. Ars explains the history of how this conundrum came to pass — blame Apple and/or Adobe as you will.

Re:64 bit is no panacea

[joaommp]

Well, it will run faster if you have a large pool of physical memory and do some heavy Photoshop editing, because Photoshop will be able to access more than 3GB of memory (remember that 1GB of the 4GB address space is already reserved for system code sharing) and not resort to it's own swap/disk cache system as much.

Re:64 bit is no panacea

[Anonymous Coward]

It does mean that the app will be able to address more than 4 gig of RAM though, which for a professional image program I could see being useful.

bad summary - there will be a 32-bit version

[Anonymous Coward]

You misread the article:

The Lightroom news naturally raises the question: What's Adobe doing with Photoshop? In the interest of giving customers guidance as early as possible, we have some news to share on this point: in addition to offering 32-bit-native versions for Mac OS X and 32-bit Windows, just as we do today, we plan to ship the next version of Photoshop as 64-bit-native for Windows 64-bit OSes only.

Re:What will happen?

[oahazmatt]

At the WWDC show last June, however, Adobe & other developers learned that Apple had decided to stop their Carbon 64 efforts. This means that 64-bit Mac apps need to be written to use Cocoa (as Lightroom is) instead of Carbon. This means that we'll need to rewrite large parts of Photoshop and its plug-ins (potentially affecting over a million lines of code) to move it from Carbon to Cocoa.

The main reason for the Mac having only the 32-bit (Yes, CS4 will still be available for the Mac) is Adobe does not feel like rewriting an entire program at a moments notice, and I can't say I blame them.

Additionally, this shouldn't rule out the eventuality of a 64-bit Mac version. I would assume it is a goal and it will just not be available at launch.

Re:What will happen?

[nxsty]

If this carries out, this will pretty much end the debate on how Macs are "so much better for image editing than PCs" even though most of us know that that is rubbish. Kinda hard to do image editing when the primary tool used for the job isn't even available for your OS.

What? There will be a version for Mac OSX, but only 32 bit just like the current version.

But AMD64 could be...

[mrchaotica]

Remember, going to 64-bit on x86 can make programs faster, but not because of the extra bits. The speedup comes from the fact that, in addition to increasing the bits, AMD also added a bunch of extra registers to the spec.

Re:What will happen?

[john82]

As a matter of fact, Slashdot once again misleads with the choice of headline and half-the-story lead-in. Just a bit of reading reveals:

On the other hand, we work very hard at maintaining parity across platforms, and it's a drag that the Mac x64 revision will take longer to deliver. We will get there, but not in CS4. (Our goal is to ship a 64-bit Mac version with Photoshop CS5, but we'll be better able to assess that goal as we get farther along in the development process.)

Hmmm. Not the end of the world after all.

Re:I vote Apple

[Anonymous Coward]

You're wrong as of 10.5 Leopard. It's 64-bit completely through.

Re:64 bit is no panacea

[Kjella]

Yep, and memory prices have dropped *extremely* over the last year. If I was working with many and large photoshop images, getting 4x4GB memory wouldn't be out of the question. Honestly I don't need it, but if you're working with high-quality print images I can easily see why you might need that...

Use QT, like the rest of the world

[SwiftX]

Trolltech(/ nokia) is working with Apple to get QT on MacOSX using Cocoa.
Problem solved!
SwiftX

Re:I vote Apple

[dpbsmith]

No, my recollection is that they said exactly the opposite: that Carbon and Cocoa were co-equal and would be kept feature-comparable.

I don't have my notes from WWDC 2000, however.

Re:64 bit is no panacea

[alta]

Unless I'm mistaken the only thing 64bit color has to do with 64bit processing is that they both start with the number 64.

64Bit will allow the computer to deal with more data at a time, no matter what the color depth of the file is... It'll let the program have more memory. That will help a 64bit image if it's BIG, but just because it's BIG, not because it's 64 bit.

Re:I vote Apple

[jcupitt65]

You're thinking of Tiger, I think. Leopard is fully 64-bit. http://www.apple.com/macosx/technology/64bit.html [apple.com]

Re:I vote Apple

[crusty_yet_benign]

They say lots of things.

They also said, as recently as WWDC 2007, that they would DEFINITELY support 64-bit Carbon in OS X. Now, they're shanking Adobe (and anyone else who believed them), by 'decommitting' from their previous commitment.

I'm as much an Apple fanboy as most here (4 macs in my house, only 2 are for work), but don't blame Adobe for trusting Apple.

Re:But AMD64 could be...

[chaosite]

Thats just the thing, they're not 'vendor-specific' registers. They're in the spec for x86-64, and both Intel and AMD implementations support them.

Besides, I think you were thinking of vendor specific instructions (Like SSE1/2/3, MMX, 3DNow!, etc...)

Re:bad summary - there will be a 32-bit version

[langelgjm]

You misread the summary (so did I, at first). It's not "Adobe Photoshop CS4 Will Be For 64-Bit Windows Only," it's "Adobe Photoshop CS4 Will Be 64-Bit For Windows Only."

Re:The blame falls solely on Apple

[Teese]

Apple have never promised 64-bit Carbon.

They did promise 64bit carbon, during the 2006 WWDC. It wasn't until the 2007 WWDC that they rescinded the promise. Before the 2007 WWDC, they backed up the promise with seeds with 64bit carbon support in. They removed that 64bit carbon support in the 2007 WWDC seed. Of course they also slightly redefined what carbon meant. It now means the GUI portions of what used to be called carbon. So there are parts of "carbon" that are 64bit. They just aren't called carbon anymore.

Re:What will happen?

[bhima]

Just want to correct one thing: Aperture is not a replacement for photoshop it is a competitor of Adobe Lightroom. Apple doesn't have a direct replacement for photoshop.

Re:No, blame Adobe

[_|()|\|]

I'm sure Apple was alerting Adobe to the Carbon issue long before WWDC 2007.

Actually, John Gruber claims [daringfireball.net] that's not true:

Several sources have confirmed to me that Adobe found out that Apple was dropping support for 64-bit Carbon at the same time everyone else outside Apple did: on the first day of WWDC 2007.

You are still wrong...

[hummassa]

Okay, stipulated. Regardless, it's the memory address space that allows for the speed improvement when working with large files, not new JMP routines.

JMP routines? Actually, the extra register things is capable of optimizing out _many_, _many_ memory accesses... leaving the path clear for the SIMD instructions to fetch repeatedly only the data that your extended addressing is capable of. Imagine (simplifying a little) some transform being done to an image, that alters some data:

for( all pixels in the image ) { x1 = red(pixel); x2 = (x2 + x1 *2 + 3) % MAX; blue(pixel) = x2 }

if x1, x2 are put in registers then your transform will fetch only the pages where the pixel values are; if x2 is in memory, then _each_ fetch of a page where a pixel are is interleaved with one fetch and one write of the page where x2 is. This means that the operation becomes probably three to four times slower.

Re:64 bit is no panacea

[baadger]

x86_64 is more of a cleanup to the aging x86 ISA. Not only does it future proof the architecture against big memory requirements but it also does away with ancient segmented addresses, provides more CPU registers (leading the the possibility of more specialized register operations, I assume) and generally allows people to break ABI *as a matter of course* which is great because on AMD64 arch's you can *assume* the presence of MMX, SSE, and SSE2 instruction sets. Even Microsoft, anally retentive back-compat evangelists, took the opportunity in Windows XP x64 and Windows 2003 x64 Server to introduce further kernel mode memory protections ('PatchGuard')

No x86 software, *including drivers*, should be shipping in both 64bit and 32bit binary form, all of the problems you mention with 64bit are essentially proprietary software exclusive btw, and just highlight the highly broken software ecosystem Microsoft Windows has fostered.

There will be an x86_64 version for Mac...

[leamanc]

...but the Windows version is just coming out first. It's not like Adobe is totally abandoning 64 bit apps on the Mac. It's just that re-writing millions of lines of Carbon code is going to take a bit longer.

If you read the Ars article, and John Nack's blog at Adobe, you get a sense of the history involved here. Back when Apple's next-gen OS was going to be Rhapsody, Apple developers were looking at re-writing all their apps in what came to be known as Cocoa. Many of the big developers, Adobe among them, said "No way, Steve," leading to the birth of Carbon, to allow an easy transition from OS 9 to OS X.

It's been known for a while that Carbon would eventually be deprecated, but that still doesn't change the fact that it's going to be a huge job for Adobe. Adobe shouldn't be chastised for this move. They should be lauded for developing the an x86_64 version for Mac at all, even if its release will lag behind the Windows version.

Re:windows 64bit tradition

[cyberjessy]

I don't know if your comment was meant to be sarcastic, but:

Tiger had very limited 64-bit support (GUI apps ran in 32-bit mode). The fairly recent 10.5 is much better though.

In contrast, the Windows API's were well supported in 64-bit platforms since 2003. (Windows 2003 server, for IA-64 and later X64). While XP 64-bit was pointless, and soon discontinued, Windows APIs remain the same on Server and Client editions.

This would have allowed Adobe to start working on a 64-bit version anytime in the last 5 years.

Re:You are still wrong...

[fitten]

To add to your post, the folks at Cinebench were very happy transitioning from 32-bit land to 64-bit land (x86-64) because they were able to get rid of a lot of cruft and make use of the registers and such to achieve a significant speedup with their 64-bit version over their 32-bit version.

Also, in 32-bit land, you can use blocking algorithms to get by memory limitations. Not all operations must be done over the entire file, requiring all the data be in memory at the same time so it isn't like 32-bit can't do what 64-bit can memory-wise.

Re:64 bit is no panacea

[Overly Critical Guy]

Now Windows has ~90% of the market place and Apple has ~6%.

But not in digital editing, where Apple is the majority. Adobe will eventually release a 64-bit version because Apple users are their biggest customers. They did get screwed with Carbon 64-bit, though.

Re:64 bit is no panacea

[jocknerd]

Yep, Adobe was told that Cocoa was the future for OS X development. And yet, they chose to stick with Carbon. Can't blame Apple for that one. Simple fact is Photoshop is designed for Windows first and then ported. So its not a native Mac app and doesn't take advantage of all the technology in OS X. If you want to see what I'm talking about, take a look at Pixelmator. While its not on par with Photoshop, it combines the power of ImageMagick with the underlying technology from OS X.

Re:64 bit is no panacea

[MidnightBrewer]

Photoshop's legacy is all Apple. If you've ever tried to use Photoshop in Windows from, say 4.0 on (about the time I tried using it on Windows, instead of my Mac, where I started at 2.5), you'd know how horribly awkward it was compared to its smooth operation on the Mac OS. Adobe has been criticized on the Windows side for having a Mac-like interface as well, which Windows users have been forced to just get used to.

Adobe has a long legacy of making sure their application is rock-solid and reliable before releasing. They, of any company, were the ones to set the bar for what it's like to release incredibly stable, bug-free software without any major point release dramas to fix glaring mistakes.

Yes, ever since they decided it was a good idea to put a salesman at the head of the company who believes that it's not what you sell, but how you sell it that's important, they've started going down a bad road. Their subsequent attempts to lock the system down with draconian DRM etc. has not improved their image much. However, there is no way to compare Pixelmator to Photoshop. Pixelmator can afford to be nimble because it has no expectations to live up to and is a relatively limited application with little utility in comparison.

Photoshop is a (reasonably) well-thought-out system of utilities and tools that have always done a darn good job working within the limits of the processor and memory and still manage to offer speedy, capable performance and a comprehensive 3rd-party plugin architecture. Adobe's main crutch is that they can't afford to simply throw away doing things the way they've always done in order to move forward; their own success has locked them into evolutionary, rather than revolutionary, progress.

Re:64 bit is no panacea

[dishpig]

You clearly don't know what you're talking about - there is (and has been for at least 10 years) a feature complete education version of Adobe Photoshop . Currently priced at $299. Somewhat reasonable if you consider it's a primary tool in your field. I've spent more than that on books for a single course.

The difference between a commercial version of Photoshop and an Education version of Photoshop is the splash screen and the license: education versions are not to be used for commercial projects. In other words, they're for learning, not making money on. That's the whole point - get it into student's hands so it is the tool they are comfortable using. That way they'll be more likely to want to use it in the future, when they are in the workforce. It's in Adobe's interests to make it feature complete.

The 'hoops' you are referring to seem to be a function of your institution's license and/or misinformation about the product. Any student could purchase a stand-alone, boxed education version of any adobe product with proper ID at any of the schools I have attended.

Does that mean all of the copies students use are legit? Of course not. That would be a silly thing to claim. Almost as silly as claiming all students will pirate Photoshop.

Re:64 bit is no panacea

[OS24Ever]

According to this [apple.com], 64-bit cocoa was introduced back in March 2007

You clearly have no clue what Objective-C is

[danaris]

Objective-C is most certainly not a "proprietary language". It is not as popular and widely known as C/C++ or Java, to be sure, but it is, as far as I understand it, completely open.

Cocoa, Apple's Objective-C based API, is, I believe, not completely closed, either, but it's probably what you're actually thinking about. And it's an API, just like the Carbon API, or the Win32 APIs.

Dan Aris

Re:64 bit is no panacea

[PitaBred]

16 bit/channel is 64bit color (16 bits per RGB, and a 16bit alpha channel. Or 16 bits per CMYK if that's the way you swing). Just, you know, so you don't look silly next time you post.

Re:Let the blame game begin!

[Blakey Rat]

I'm not talking about the basics, even GeOS supported those.

I'm talking about things like the integrated spell-checker, Services, drag&drop, AppleScript GUI scripting, etc. X11 on some other platform may have those features, but it definitely doesn't in OS X.

Re:What will happen?

[bhima]

Why would you say Aperture is not based on Cocoa?

As far as I can tell it is, not that I am the Apple developer that maintains it or anything. The plugin SDK is highly suggestive that it is a Cocoa app.

Re:64 bit is no panacea

[MrJerryNormandinSir]

You are running 64bit on the wrong OS!
Linux 64bit apps are very fast and for photo editing I would use the GIMP over Photoshop. there are a lot of plugins for the GIMP too! Also I have a powermac G5 (real mac) running tiger. GIMP is very fast on that too! So I am not missing anything.

Re:64 bit is no panacea

[prockcore]

Or Python or Ruby or Perl or Lisp. Cocoa requires a reasonably dynamic language and C++ doesn't make the cut.

Not true at all. wxWidgets and QT are both able to provide a C++ wrapper for Cocoa. I imagine that QT is exactly what photoshop is going to use. Then they can have the same code base for windows and osx (and linux if it ever comes to that)

Re:64 bit is no panacea

[TravisO]

Wow really, no useful features in Photoshop lately, well let me list the minor ones I know about that have been added since Photoshop 4 which is almost 10yrs ago now.

1. multiple undos
2. the ability to group multiple layers into a "smart object" making it easier to reuse image parts you've created
3. Save for Web ... finally you can customize the exactly details of an image and get realtime feedback how big the image is
4. text stays editable, instead of converted into "carved in stone" pixel data
5. layer effects (enough said)
6. major UI overhaul that's make it easier to use and more organized

and those are just the bits I use. Now how about you shut your whine hole and go innovate something yourself

Re:Let the blame game begin!

[Ilgaz]

They are working on it but nobody reports issues. Telling Slashdot "X11 from Apple sux, it can't use services" is not the way to go. You say "X11.org can't use Services, I have an idea how to implement them". It is not like Cocoa, it is completely open source.

I am not a developer of any kind, I try my best as end user to report issues I spot.

http://trac.macosforge.org/projects/xquartz [macosforge.org] .

It is not a bad X11 (as they moved to x.org) , in fact Apple made possible and lot easier for X11 apps run in average end user desktop by integrating it to launchd subsystem. If you type "xmms" from command line, X11 launches in rootless window and opens xmms. It is that easy. I use Kopete as my instant messenger since I installed Leopard (thanks to finkproject.org ) and various tools like Koffice.

Real issue with X11 apps could be the thing that most of them are coded with Linux in mind. Those Fink and Macports guys spare a lot of time to make them compile in a true Unix/NeXT environment on a OS which even openly warns its own core tools like Finder.app NOT to use depreciated functionality (from system.log). That is how Apple expects people to code on the OS X. They warn politely first, a bit serious later and it basically refuses to launch even with a informative crash.

I blame Apple

[kuwan]

It's uninformed BS like this that makes me sick. Carbon may have initially been a "backwards compatibility" layer in the initial versions of Mac OS X but since that time it has involved into a fully native modern API that is every bit as native as Cocoa is on Mac OS X. Modern Carbon applications work just as well, look just as good and can have just as many features as any Cocoa application.

Also, prior to WWDC 2007 Apple has never said that "You're not supposed to use Carbon anymore!" Apple has been evolving Carbon since Mac OS X has shipped (HIViews, Quartz 2D, HIThemes, HICocoaView, Carbon Events, etc.) and if you had a large, complex application that was already built in Carbon there was no compelling reason to switch to Cocoa, especially since Apple announced and provided a working version of 64-bit Carbon up until WWDC 2007. Yes Cocoa usually gets access to new APIs first, but you can usually access these fairly easy from Carbon if you want to. For new applications Cocoa has been a better choice over Carbon as Cocoa apps are easier to create and maintain. But if you've already got a very large and complex Carbon application (such as Photoshop) then there's never been a compelling reason to rewrite the app in Cocoa since anything you can do in Cocoa you can also do in Carbon (although usually with a bit more work).

It wasn't until WWDC 2007 that Carbon really became a dead API. Prior to WWDC 2007 Carbon had been updated regularly including many sessions on building applications with Carbon at every prior WWDC. And I believe the WWDC 2007 build of Leopard still included a working version of 64-bit Carbon (it was removed in seeds after WWDC). When it was realized that 64-bit Carbon was dead people had to ask (including Apple Engineers) - What is Carbon? Because really there are many parts of Cocoa that are built on top of Carbon. You couldn't just take out all of 64-bit Carbon and still have 64-bit Cocoa work. It was decided that Carbon for 64-bit intents and purposes was anything GUI related (Appearance Manager, HIView, HIToolbar, Menu Manager, etc). There are still a number of Carbon technologies that are available to 64-bit applications - much of Carbon Events, Core Foundation, ColorSync, etc.

There are some Apple applications that are built on Carbon as well - iTunes and Final Cut Pro for example. Final Cut would benefit from a 64-bit Cocoa version, but it's hard to see iTunes ever needing to be 64-bit. It might as well remain a 32-bit Carbon application and no one would ever care.

I think that dropping 64-bit support for Carbon was the good decision in the long run, but Apple really dropped the ball in the way they killed it. They should have done it at WWDC 2006 rather than give developers a year of play time with the soon-to-be-doom 64-bit Carbon. Had they done that Adobe and others could have started work on a 64-bit Cocoa port in 2006 rather than 2007 and there would have been a slim possibility of a 64-bit CS4.

The bottom line is that the blame is largely on Apple for this one. Adobe was using one of the two APIs that Apple has officially supported and continued to improve since Mac OS X shipped. Apple even announced the transition of this API to 64-bit and provided developers with every indication that it would be supported well into the future. Yes, Adobe might have looked at Cocoa and seen its benefits - more modern and easily maintainable with easy access to the latest Mac OS X technologies. But those benefits are lessened when compared to the task of rewriting a very large and complex program such as Photoshop (let alone the rest of the CS apps). Apple should have dropped 64-bit Carbon in 2006 (by never announcing it) to give developers the time to rewrite their applications, rather than drop it just months before they shipped Leopard.

Re:Let the blame game begin!

[anarkhos]

I'm tired of people who don't write Mac programs pontificating on crap they have no clue about.

Carbon and Cocoa aren't in direct competition. Carbon is a lower-level API that works as advertised. Cocoa is a higher-level API like PowerPlant or MacApp that, in spite of Apple's marketing, isn't some kind of all-encompassing masterwork of new technology. In fact, it hasn't changed significantly since the debut of OPENSTEP, and the fact it wasn't written for the same market as the Mac shows.

Cocoa has missing APIs and legacy issues stemming from its UNIX roots (pre-dating the Macintosh, which was written from day 1 as human-centric). Also, unlike PowerPlant, Cocoa is closed source. This means that when you have blocking issues, you can't puncture the damned beach ball unless your radar is miraculously answered several OS revisions from now. This isn't an issue with Carbon. There is a reason why all of Apple's high-end softwares are written in Carbon.

In fact, the only major practical advantage Cocoa has is Interface Builder. Some cool Carbon developers at Apple (aka, those who actually read radars) created the same for Carbon with HIView. One may ask how dare they improve a viable API when lord Steve has already given orders from on high that Cocoa is the New Wayâ. I'll answer because an OS is a tool, and those who find it useful use the tool. When Mac OS ceases to be the best tool for the job, we'll go elsewhere. Removing 64bit Carbon is removing a damned useful tool. Apple would be better off removing a different tool (the breathing kind).

If Apple gets rid of Carbon, they ought to provide a viable replacement or Mac OS X will be relegated to the same rubbish bin you'll now find OPENSTEP.

By the way, you'll find that some of 64bit Carbon still exists, albeit in private frameworks. Expect this list to grow as they publish 64bit Final Cut Pro (aka how to piss Adobe off even more).