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.

Comments

64 bit is no panacea

[jgarra23]

just like the article says, it's not like it's going to make your app run any faster. In fact, with tday's machines, 64 bit will probably run slower than 32 bit...

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

[OS24Ever]

I'm not overly concerned, it's not like I'm editing 64 bit color images, 12 - 16 bit tops (but then, I don't have a Hasselblad)

I'd be more concerned if they said something like it ignores 2 of the 4 cores per processor, or can't due SMT, or something else. 64-bit isn't as sexy/important in this case as far as I understand it.

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.

Re:64 bit is no panacea

[Anonymous Coward]

64 bit will speeds things up, but not by a lot. And then, on windows, you take a hit for running all your 32 bit apps (perhaps 95% of what you run) on WOW64. And also 64 bit apps take ~15% more memory. So far, on the desktop, 64 bit just ain't worth bothering with. Even die-hard windows fanboys like Paul Thurrott admit 64 bit windows is treated as a 2nd class citizen in his own reviews. There's almost no speed advantage, it just brings compatibility issues, and it's much harder to find drivers for some hardware. If CS4 is 64bit, and Vista only, that means our dozen or so photo workstations (running XP) will stay with CS3 for a long time to come.

There's just no way we'll upgrade the hardware, to be able to upgrade the OS and have it run at a decent speed (nevermind support costs), to be able to upgrade to CS4. It would have to have MAJOR time saving/productivity features to be worth spending that much. They must not want our money.

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

Re:64 bit is no panacea

[elrous0]

32 bits is just fine...until the day that Apple announces better 64-bit developer support, at which time it will immediately become the greatest thing since sliced bread.

Re:64 bit is no panacea

[mehemiah]

But the little bit of support they give makes pixelmater for lepord 64 bit by defau_t. I'__ _et a Pixe_mater rep speak for how dificu_t it was. wou_d the editor p_ease rep_ace my underscores with the 17th _etter of the a_phabet.

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:64 bit is no panacea

[joaommp]

And you have to keep in mind that Photoshop isn't the average "Paint" product for the average joe home user, it's a product developed for professionals (and with "professional" prices...). It's intended for those who need it at the point that they can afford it and the requirements for the kind of work they need to do with it. So, yes, going 64 bit is good and important for Photoshop.

Re:64 bit is no panacea

[PopeRatzo]

I was just gonna agree. Photoshop works really nicely in OSX as it is. I understand Adobe's gotta keep adding "features" so they can keep making money, but I don't think Mac users should get too upset that they won't have a 64-bit version for a few months.

Re:64 bit is no panacea

[Anonymous Coward]

Well according to Adobe in TFA

In our testing, when an app isn't using a large data set (one that would otherwise require memory swapping), the speedup due to running in 64-bit mode is around 8-12%.

Maybe I'm wrong but 8%-12% on the same hardware is quite a speed up.

Re:64 bit is no panacea

[Anonymous Coward]

Photoshop can already use more than 3GB:

http://kb.adobe.com/selfservice/viewContent.do?externalId=320005

Re:64 bit is no panacea

[FireXtol]

Insightful?

Re:64 bit is no panacea

[larkost]

Apple has already announced (and shipped with 10.5.0) better 64bit support, but just not for Carbon. And since all of Adobe's products (except Lightroom) are Carbon applications, they have no access to GUI-integrated (single process) 64bit support.

Adobe has been dragging its feet on a port to Cocoa (about which everyone saw the writing on the wall a long time ago), aided by Apple's thinking that it was going to give 64bit Carbon a future (rescinded quite some time ago). I don't know why this is at all surprising to anyone.

Re:64 bit is no panacea

[saigon_from_europe]

Following that logic, that 64-bit machines are necessary in order to get more than 2^32 bytes of memory, one may assume that 8-bit machines were able to address only 256 bytes of memory. IIRC, my C64 had 64k without 16-bit CPU.

Re:64 bit is no panacea

[LO0G]

I was fine with your 1st statement.

But for your 2nd statement (that wow64 slows things down), there is essentially no slowdown for 32bit aps in WOW64 - WOW64 is basically a compatibility layer that allows 32bit applications to access 32bit DLLs (in windows\syswow64) and registry. But applications run at full speed, because the support for 32bit applications on a 64bit OS is built into the processor (otherwise OSX and Linux would have the same issue).

Re:64 bit is no panacea

[Anonymous Coward]

you should inform college graduates then. we hire them all the time, full time, interns you name it. among the list of many skills like, word, excel, powerpoint, googling effectively, etc...photoshop is in there too.

you don't know photoshop, you're not getting hired. period.

we have a bank of macs, and we have several little tests that we've setup.

adobe would LIKE everyone to believe that their application is the EXPENSIVE HEAVY DUTY PAINT APP.

I'd say it's a paint app that remains expensive and hasn't added anything extraordinary to the feature lineup in 10 years.

We chose adobe photoshop in 1993, instead of a used Pixar Image Computer. Back then this stuff was ground breaking. We had a quadra 950 with 64 megs of memory (the memory alone was $5000). The license for photoshop was $500.

18 years later, computing power is cheap.

and Adobe has been playing safety defense for 10 years. The signs are all there. Buying up all sorts of smaller companies or competitors. Innovation is dead. Lot's of top down decisions. Microsoft, Autodesk, and Adobe...are all just the big fat slugs of their domain. They need to be taken out and shot.

Re:64 bit is no panacea

[joaommp]

For what I could understand, it seems to be a workaround like creating some sort of memdisk or memory used by the plugins as being other processes but still not directly mapped to the Photoshop virtual address space itself (the document talks even about more than 4GB like &GB and 8GB, but with 32bit you can only directly address 4GB and of those 4GB depending on the operating system, 1-2GB are reserved for code).

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.

Re:64 bit is no panacea

[BlackSnake112]

If their are slugs, just use salt. It is cheaper, easier, and safer then bullets....

Re:64 bit is no panacea

[baadger]

Whoops...

All x86 software, *including drivers*, should be shipping in both 64bit and 32bit binary form

Re:64 bit is no panacea

[Hal_Porter]

They should be concerned that Adobe got told that the API they relied on won't be ported to 64 bit though. That might affect other third party software vendors.

On Win32 the API doesn't really change when you go to 64 bit. And the LLP model means int and long stay 32 bit, only the pointers change size. So code that reads bitmaps for example won't break. Now you can argue about this, but it means if you've spent ages developing Win32 code it only takes a few days to port a large application to Win64.

Now Windows has ~90% of the market place and Apple has ~6%. If you were Adobe and getting to 64 bit on Apple required a lot more work in return access to far less of the market place, wouldn't you be tempted to tell people to use Bootcamp if they want to use the 64 bit version? Now I know Adobe will do the work at least this time, but don't you think decisions like this may cause other vendors to reconsider keeping their Mac ports going?

I know Adobe had a hard time going from PPC to Intel

http://blogs.adobe.com/scottbyer/2006/03/macintosh_and_t.html

The thing that Apple needs to realise is that independent software vendors are an asset to the platform. If you keep making them to extra unnecessary work - the transition from Metroworks to XCode and from Carbon to Cocoa - to support a minority platform when the majority platform doesn't require this, then they might well just tell people to use Bootcamp. Which they do already for Framemaker.

http://www.macworld.com/article/50465/2006/04/photoshop.html

"However there are some products that we have today that we have not been able to afford to continue to develop to make available on the Mac. A great example being FrameMaker. The majority of FrameMaker users use Windows as an OS but there is a small percentage that want to use FrameMaker on the Mac so they can use Boot Camp."
Adobe CEO Bruce Chizen Actually maybe Bootcamp is too much hassle for most people. But I've seen Parallels desktop, and it's really slick. Sooner or later someone will work out a way to get Windows applications running seamlessly on Intel Mac, if they haven't already.

So the hassle for Mac users running a Windows application is dropping all the time. And that will definitely affect Adobe's decisions whether to spend man power on refactoring every few months to keep tracking Job's whims. But in the long run, if the Mac has no native third party applications, it will go the way of OS/2.

Re:64 bit is no panacea

[afidel]

It's worse than that on Windows, unless you use the /3GB option in boot.ini 2GB is reserved for the kernel.

Re:64 bit is no panacea

[NicknamesAreStupid]

Not true for photo editing, and Adobe is not the first (though they may be the first big shop). I've used photo-stiching Panorama Factory (http://www.panoramafactory.com/, from Smokey City Design) for years, and they addresssed the memory/performance problem by going to the larger memory model. I've stitched together images that became over three gigabytes (uncompressed) that could only be done in a 32-bit address space with a crude swap-file workaround that would have taken 100 times longer than running everything in RAM (i.e., two weeks). The same problem with VR games will become evident as bandwidth increases and rendering improves.

Re:64 bit is no panacea

[Hijacked Public]

I have a Hasselblad (and I scan large format film) and I'm not overly concerned either. I tend to find that the people who think they neee to process loads of images quickly are the biggest Photoshop speed freaks. Some guy who shoots 5000 RAWs at a wedding and wants to set up a print stand at the reception.

Re:64 bit is no panacea

[afidel]

4GB DIMM's are still extremely expensive, I know because we buy them for some servers. Generally it's significantly cheaper to buy two servers full of 2GB DIMM's then it is to fill one server with 4GB DIMM's ($800+ per 4GB stick vs $200 for 2GB). Of course you can buy workstations with 8 slots so that still gets you to 16GB.

Re:64 bit is no panacea

[cnettel]

For image processing, I think the story is generally quite simple. You don't have too complex data structures (i.e. not a lot of overhead due to pointers changing size, this is different from much of general business/application programming), relative to the amount of data being crunched. You do benefit from a clean and huge virtual address space, you do benefit from a larger register file (which you get with x64), you can certainly benefit from 64-bit integer arithmetics in some cases where you might otherwise resort to floating point. Future SIMD extensions tend to be x64 only, or at least do better in that mode.

Photoshop is simply the typical consumer app that can and will benefit, in addition to some games.

Re:64 bit is no panacea

[cnettel]

Yes, but it also meant that address calculations were relatively expensive when you wanted to do free addressing over those 16 bits. A relative offset of less than 256 bytes was cheaper, by far. The data bus was also only 8 bits. The "bitness" of a CPU is no simple issue, the original Pentium could address more than 32 bits, and used a 64-bit data bus, but few people would choose to call it 64-bit. When all general purpose and address registers support a certain width, it makes sense to actually say that it "is" that number of bits.

Re:64 bit is no panacea

[thanatos_x]

It's very likely that your 8-bit processor had a 16 bit address bus, allowing the 64k memory limit, since 256 bytes was very restrictive, even back then.

The other registers were 8 bits, though they could likely be paired for some instructions, for example to add two numbers both over 255, but under 2^16-1 (unsigned)

I'm pretty sure all 32 bit CPUs use a 32 bit address bus, since when 32 bit CPUs were introduced the address space limit was no problem. Moore's law also ensured that we had more than enough transistors to make a true 64bit CPU when the memory limit became an issue (64 bit processors have been widely available since AMD made the transition in 2003)

http://en.wikipedia.org/wiki/8_bit

Re:64 bit is no panacea

[Xocet_00]

You're quite right; the Commodore 64 had an 8-bit processor, but the chip had a 16-bit address bus (link)

The ability to do 64-bit processing is not a prerequisite for accessing large amounts of memory. The Intel Pentium III Xeon chips (32-bit), for example, could address up to 64GB of memory (link, 64GB = 2^36 bytes, so a 36-bit address space).

I believe that the memory controller is that component that determines how much memory can be addressed. There are, so far as I know, three "bit" numbers that are important with processors:

1) The registers; the size of the register determines the size of values that can be processed directly.
2) The addressable space; determined by the memory controller. (IIRC)
3) The data bus width; the number of bits per bus clock that can be moved into or out of the chip.

I'm hardly an expert on this stuff though. Anyone care to give a more detailed description?

Re:64 bit is no panacea

[jimicus]

Following that logic, that 64-bit machines are necessary in order to get more than 2^32 bytes of memory, one may assume that 8-bit machines were able to address only 256 bytes of memory. IIRC, my C64 had 64k without 16-bit CPU. Not always that simple. My BBC had 32K of memory and an 8 bit CPU (a 6502, as it happens, which I think is very similar to the CPU that went into the C64), but I suspect you'll find that the address space and the size of the registers are often two different things. Certainly the 6502 it was based on would have had a 16-bit program counter and virtually everything else 8 bit.

Re:64 bit is no panacea

[kitgerrits]

Not entirely.

Running in 64-bit color on a 64-bit CPU with a 64-bit O/S means that applications (photoshop filters) can address the pixels in images as raw bytes.

Running 64-bit images on a 32-bit O/S on 32-bit hardware means that the software has to refer to the pixels as a different datatype, or manually sew together its hardware-native 32-bit (doubleword)bytes into 64-bit (quadword) image pixels.

Running 32-bit programs on a 64-bit machine means that the hardware has to constantly convert the software's 32-bit bytes and address space into 64-bit bytes and address space. The reason the impact is not that significant, is that AMD does this in very-fast hardware.

MMX was a prime example of allowing 32 or 64-bit operations, without making the CPU break it up into 8-bit bytes, process it and sew it all back together. This allowed for 32 instead 8 bits of color at no extra cost in CPU power.

Re:64 bit is no panacea

[Minimalist360]

Following that logic, that 64-bit machines are necessary in order to get more than 2^32 bytes of memory, one may assume that 8-bit machines were able to address only 256 bytes of memory. IIRC, my C64 had 64k without 16-bit CPU. The 6502 is an 8-bit processor with a 16-bit address bus.

Re:64 bit is no panacea

[Joe Decker]

... Adobe has been playing safety defense for 10 years. That's at least a bit glib, at least with respect to Photoshop and competing products. I find that most of the last few releases of Photoshop have improved enough to make it worth the price of upgrade, moreover, Thomas Knoll's work on ACR and the introduction Lightroom represents a significant rethinking of the photographic workflow. That having been said, the attempts at competition in the broad marketplace have been weak, Adobe does have a pretty entrenched "moat" around PS. I just don't see that translating them getting away with selling inferior products--if there were better products, I'd likely switch--it'd be a lot easier than switching, say, operating systems.

Re:64 bit is no panacea

[Minimalist360]

And before anyone responds that the C64 had a 6510, yes it did, but the 6510 is just a 6502 with some added features. They were both 8-bit processors with a 16-bit address bus.

Re:64 bit is no panacea

[Hal_Porter]

The 6502 in the C64 used a 16 bit address space. Registers where only 8 bit and one register could indeed only access one of 256 addresses. But pointers in code could be 16 bit e.g. store accumulator to address $8000 was like this -

STA $8000 ; I still remember the hex for this $8D $00 $8d

You could use the 8 bit registers as an offset too, e.g

LDA $8000,X ; Load the accumulator from address $8000+X

Finally the first 256 bytes of memory called the zero page could be used to hold 16 bit addresses. So if you had an zero page space you could do

LDA ($40),Y ; load a from the (16 bit address at $40)+Y

Note that since all the registers - A,X,Y (and even the stack pointer!) are 8 bit the offsets from pointers can only be 8 bit. It's a bit like a stripped down version of 8086 in 16 bit mode. There you had a 16 bit offset from a segment. Segments were 16 bit values but they were shifted left 4 bits to give addresses below 1MB. Effectively you have a 1MB address space consisting of arbitrarily aligned 64 segments.

In much the same way, you can think of the 6502 as having a 16 bit (64K) address space and 256 byte segments.

Of course in 6502, if your code runs from Ram, you can write a 16 bit address directly into the instruction. Since 6502s don't do much in the way of caching or prefetching, this is still fast.

Now some 6502 designs used bank switching to get access to more than 64K of memory. Typically they would use a memory mapped IO port to latch the high order address bits. So you'd write the address bits to a port and then some chunk of the 64 address space would be remapped. An example would be to have a 16K window mapped anywhere in 128K of Ram.

Re:64 bit is no panacea

[Hal_Porter]

That's virtual address space, not physical address space.

http://blogs.msdn.com/oldnewthing/archive/2004/08/22/218527.aspx

32 bit non server versions of Windows do have a 4GB physical address space limitation though, so even if your Bios maps Ram hidden by IO devices above 4GB, Windows XP 32 and Vista 32 won't use it. Windows Server will though.

Re:64 bit is no panacea

[anss123]

On the Mac I believe you get the full 4 GB. Windows and Linux have the 3 Gig limit but without backwards compatibility to worry about Apple was able to code around it.

Re:64 bit is no panacea

[magbottle]

remember that 1GB of the 4GB address space is already reserved for system code sharing Not on Mac OS. Apps get the full 4gb. Although, at least on Tiger and before, there's a usability wall at 3.6gb due to required frameworks loaded.

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

[wall0159]

"remember that 1GB of the 4GB address space is already reserved for system code sharing"

It's worth emphasising that this is a limitation of Windows only, and does not apply to other operating systems.
(at least, that's my understanding...)

Re:64 bit is no panacea

[Computershack]

just like the article says, it's not like it's going to make your app run any faster. Tell that to my wifes' boss who runs a sign company and is regularly now dealing with images >4GB and has to sit there whilst the HDD hammers away paging stuff.

Re:64 bit is no panacea

[Kjella]

4GB DIMM's are still extremely expensive, I know because we buy them for some servers. Generally it's significantly cheaper to buy two servers full of 2GB DIMM's then it is to fill one server with 4GB DIMM's ($800+ per 4GB stick vs $200 for 2GB). Don't know WTF you buy memory, but you're either buying something completely different or getting totally ripped off. I can buy a 2x4GB set for 2000NOK = 386$ before VAT here that's in stock right now (only one though) and those that don't have in stock go as low as $230 (1483 less VAT in USD) here with expected stock date in three days.

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

[cHiphead]

Maybe its just me but after Photoshop 6, all they did was add bloat with minimal overall improvement (with a few notable exceptions) as far as a 'light' user is concerned. After PS6, performance went straight to hell and you needed much more computing power for the same simple tasks.

Note: I'm speaking just from the view of a very 'occasional' user, not a professional graphics designer or the like.

Cheers.

Re:64 bit is no panacea

[TheThiefMaster]

On Win32 the API doesn't really change when you go to 64 bit. And the LLP model means int and long stay 32 bit, only the pointers change size. So code that reads bitmaps for example won't break. Now you can argue about this, but it means if you've spent ages developing Win32 code it only takes a few days to port a large application to Win64. Only if it's well written, and written in a language with a 64-bit compiler.
And even for C/C++, some lines that won't work properly or crash when built for 64-bit:
(int)(pSomePointer); // storing a memory address in a stupid type, eg int, instead of storing a memory address in a pointer
(int)(pOther-pSomePointer); // storing an offset from one memory address to another in an int, basically a variant of the above
void** pDoublePointer = malloc(4); // hard-coded memory sizes instead of sizeof()
asm{} // pretty much any assembler code will probably be broken
assert(!(pPointer&0x80000000)); // Code that assumes bit 31 being set means OS-only memory and treats it as an error ... // Using external libraries that don't have a 64-bit version (yet) or have some of the above problems

Some apps may need to be re-written for Win64 if they were written badly enough to begin with.

Re:64 bit is no panacea

[pressman]

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. Whoa! 64Bit color? No one works with 64Bit color! The two color spaces people work with are 8Bit/channel and 16Bit/channel and those pretty much encompass all colors visible to the human eye in RGB.
A 64Bit color image would be HUGE indeed.

Re:64 bit is no panacea

[Swift2001]

Adobe has a huge problem: its past. When the Mac crossed over to OS X, Photoshop had a huge constituency that wasn't going to be happy about running in Classic, and a huge code base that needed some heavy lifting to translate to Cocoa. Apple provided the Carbon template as a temporary transition to OS X. Adobe farted around and took the easy way out. Imagine, they just discovered that there would be no 64-bit Carbon. So they'd actually have to delve into all that spaghetti and rewrite stuff. Apple switches to Intel, and to 64-bit chips. It's seven years into OS X. It's not a fad. Wake up, Adobe!

Re:64 bit is no panacea

[Joe Decker]

Indeed, we're all going to see performance and features of Photoshop through the lens of whatever work we do with it. You'd be surprised how much time a "small" feature like the healing and spot healing brush have saved me, not to mention lots of the improvements to what one can do with layers and smart filters, but ... that's me, that doesn't make my experience any more valid than your own.

Still, I wouldn't entirely judge Adobe's "sitting on it's laurels" based only on Photoshop itself. I think of Lightroom as a reinvention of a lot of what Photoshop that I need to do, plus a lot of stuff that I would have used another application for in the past. It's not "enough" to replace Photoshop at version 1.3.1 for most of my work, but 2.0 (now in Beta) appears to correct the single biggest deficiency (more local adjustments) while holding to a much cleaner (and far less resource-hungry) paradigm for non-destructive editing, many things I'd do in PS with a full (non-adjustment) layer (100+ MB of memory usage) can be accomplished in both an easier to use and less memory-intensive manner. Moreover, Lightroom moves photographic work from a file-based to a database-based storage paradigm, which is quite a leap as well. I suspect even in 2.x most of my images will "see" Photoshop at some point during the process, but I'll be able to ditch a huge amount of the disk and RAM resource bloatage imposed by the layer-based "master file" paradigm. Cheers...

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

[CrackedButter]

When you talk about market share please provide it in its proper context, yes Windows market share is bigger but what is the market share in the creative markets? I think you'll find the %'s are not as skewed so much towards Windows.

Re:64 bit is no panacea

[OS24Ever]

According to this, 64-bit cocoa was introduced back in March 2007

Re:64 bit is no panacea

[Anonymous Coward]

I'll call this your company's fault, what you are saying is quite ridiculous. Its definition of skills is quite lame, looks like they only hire locked-in morons.

Re:64 bit is no panacea

[crusty_yet_benign]

I'd say it's a paint app that remains expensive and hasn't added anything extraordinary to the feature lineup in 10 years.

False. Tens of thousands of people who use Photoshop to make a living every day could point out dozens of ways in which your sweeping generalization is inaccurate.

One example: Ever tried to place a fake sign on the side of a building, in Photoshop 5.0 (ten years ago)? It's hard. Try it in CS3; it's trivial. Another: Healing Brush. I could go on, but I'm no Photoshop guru...

Shot? Someone's a bit grumpy. Innovation at Adobe is far from dead; read some Siggraph papers sometime, and you'll see plenty of "@adobe.com" contact info. Besides, if Adobe was gone, who would we blame for anything Apple does wrong? Oh, right, Microsoft...

Re:64 bit is no panacea

[OS24Ever]

yeah I was being sarcastic, as usual it didn't come across clearly.

I've been deep into 64 bit computing now since the opteron hit the shelves, and nobody - and I mean nobody - generally uses it well for commercial applications. Key word is applications mind you, not servers. In the server space there is lots of good things you can do with the 64-bit capabilities of Opteron or Intel, but on the desktop, heaven forbid if you accidentally get the 64-bit version.

Windows has XP 64 and Vista 64 sure, but they're the redhead bastard stepchilds. Mac OS X tried to do it a little differently, but in Adobe's case they did it to Cocoa but not Carbon. Photoshop is a carbon app, and will require re-write to Cocoa to get 64 bitness. Lightroom is a pure cocoa app as I understand it and will be 64-bit as it comes out.

It's just a timing thing for photoshop. Other than people with too much time on their hands I really doubt a lot of people are going to flip to windows for a single generation of a 64-bit app on the desktop.

Re:64 bit is no panacea

[nahdude812]

Even still very few people work either with large enough images or large enough quantity of images to really make use of 3 gig of ram.

64 bit support will be good for people designing billboards, 300 dpi posters, and for people who have a hundred files open at once, but honestly most users never get Photoshop's memory usage over 500 meg.

Certainly not web designers, and fairly unlikely print designers. Maybe stock photo companies who are going through hundreds of images, but even then they are probably using photo workflow software like Lightroom, and dropping into Photoshop only for periodic edits.

One other demographic I can see using this: photo restoration specialists - people who scan negatives or old photos at 4000 dpi on a drum scanner, then clean it up after. But more people are going to be more enamored by the idea of 64 bit than actually take real advantage of it.

Re:64 bit is no panacea

[Anonymous Coward]

64 bits colors, let's see.

RGBA at 16 bits = 64 BITS

Re:64 bit is no panacea

[prockcore]

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.

Sure you can. Apple refuses to provide C++ bindings for Cocoa. You want to write a cocoa app, you have to use Objective-C.

Basically Apple is asking Adobe to rewrite photoshop from scratch. It will never happen.

Re:64 bit is no panacea

[jcr]

Actually, there is some blame to give to Apple for this, and the mistake they made was in extending Carbon after most of the OS 9 apps had been ported. Carbon had to be done, but HIView was throwing good money after bad. By not saying flat-out, in no uncertain terms, that Carbon was going to be put into maintenance mode back around the 10.2 timeframe, Apple let developers believe that they didn't have get with the program.

-jcr

Re:64 bit is no panacea

[Your.Master]

This is the conventional wisdom, but I've never seen stats to back them up. I'm not saying they don't exist, I just want to see them.

Re:64 bit is no panacea

[joaommp]

both in windows and linux it can be up to 2GB...

Re:64 bit is no panacea

[Anonymous Coward]

32-bit Linux can use up to 64gb of memory. Most distributions (especially server oriented ones) enable PAE. If PAE is not enabled the max is 4gb.

Re:64 bit is no panacea

[godawful]

Well, you're partially correct. Now it's been a few years since I remember seeing anything, but back then i believe sales of photoshop were at 60% windows and 40% Mac.. i'm guessing (i have no evidence, i could be completely wrong, i am pulling this directly out of my speculative ass) that with the growth of the Apple platform, that it may have switched closer to 50/50

This of course isn't that important, so long as apple is making up a big chunk of Adobe's sales, they wouldn't abandon it.

Now, in regards to carbon development and other 3rd party app makers using it. There are 3 major software developers still using carbon..

1. Adobe - They did make lightroom in cocoa, and thats a pretty sweet app, so it gives me a lot of hope for future adobe apps that eventually switch to cocoa.

2. Microsoft - That lumbering behemoth Office is still carbon. I don't know if this really ever needs to be written in cocoa, i mean, an office app certainly doesn't _need_ to be 64 bit. But I would think microsoft somewhere should at least be slowly converting to cocoa.

and perhaps the biggest software developer still using carbon...

3. Apple -Quicktime, iTunes, Final Cut Pro (really needs to be 64 bit).. 'nuff said.. I really wish apple would deploy yellowbox for windows..

anyway, I've strayed.. Adobe wouldn't ask users to use boot camp for PS4, people just wouldn't buy it then..

and besides, isn't it a little late to be predicting doom and gloom for the platform? they seem to be doing well enough

Re:64 bit is no panacea

[Hal_Porter]

Well yeah. But I've built stuff for Win64 and only seen problems with bad pointer casting and not using sizeof. So the others are not exactly common idioms. Plus there were articles on MSDN back when Itanium was being planned explaining how you could build with /Wp64 to find them. I remember reading them almost 10 years ago. And assert(!(pPointer&0x80000000)); was broken even then on a 32 bit x86 OS. If your application was run with the /3GB boot switch and was marked LARGE_ADDRESS_AWARE then then user/kernel virtual address boundary was at 3GB. In typical Microsoft style, applications saw a 2GB virtual address space unless they were marked LARGE_ADDRESS_AWARE. So you could leave code that checked the high bits of pointers and it would still work, or make sure it was gone and set the linker flag and have a 3GB address space if the OS supported it.

Which will no doubt annoy purists, but it allowed some software houses to opt into a larger address space after they audited the code and retested it. Others could be sure that their code wouldn't break.

Some apps may need to be re-written for Win64 if they were written badly enough to begin with. Not at all. In your examples the pointer casting bugs can be fixed with LONG_PTR types. Inline assembler needs a rewrite, but if you're sensible you write in C, profile and then only rewrite a few hotspots in assembler surrounded by #ifdef _M_X86. Most of the time, even this is unnecessary since you can get the performance you need out of C. And if you do write assembler, Win32 has always supported non x86 chips, and it's always handy to be able to build with mingw32, so it was always good practice to make sure you could build a pure C version with minimal effort. If you keep the C version of the hotspot code around, that is always possible.

In general I'd say a few days of hard work will convert a largish and averagely crappy application to Win64. Maybe longer but it's still less work than Adobe needed to port Photoshop from Carbon to Cocoa to get it from 32 bit Mac x86 to 64 bit Mac x64. It looks like they need to rewrite the UI code in Objective C. What's funny is that Apple told them they would port Carbon to 64 bit for years and only recently reneged on that. So it's pretty clear who's to blame for Photoshop being 32 bit only on Macs.

Re:64 bit is no panacea

[daran0815]

I understand Adobe's gotta keep adding "features" so they can keep making money, Well, that may be part of why stopping 64-Carbon may have been a good idea in the long run. In order to go 64-bit, Adobe was investing time into carbon where the more difficult cocoa port would have included 64 bit pretty much for free.

Taken from the Adobe- 64-bit FAQ:
The Photoshop team
began working on porting Photoshop to Cocoa as soon as Apple announced 64-bit support
in Carbon was no longer part of their plans. If this is true, Adobe wasn't even woring on a cocoa port before. I would have expected Adobe to put some more effort into their flagship product in the mac. Their FAQ does sound like they would simply never have made the port unless forced by apple.

but I don't think Mac users should get too upset that they won't have a 64-bit version for a few months. A few months for a cocoa port of that size? Hardly.

Re:64 bit is no panacea

[bnenning]

Apple refuses to provide C++ bindings for Cocoa. You want to write a cocoa app, you have to use Objective-C.

Or Python or Ruby or Perl or Lisp. Cocoa requires a reasonably dynamic language and C++ doesn't make the cut. (Yes, Turing equivalence, but you'd end up essentially recreating the ObjC runtime in C++ which would give you the worst of both worlds).

Basically Apple is asking Adobe to rewrite photoshop from scratch. It will never happen.

They "only" have to rewrite the UI portions, which is certainly a major undertaking but they're going to do it.

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:64 bit is no panacea

[AshtangiMan]

" . . . those students [illegally] obtained photoshop." I call BS. I just got out of grad school and Adobe CS could be had for $299 (the educational version). The computer labs for the department all had CS and then CS2, probably now have CS3. There were students with illegal copies on their laptop, but for the most part everyone had access to perfectly legal versions. I would guess that most schools of art, architecture, and photography would have at least this.

Re:64 bit is no panacea

[babyrat]

($800+ per 4GB stick vs $200 for 2GB)

http://www.ec.kingston.com/ecom/configurator_new/partsinfo.asp?root=us&LinkBack=http://www.kingston.com&ktcpartno=KTD-WS667/8G

two 4GB sticks for a Dell 2950 for $1050...WTF?

Re:64 bit is no panacea

[sexconker]

But most will.
Obviously you haven't been on a college campus in a while.

$300 and a trip to the bookstore or $0 while I eat some nachos and drink beer?

Yeah.

The odds are you hire the smarter, more tech savvy people.
It is these same people that are more inclined to pirate.

Why do internet nerds pretend they are not thieves? It's not a secret.

Re:64 bit is no panacea

[sexconker]

Sure, the labs have them.
And you can buy a version, even for a "reasonable" price. $300 is not reasonable. And before you mention it, $3000 for 3DS Max is less reasonable, but it does not make $300 for (what is essentially) a 10 year old program any more reasonable.

The majority of experience people get with photoshop is through piracy.

Re:64 bit is no panacea

[alta]

Well I was using the assumption that I don't know everything, hard to believe, I know. And seeing that I am not familiar with Hasselblad cameras, I thought there just may have been a few people working out there with 64bit color. Now, I'm a little more confident that there aren't any 64bit monitors, so you'd have to be pretty damn good to manage colors that you can't actually see.

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

[timeOday]

Now Windows has ~90% of the market place and Apple has ~6%. I'd be very surprised if only 6% of photoshop users run Macs!

Re:64 bit is no panacea

[daemonhunter]

Photoshop would seem like bloat-ware to a "light" user, and especially a light user without a powerhouse machine to run it.

(NOTE: I'm not taking a stab at your manhood, simply putting bloat in perspective.)

Adobe introduced other products to their line for "casual" users.

That's what Photoshop Express and Photoshop Elements are all about. Less frills, smaller footprint, smaller pricetag.

D

Re:64 bit is no panacea

[AshtangiMan]

I thought then, and still think that 300 for photoshop, illustrator, go live, in design, and acrobat was a good price. But you are correct about the functionality. I use PS 7 at work and find it to be no different from CS.

Re:64 bit is no panacea

[amRadioHed]

If Apple did that when OS X first came out Photoshop would be in the same exact situation as they are now. The only difference is that by supporting Carbon for ~10 years developers could have been using all that time to work on porting big apps like Photoshop. It's seems like it's entirely Adobe's fault if they didn't take advantage of all that time they were given.

Re:64 bit is no panacea

[daemonhunter]

The majority of experience people get with photoshop is through piracy.

Less rhetoric, more numbers, please.

Show us the data to back that up, or find a new argument.

D

Re:64 bit is no panacea

[alta]

I agree with you on the server/desktop stuff. The only time I've been bitton on a server was when I got a 64bit server, 64bit windows, and then tried to install exchange 2003... Won't install!@#$ And this was before there was a 2007 version. Luckily the license for 2k3 server said you can run 32 or 64bit versions. I was able to find an iso and use my legal key.

As for my desktops, all the workstations we order are 64bit. And we always choose the 32bit OS. We get Vista for the power users that can fix their own crap, and XP for the people the ones that can't. (Can't teach an old dog new tricks)

Re:64 bit is no panacea

[Anonymous Coward]

OS X may have only 6% of the overall market, but its share of the Photoshop user base is a LOT higher. (Not my opinion - I know the number.)

Re:64 bit is no panacea

[afidel]

Ok, it's come down a bit, but the kit for my HP boxes is still $775 per piece. I'd rather not fight with HP over warrant issues so I just use their branded memory.

Re:64 bit is no panacea

[afidel]

Bah, that's slow high latency memory. DDR2-667 CAS 2.5 is significantly more. For a workstation it might not matter, but for an 8 core DB server it does =)

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

[theshibboleth]

I tend to agree. Except for the anti-competitive practice of the big software companies and the high cost of trying to compete with them, I think there would be a big opportunity for a new image manipulation program to become a real challenge, especially on the Mac.

Adobe took about a year longer than it should have to release a universal binary of Photoshop, and now, apparently at an early stage of development, they've already decided they're not going to fully support Mac users. What are they thinking?

Re:64 bit is no panacea

[Anonymous Coward]

While what you state about Apple having a relatively small piece of the overall market compared to Windows is true, that does NOT necessarily hold true for Adobe's customer base. Go to an Adobe user group meeting and look at how many Mac laptops you see relative to Windows machines.

Re:64 bit is no panacea

[mistermiyagi]

"but I don't think Mac users should get too upset that they won't have a 64-bit version for a few months."

While the first part is true ; users shouldn't but will be upset because mac native 64-bit CS will take years not months to rewrite ( Over 1 mil. lines and 6+ years of now outdated code rewritten is not a small task and to date would be the largest scale reworking of an app in apple-land even bigger than the PPC-intel switch)

Apple is more concerned with the sales hit they will take as some ( maybe not an enormous number but enough ) users revert to Windows to do what they perceive they must to stay current.

"Photoshop works really nicely in OSX as it is"

It does until you open a 256MB Tiff and make more the 6 layers each with their own subset of layer/filter/layer-style sets. Sounds like you don't see very many 1GB+ PSDs. Sadly when you work on larger files frequently you see where Adobe cut back.

  Not taking anything away from you but some people would benefit from adobe getting with the times. 64-bit hardware has been around for a while and adobe sat back Milking the old code for all they could get. Carbon was never meant to be a long term thing and adobe figured ( while drinking the apple flavoured kool-aid in so far as 64-bit cocoa ) they could get away with it.

Not after 07 WWDC.

Re:64 bit is no panacea

[mehemiah]

But the little bit of support they give makes pixelmator for leopard 64bit by default or at least with little effort on the developer's part.

Re:64 bit is no panacea

[mistermiyagi]

"...even bigger than the PPC-intel switch"

After some more looking around that might not be right.

Please correct me if I am not.

Re:64 bit is no panacea

[Anonymous Coward]

The two color spaces people work with are 8Bit/channel and 16Bit/channel

Neither of those is a "color space". Please, if you want to sound knowledgeable, check your terminology before you post...

Re:64 bit is no panacea

[pato101]

But, when you address more than 1gb+something of memory at one executable, the access to that memory becomes much more expensive. Whereas, in 64bit you get full speed addressing!

Re:64 bit is no panacea

[adelgado]

2008 - 1993 != 18
2008 - 1993 = 15

Maybe you are using MS Excel?

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:64 bit is no panacea

[ultramk]

If you don't understand the advances over the last ten years that Photoshop has made, you probably aren't the target market for it.

Re:64 bit is no panacea

[jon3k]

"Sooner or later someone will work out a way to get Windows applications running seamlessly on Intel Mac, if they haven't already."

You already can:

http://www.parallels.com/en/products/desktop/features/coherence/
http://www.youtube.com/watch?v=rN9jNNeEd98

Re:64 bit is no panacea

[Kjella]

Agreed, but if I given the budget restriction had the choice between 8GB fast memory + HDD swapping or 16GB slow memory, I'd go with slow memory every time. I guess it depends on what set of data you're working with. I have no idea what an 8-core DB server needs but I'd think another 8GB of table cache should help as well, no? I honestly have no idea, my wristwatch could probably run all my DB needs...

Re:64 bit is no panacea

[Anonymous Coward]

Maybe its been the same for 10 years because it works?

Re:64 bit is no panacea

[sexconker]

Show me the data to refute it, or find me a new strawman.

Re:64 bit is no panacea

[sexconker]

Sure, for all that it's a good price.

But seriously - illustrator? go live? in design?
Yeah, those are all the rage among the interwebs.

Acrobat is useful though (though I hate PDFs). Don't think I'd ever have a need for it through when there are free alternatives about.

I'd pay $80 for PS alone.
No, not starter edition, no, not elements, no not photo album edition.
I had been using Paint Shop Pro for AGES simply because it was cheap, Photoshop had stagnated, and the interface blew chunks. The latest versions of PSP have adopted the crappy photoshop interface, unfortunately.

GIMP is usable, but no where near as versatile as PS.

Re:64 bit is no panacea

[Vitriol Angst]

Your point about Apple being 6% and Windows being most of the rest used to be true. Apple is 10% now, and even bigger in the US.
I would be willing to bet, that of the "workstation class" computers, capable of doing PhotoShop, Apple has a much bigger slice of the pie, vs. say a cash register at Applebee's running Windows.
It's also a marketing fact that Mac users actually make up more than 50% of the people buying Adobe products. Not worth it to update the code? For millions of users when you charge $800 or more for a Suite? How much money does a program need to cost to motivate developers?

I'm in the process of justifying to myself the move from CS2 to CS3. Well I see improvements in After Effects and In Design -- but the improvements in Photoshop? I might see more improvement by spending the money on other plugins. I like the non-destructive filters and effects. But, the most obvious changes are just bug fixes for Leopard.

I have the total CS3 suite on another Mac I use. I'm really not seeing a real world difference in the product. the damn draconian DRM. It is a PIA with updates every week. I login with as a different user, and it tells me I need to re-authenticate. So, for what I do every day, I might be better off with CS2 and a better masking program on the side.

If someone comes along with something that does 90% of PhotoShop, gets rid of the performance bottlenecks and gets the stability of CS1 -- this person who has used PhotoShop since inception will jump ship. Especially if I have to give up a Mac.

>> My own opinion is that this is a shot across the bow of Adobe towards Apple. They want them to stop encroaching on their territory with applications like Aperture. Well, if Microsoft can't stop Apple from developing Quicktime, than I think this is a dumb move by Adobe. They are only going to force Jobs to listen to the developers who would like to take Adobe head on. Remember AVID? I can get a damn fine Avid symphony rig for pretty cheap right now -- and it can do a lot that Final Cut Pro can't. But FCP is about a community and the cost of the solution. Imagine a Mac bundled as an art station. How much would it take, for Apple to shore up the missing parts in Gimp, and give it an interface lift? Safari is a great end for Kerberos, isn't it?

I use both After Effects and Motion by the way. And Motion does not do everything that After Effects does -- but it does do about 80% and does it about 10 times faster.

I don't think it is a smart move for Adobe to use their product to threaten Apple to perhaps make development easier for them or not build a competing product. Adobe SHOULD be improving their product so that nobody could think of using anything else -- you know, the way I USED TO feel about their products 8 years ago. I guess they just want to sit on their rumps and collect money based upon really good DRM.

Re:64 bit is no panacea

[justinchudgar]

Well, speaking as the husband of a print designer, I can concur. She kept up with the upgrade treadmill until CS1. Since then, she has tried the trial versions but has found no compelling reason to upgrade. And, yes, she does do glossy magazine, and sign work.

Re:64 bit is no panacea

[xZgf6xHx2uhoAj9D]

That sounds pretty good. The only division I might make is with addressable memory. The HuC6280 (used in the TurboGrafx 16) had a 64KiB (16-bit) logical address space, but a 2MiB (21-bit) physical address space. This meant it had an 8-bit data bus (and 8-bit registers), a 16-bit logical address bus and a 21-bit physical address bus.

Actually I don't know the specifics, but the Pentium 3's 36-bit physical address space might be a similar situation (since it only has a 32-bit logical address space).

Re:64 bit is no panacea

[mytrip]

Actually, if you have more than 4gb, you can use it with photoshop by using a ram disk application to turn the ram into a drive letter (if you have a LOT of ram) When I was working in the printing business in the early 90's the mac supported ram disks in the operating system. I would make a ram disk and either put the image in the ram disk or set the ram disk as the photoshop primary swap space.

Re:64 bit is no panacea

[defstro]

I'm a graphic designer at Nike, and we have a little over 600 people who are on the creative side (product designers and graphic designers) and I would guess that upwards of 95% of us use Macs. As for running Boot Camp or Parallels desktop to be able to run Photoshop here on the Nike Campus, I feel confident saying it's not ever going to happen. Anyway, that's my two cents.

Re:64 bit is no panacea

[Anonymous Coward]

hasn't added anything extraordinary to the feature lineup in 10 years.

You should really upgrade from your original version of Photoshop to CS3 so you can enjoy the many, many, many great features Adobe has implemented which radically streamline image manipulation processes. Come, join us in the post-Clinton years.

Re:64 bit is no panacea

[ZSO]

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

Wrong. That reflects the overall computer market, not the graphic design market. Mac sales contribute a very significant percentage of total sales for Adobe.

Re:64 bit is no panacea

[LilBlackDemon]

*smack* CMYK support in GIMP has been lacking for quite some time. I work on a weekly paper, and we couldn't function without CMYK support, plus InDesign is far better than Scribus.

Re:64 bit is no panacea

[Lord Flipper]

Maybe its just me but after Photoshop 6, all they did was add bloat with minimal overall improvement (with a few notable exceptions)

I like the version in CS3 a lot. I saw a few things in the "What's new" and some of the demos of what folks were doing with the newer aspects of the app, and had a couple of "Wow" moments.

BUT, I will not argue with you, and, as a matter of fact, I'd go back to Photoshop 5, or 5.5, rather than 6, to say that if someone knows what they're doing with those versions, they can can compete with a huge majority of P-shop users out there.

Re:64 bit is no panacea

[Lord Flipper]

I think of Lightroom as a reinvention of a lot of what Photoshop that I need to do...

My ex-wife was struggling with a demo of Photoshop, and had run into some serious lag and 'early-version' blues with Aperture. I gave her a full version of Lightroom, and racked up a ton of points, let me tell you.

I do work with already-existing images, for the most part, and use Photoshop and PhotoRetouch Pro. But she is a photographer (amongst other things) and absolutely loves Lightroom. I'd recommend it, based on my limited usage, and more on her real usage, to anyone out there who takes pictures and wants to pop them into their file systems with some serious editing on the way in. Really outstanding work on the part of Adobe... almost makes up for GoLive... on second thought, no... no, it doesn't. :)

Re:64 bit is no panacea

[Anonymous Coward]

All the calculations for image processing are done for each channel. So the calculations done for each pixel have at most a 32 bit result, which is not a problem for 32 bit processors. Not silly.

Re:64 bit is no panacea

[Hal_Porter]

Even if it's true it's still stupid for Apple to keep forcing Adobe to do unnecessary work like this.

Re:64 bit is no panacea

[Hewligan]

Now Windows has ~90% of the market place and Apple has ~6%. If you were Adobe and getting to 64 bit on Apple required a lot more work in return access to far less of the market place, wouldn't you be tempted to tell people to use Bootcamp if they want to use the 64 bit version? Now I know Adobe will do the work at least this time, but don't you think decisions like this may cause other vendors to reconsider keeping their Mac ports going?

Those are the numbers for the general computer suing install base. If you're considering the numbers for paying photoshop users, all of a sudden, that Aplle numbert gets much, much higher. Are you sure it's not worth it?

Re:64 bit is no panacea

[macs4all]

Microsoft, Autodesk, and Adobe...are all just the big fat slugs of their domain. They need to be taken out and shot.

Amen, brother!

Re:64 bit is no panacea

[afidel]

We already fill em with 4GB DIMM's, it's just kind of expensive =)

Re:64 bit is no panacea

[jtranber]

"Simple fact is Photoshop is designed for Windows first and then ported." This statement is simply false.

Re:64 bit is no panacea

[AshtangiMan]

I guess it depends, but I use illustrator/photoshop and In Design daily. InDesign is the best layout program I have found, granted amongst a bunch of freeware which is lacking. And for graphic arts illustrator cannot be beat either. Photoshop is actually what I use the least . . . just putting renderings of proposed buildings into site photographs etc. GoLive was also useful, I know there are a bunch of other offerings, but as a student I used it to build a publication for a design contest and got paid $500 . . . so GoLive paid for the entire suite and then some.

Re:64 bit is no panacea

[sexconker]

Yeah, sure, it worked out great for you.
But most people who buy CS3 (or whatever they're calling it now) buy it for photoshop alone.

You had a specific need for the other programs since you were in the industry. Most people only want photoshop, and Adobe knows this.

I'm sure sales of each non-photoshop program would plummet if they weren't bundled the way they were.

Re:64 bit is no panacea

[AshtangiMan]

I find it interesting that throughout this you speak for "most people" without ever qualifying how it is you do so. I speak for myself, and happen to know quite a few people who use the products the same way. I call BS still . . . who are you to speak for "most people"?

Re:64 bit is no panacea

[jwo7777777]

I speak for the trees ... the truffula trees ....

Re:64 bit is no panacea

[sexconker]

Who are you to NOT speak for most people?
Are you that removed from society that you can't even see what the common pleebs are doing?

Surely you've been to the internet, and heard of various things such as piracy and bittorrent and lolcats.

Your post is the equivalent of someone with a gas can in front of a burning house asking the neighbors "what fire?"

Sure, you and your friends may use that gas can as it's intended, but that doesn't change the fact that the neighborhood is awash with arson.

Re:64 bit is no panacea

[cHiphead]

Ouch, my manhood! ;)

But really, the 'casual' user product line is crap, one cand just use paintshop or gimp and get a stronger feature set. The bloatware effect is from gross mismanagement of resources, implementing transparency of the gui and generally using excessive 'frills' on the interface itself that affect the memory and cpu usage. I have certainly run CS2 on a 'powerhouse' machine and it feels extremely sluggish compared to PS6 on an old p2-400/512ram. Its all in the feel, and since I don't rely on many of the 'advanced' features of the later versions of photoshop, I'm less biased towards its feature set and more likely to care about the 'feel' it provides performance wise.

Also keep in mind, I can get down and dirty with PS as needed, but I tend to farm out design work to the more experienced folks that work with it day to day so I can get back to the network admin tasks instead.

Its about the actual feel you get from using it, and the latest versions of photoshop have lost their reliable feel (and really, running it on a quad core intel with loads of ram SHOULD let it 'feel' like a champ that price tag claims it is).

Cheers.

Re:64 bit is no panacea

[AshtangiMan]

Ahhh, you have nothing more than poor wit to stand on. I see. So "most people" are pirating photoshop becuase you've heard of piracy on the internet, peer to peer file sharing, and an unfunny website with cats that have thought bubbles. I consider myself schooled. But if you do come up with a meaningful argument I'm anxious to hear it.

Re:64 bit is no panacea

[sexconker]

Most people who have photoshop have pirated it because of its price. It doesn't take a genius to figure it out.

Re:64 bit is no panacea

[AshtangiMan]

And the only evidence that you have to support it is the assertion that you make. I still call BS, as no one I know who uses photoshop has pirated it. Most people I know don't know what photoshop is. Perhaps you are a student and think that most students have pirated photoshop, I would again disagree, but would agree that most people who have pirated photoshop are students. But of the people who use photoshop, only a small subset are students.

Re:64 bit is no panacea

[sexconker]

You said a lot of things.
I am not a student.
I am not talking about students.

Re:64 bit is no panacea

[AshtangiMan]

I am/was responding to the original assertion by someone else that a company was unethical requiring photoshop skills for new hires, essentially saying that doing so was tantamount to supporting piracy. I called BS. I gave good reasons (every college I have been to to teach/lecture/study has provided photoshop and offered classes). Then you jumped in and said a lot of things, but apparently just wanted to mouth off.

Re:64 bit is no panacea

[sexconker]

No, I never said anything was unethical.
What I said was a joke about his company, specifically, supporting piracy.

It was a comment on the fact that most photoshop installations are pirated, that most flash installations are pirated, etc.

Then people got stupid and defensive.
Some people don't want to admit that pirates have a leg up on the competition. The best way to bolster your resume in any tech field is through experience. When it comes to computers, that means getting your hands on the typical "industry standard" applications. Students get discounts, sure, but free is cheaper, and most people aren't students.

Re:64 bit is no panacea

[van308]

>>>> Actually maybe Bootcamp is too much hassle for most people. But I've seen Parallels desktop, and it's really slick. Sooner or later someone will work out a way to get Windows applications running seamlessly on Intel Mac, if they haven't already. It's called a Wintel-PC :)

Re:64 bit is no panacea

[van308]

>>>>> 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. Why spend on platform that is dying (%5 to 7 users base) just doesn't justify the cost of it. MAC Platform is terminally ill; just doesn't know that yet because of other factor, ie. iFoney so called sales success but yet the iFoney is NOT the best selling mobile device or the best UI either. When it's all said and done; it's all about economic 101... Majority wins!

Re:64 bit is no panacea

[AshtangiMan]

Ok, so most installations of photoshop are pirated. And you know this because you think it's true, but have nothing to back up this assertion. Nicely done.

Re:64 bit is no panacea

[sexconker]

I also know that shit stinks.
I don't have the numbers to back it up, however.

Do you?

Re:64 bit is no panacea

[Anonymous Coward]

Hahahaa. Vista is being replaced in '09 [source Bill Gates]
Vista 64bit edition has even more problems than the 32bit Ed.
Adobe is sawing off their own foot.
I don't care. I can manage just fine with CS3 for at least 10 years.

Re:64 bit is no panacea

[stewbacca]

I'd say it's a paint app that remains expensive and hasn't added anything extraordinary to the feature lineup in 10 years. I'd say somebody isn't tapping into all of the features available in Photoshop. The History palette, for one, was a huge feature, as were many of the improved layer masking improvements. I'm sure that the bevel/dropshadow/etc. layer masks being available from right within the layers palette has been in the past 10 years as well. Text editing has improved too (while far from perfect, much better than it was 10 years ago). And those are only the hobbyist features that I'm aware of...I'm sure there are tons of professional features that have been added in the past 10 years that I'll never use.

Re:64 bit is no panacea

[stewbacca]

I have the exact opposite experience here. Parallels (and probably any brand of VM) is much more complicated to keep configured and running optimally than it it to just reboot and hold down the option key, booting into real Windows.

VM is still too slow for me. I have a 2.4Ghz iMac and 2gb of ram and Parallels suffers from some pretty bad slowdowns. I have VMWare at work on my Dell box (same specs as my iMac) and it's a bit snappier, but still obviously not running things natively.

Adobe Flash on PPC Linux?

[BladeMelbourne]

I guess there's no hope now...

Re:Adobe Flash on PPC Linux?

[gEvil (beta)]

Because Flash and Photoshop are so interrelated?

Re:Adobe Flash on PPC Linux?

[BladeMelbourne]

Hi, you must be "special". If a company makes such a statement (like not supporting CS4 on OS X), it is a good indicator that a Flash plugin for PPC is even more unlikely than before.

Please let me know if you would prefer less syllables, or a clue.

Re:Adobe Flash on PPC Linux?

[MrMacman2u]

Hi, you must be "special". If a company makes such a statement (like not supporting CS4 on OS X), it is a good indicator that a Flash plugin for PPC is even more unlikely than before. Please let me know if you would prefer less syllables, or a clue.

*whistles in disbelief*

No scratch that, it's not disbelief, I should expect it on /.

TFA says that there will be no 64bit version of CS4 for Mac OS X, not that they will not support it.

Someone is special and I don't think it was the poster before you.... Go away now, kthnxbi!

Re:Adobe Flash on PPC Linux?

[Winckle]

The one who needs a clue is you.

They are still supporting cs4 on OS X, they are just taking longer to convert to cocoa from carbon, carbon can't do 64 bit so until cs5, no 64bit on os x. That has absolutely nothing to do with flash player.

Though I do think there is no chance of a PPC linux flash player.

Re:Adobe Flash on PPC Linux?

[mpathetiq]

I'd reckon that not creating software for a specific platform indicates not supporting that platform. How does one support software that doesn't exist?

Re:Adobe Flash on PPC Linux?

[BladeMelbourne]

"TFA says that there will be no 64bit version of CS4 for Mac OS X, not that they will not support it."

Your are super special! Please let me know what you discover about the 11th dimension in M theory.

Re:Adobe Flash on PPC Linux?

[BladeMelbourne]

So you acknowledge that I'm right, and also that I need a clue?

The point that Adobe as a company is slow adapting to new platforms and architectures. For a company of this size, it's pretty shameful...

Re:Adobe Flash on PPC Linux?

[gmack]

The point that Adobe as a company is slow adapting to new platforms and architectures. For a company of this size, it's pretty shameful...

I'm going to go out on a limb and assume your not a programmer. Code takes time to port to new interfaces. That's time that can be spent on other things. It gets even worse when some of the code is hand optimized or worse yet is a GUI app. Photoshop is a very large and very complicated GUI code base and therefore will take a long time to port.

That's life.. it's not Adobe's fault or Apple's. It's just a fact of the industry they life in.

Re:Adobe Flash on PPC Linux?

[neumayr]

Wow, you were still hoping for a PPC Linux flash player?
Adobe/Macromedia ignoring PPC Linux folk for like ten years and Apple eventually going Intel, those things were no reason for you to give up?

In that case, I admire your optimism. You shouldn't give that up just because Adobe is slow supporting a completely different app on new-ish archs.

P.S.: Ugh, what a ghastly looking comment system. When did that happen?

Re:Adobe Flash on PPC Linux?

[Xtravar]

Aw cmon, porting isn't that hard! You just run "replace all" a few thousand times and then fix compile errors until it runs!

Then you hand it to your QAers. "Good luck, fuckers!"

Re:Adobe Flash on PPC Linux?

[MrMacman2u]

*sigh and eye roll*

I will explain this very slowly and very carefully to you and "bright boy" who responded before you.

Mac OS X Leopard runs 32 bit AND 64 bit applications at once.

There will be a 32 bit version of CS4 for Mac OS X.

That means the ONE version that needs to be created for the Mac OS X platform WILL NOT be 64 bit native.

That is, you DO NOT need two write two separate applications to offer 64 bit AND 32 applications on a Mac OS X based machine. Only ONE.

In the case of CS4, the application will only run in 32 bit mode instead of being ABLE to run in 64 bit.

There IS NO separate 32 bit and 64 bit "platform" form Mac OS X.

In contrast, WINDOWS requires TWO versions of CS4 to be made, one to be compatible with the 32 bit platform and one to be fully compatible with the 64 bit platform.

There... I THINK I managed to break that down enough for you two geniuses.

Now I'll be accused of leaving out information or having slightly inaccurate details due to my attempt at simplification....

Re:Adobe Flash on PPC Linux?

[shutdown -p now]

In contrast, WINDOWS requires TWO versions of CS4 to be made, one to be compatible with the 32 bit platform and one to be fully compatible with the 64 bit platform.

This is incorrect. Just like any other x64 platform out there, Win64 fully supports running 32-bit applications. It works precisely the same way as in Linux or Mac.

But of course, your argument is rather pointless in general. The point of having a 64-bit version is to be able to use more than 2Gb of RAM per process (which is something that's actually particularly useful for image processing). If CS4 will have a native 64-bit version for Windows but not for Mac, it means that it will run slower on high-end Mac machines compared to equivalent high-end Windows machines, because it won't be able to use all the RAM on Mac. And that sucks, for Mac.

Re:Adobe Flash on PPC Linux?

[jchernia]

That's the funniest thing I've read on Slashdot in a long time.

Re:Adobe Flash on PPC Linux?

[Anonymous Coward]

That is, you DO NOT need two write two separate applications to offer 64 bit AND 32 applications on a Mac OS X based machine. Only ONE.

This is only partially true. There are probably many areas of the Photoshop code base that would need little to no changes to be compiled as 64-bit applications, but the UI is not one of those sections.

The UI for Photoshop uses Carbon, not Cocoa. Apple has said that there will not be a 64-bit version of the Carbon framework, so any Carbon-based application will be limited to running as a 32-bit application. When Apple announced this, many people openly wondered what Adobe would do since so many of their apps would have to undergo extensive conversions to Cocoa. This announcement is the answer to the question about what Adobe is going to do...they're not going to convert to Cocoa.

Now the ball is in Apple's court. They now have to decide whether Photoshop and the rest of the Adobe products are worth the effort necessary to create a 64-bit version of Carbon.

I vote Apple

[MMC Monster]

Apparently Apple suddenly mentioned that carbon would not be supported in 64bit, meaning that a lot of code will have to be ported to cocoa.

Re:I vote Apple

[gEvil (beta)]

Didn't Apple say nearly 10 years ago that Carbon was a stopgap solution and that you shouldn't particularly rely on it anyways?

Re:I vote Apple

[falcon5768]

Wasnt sudden at all, the writing was on the wall when Apple released OS X. Carbon was supposed to be a quick way to transition your OS9 programs to OSX. That was it. Adobe had no issues writing new programs in Cocoa (Lightroom) but continued to drag its feet on a port for the 64bit version of its landmark products, content to add GUI bullshit that many are not even sure was a improvement.

This was as sudden as Apple dropping OS9 development. It was coming and coming for years, but developers are more content to repackage old code, than to rewrite it. This is the same mentality thats screwing Vista development too. Developers are just plain LAZY.

Re:I vote Apple

[Anonymous Coward]

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

Re:I vote Apple

[Anonymous Coward]

We don't like being called lazy. We prefer developmentally challenged.

Re:I vote Apple

[DrXym]

It's not much of a stopgap if you many millions of lines of code written against it. Which I expect Adobe have.

Re:I vote Apple

[Anonymous Coward]

"Developers are just plain LAZY"

  Uhmm.. developers don't call the shots. Management does, and it is influenced to a large extent by the fiscal responsibility of the company in question (they do what makes money today and in the near future).

Re:I vote Apple

[cowscows]

Yeah, but even Apple still writes some stuff in Carbon, and up to the point where they suddenly changed their mind, they had been telling everyone that 64-bit carbon was coming.

Nobody's really saying that Apple sucks for moving away from Carbon, the argument is that they should've communicated the timeline better to developers.

Not that I think giant developers neccessarily deserve special treatment, but you'd think it prudent to at least not waste a ton of time for a developer of one of the most significant programs available for your OS.

Re:I vote Apple

[MyDixieWrecked]

Please keep in mind that the cocoa framework has changed significantly in every release of OSX since the beginning. It wasn't until the last couple of years that it started stabilizing and applications remained compatible with new releases of the OS.

They're still adding new features and improving the way things work internally, and applications, although they run, have some weird glitches with new OS features; namely, older applications sometimes behave strangely when one uses Spaces.

I agree, adobe should have seen the writing on the wall, but they were kinda like a dear in headlights, not knowing what the fuck to do and just watching the semi barreling down on them.

At least they decided to go to cocoa. At least they didn't drop 64-bit support for OSX or worse yet, drop the creative suite altogether.

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:I vote Apple

[mini me]

Developers are just plain LAZY

Of course. That's why were are developers. When job X needs to be done, the average person will just jump in and get it done. Where as we developers, being lazy, would rather tell the computer to do the job instead. Had we not been lazy, we would have just done the job manually like the average person, and the software would have never been written.

Re:I vote Apple

[poot_rootbeer]

developers are more content to repackage old code, than to rewrite it. This is the same mentality thats screwing Vista development too. Developers are just plain LAZY.

Laziness is a virtue to developers, and it rightly should be. Why rewrite something that works as -is?

And it's not like Adobe's developers had a year to spend Cocoafying the Photoshop codebase, anyway. "All the same features, different windowing API" is not exactly a selling point that customers would be willing to pay upgrade prices for, therefore management isn't going to make it a priority.

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

Re:I vote Apple

[p0tat03]

Look up the WWDC presentation on YouTube. Steve Jobs *clearly* says that Carbon would be a transitional API to Cocoa. Honestly, supporting it for 7+ years is enough I think.

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:I vote Apple

[mzs]

Well in WWDC 2006 they had sessions about how to port your apps for 64-bit Carbon. I decided to go with it for a new mac project at that time. The reason was simple, at the time it was a linux/windows app that was written in mostly C++ and I did not want to bother with a bunch of obj-C glue code. I simply could put the Carbon calls into the C++ classes. I'm still okay, 32-bit carbon is still around, but yeah now I have been working on those icky little .m files.

Re:I vote Apple

[crusty_yet_benign]

developers are more content to repackage old code, than to rewrite it. I think "employed-ness" has more to do with it than "contented-ness". If code works, and you have other priorities (features/bug fixes), you'd be double-plus INSANE to waste engineering time on it. While that may not apply to folks with .org and .edu addresses, it's definitely a fact of life in profe$$ional $oftware development.

Adobe had no issues writing new programs in Cocoa And how, praytell, would you know that? Maybe gleaned from the same Apple Developer Marketing puffery that assured developers compiling OS X apps for Intel was as simple as checking a checkbox, and hitting build?

Re:I vote Apple

[Anonymous Coward]

You can't possible blame developers for this. Developers do not get to choose what goes in a software release, ultimately the board does and quite rightly so.

Re:I vote Apple

[nbert]

Yeah, but even Apple still writes some stuff in Carbon

Yes, there are some unimportant apps still using Carbon. iTunes comes to mind ;)

Personally I don't care that much about 64-Bit. I would prefer efforts to reduce the startup times of the apps coming with the CS package. It's not as bad as Office 2008 (which sometimes takes more time to load on Intel than its ppc predecessor), but I expected more from native apps.

Re:I vote Apple

[morgan_greywolf]

Vista 64 bit is 64 bit down to the kernel. Uh, no it's not. There are still large chunks of 32-bit code in Vista. Granted, much of it is for legacy support, but still, Vista is not completely 64-bit.

Now, 64-bit Ubuntu, OTOH, is completely 64-bit if you don't install any 32-bit libs or applications.

Re:I vote Apple

[catwh0re]

I second this argument. Particularly when Adobe is pretty notorious for blame-storming their lack-luster efforts in overhauling the photoshop code. The fact is that their painting program has been getting slower with each revision and it's most basic functions, which perform little more than they did 4 versions ago, are becoming defunct.

Photoshop is spaghetti code at it's worst and it's one of the main reasons why the heuristics of the interface works so well, but simultaneously why their code has been getting heavier with little functionality improvements.

Photoshop is not modular at all, it still even loads all your plugins at bootup for example. Sheesh Discreet Maya has been owned by 3 companies in the last few years and it has not only progressed in greater bounds, but it's price has remained constant and it loads faster than photoshop.

Re:I vote Apple

[bvankuik]

In my experience, developers are not lazy, and verynkeen to use a new technology. Management decides that there's no time for that, given the release schedule that the market demands.

Re:I vote Apple

[Anonymous Coward]

Um hi continue reading the comment. Adobe has a bunch of NEW programs written in Cocoa (like lightroom), but refuses to translate old ones.

Re:I vote Apple

[nine-times]

They're still adding new features and improving the way things work internally, and applications, although they run, have some weird glitches with new OS features; namely, older applications sometimes behave strangely when one uses Spaces.

You say that as though it's not par for the course for application development. New versions of the OS come out, and sometimes the APIs grow and change. Lots of programs over the years have only worked on specific versions of Windows, and lots of Java apps have required specific versions of the JRE.

I don't see the problem here. I'd prefer the OS developers to continue to fix bugs, clean up APIs, and add features. The main question I would have is, how hard is it to fix your app if an OS upgrade breaks it? For example, let's say you build your app using Cocoa and then Apple releases "Spaces" and your application now has a glitch when using spaces on Leopard. Now as the developer, how hard is it for you to update your program to fix the glitch? If it's easy, then I'd say Apple is handling things well.

Re:I vote Apple

[seandiggity]

...now imagine there were an alternate way to develop software, where people with opinions like yours could influence the development process more directly, who were also encouraged to contribute directly. And if you didn't like the direction a project was going, you could fork it and go in your own direction (dumping Carbon, getting rid of "GUI bullshit", whatever). I wonder what they would call that.

Don't attribute these problems to laziness. There is a power dynamic at work here, one inherent to proprietary software.

Re:I vote Apple

[Anonymous Coward]

No, your recollection is wrong. Apple has always bet its future APIs on the Yellow Box. In order to smooth the transition from Mac OS 9 to Mac OS X, they would include the Blue Box emulation mode. Pressures from big name developers like MS and Adobe, and from the custumers on Apple that was struggling to make a turn around at that time caused Apple to change strategy.

Blue Box emulation mode became Classic and no longer did it run in its own window. It ran apps side by side with OS X's native apps, though with different GUIs. Classic was finally laid to rest with Leopard adn the switch to Intel chip.

Yellow Box became Cocoa. All apps should transition to Cocoa.

To appease big name devs and give them time, Apple introduced a third path: Carbon - a cleaned up old Mac APIs that could take advantage of modern OS fatures. However, this is a dead end. Apple suggested that all apps transition to Cocoa in like 2 years.

Carbon was a big success, but it came with a price: lazy devs choosing to use a dead end API even for their next-version apps and it forced Apple to extend the transition time. When Apple introduced Xcode, Apple again made it clear that their development environment would keep evolving and any developers using Xcode would have an easier time to follow the changes. This was proven later by the switch to Intel chips. Adobe, however, chose to ignore all the warning signs. Think about it: why should Apple promise co-equal and feature-comparable APIs indefinitely on a dead end APIs? The quicker devs abandon Carbon and the sooner Apple can phase out Carbon, the better it is for everyone. Devs will have an easier time to keep up with the changing time and Apple can put a singular focus, time and energy on one set of APIs.

Apple is not free from blame, though. They should never have promised Carbon 64.

Re:I vote Apple

[2short]

As a developer who works in a small enough shop that I do get a voice in calling the shots, I strongly advise anyone involved in any sort of decision making around development:

Be as lazy as you possibly can. Laziness is the greatest virtue developers can aspire to. If there are two ways to get the job done, the one that requires less effort by developers is almost always better. Developing software is fraught with uncertainty and peril. You're obviously going to have to do it some, since you're, you know, a software developer; but you should still avoid it whenever possible.

I don't pretend to declare exactly how this applies to the situation at hand. Apple seems to have said everyone must convert to a new API; but not until now has anything forced the issue. They should not be surprised that Adobe has put off the extra development work as long as they possibly could. If Adobe has had years to make this transition, then they have arguably made the right decision by not doing so yet. All manner of things could have happened in those years; Apple could have died, or blinked first and done the work to support their old API. The latter would seem to be less development work for the world as a whole, so maybe better in some sense, if not for Apple.

Re:I vote Apple

[Anonymous Coward]

Some parts are:

$ file /Developer/Applications/Xcode.app/Contents/MacOS/Xcode
/Developer/Applications/Xcode.app/Contents/MacOS/Xcode: Mach-O universal binary with 4 architectures
/Developer/Applications/Xcode.app/Contents/MacOS/Xcode (for architecture ppc7400):    Mach-O executable ppc
/Developer/Applications/Xcode.app/Contents/MacOS/Xcode (for architecture ppc64):    Mach-O 64-bit executable ppc64
/Developer/Applications/Xcode.app/Contents/MacOS/Xcode (for architecture i386):    Mach-O executable i386
/Developer/Applications/Xcode.app/Contents/MacOS/Xcode (for architecture x86_64):    Mach-O 64-bit executable x86_64</pre>

but almost no apps are:

$ file /Applications/iTunes.app/Contents/MacOS/iTunes
/Applications/iTunes.app/Contents/MacOS/iTunes: Mach-O universal binary with 2 architectures
/Applications/iTunes.app/Contents/MacOS/iTunes (for architecture ppc):    Mach-O executable ppc
/Applications/iTunes.app/Contents/MacOS/iTunes (for architecture i386):    Mach-O executable i386
$ file /Applications/*.app/Contents/MacOS/*|grep 64
/Applications/Chess.app/Contents/MacOS/Chess (for architecture ppc64):    Mach-O 64-bit executable ppc64
/Applications/Chess.app/Contents/MacOS/Chess (for architecture x86_64):    Mach-O 64-bit executable x86_64

and most libraries are, but not all:

$ file /System/Library/Frameworks/*.framework/*|grep "4 architectures"|wc -l
      69
$ file /System/Library/Frameworks/*.framework/*|grep "2 architectures"|wc -l
      13

For example, QuickTime.Framework (for some reason) is 32-bit-only.

My Linux box, in comparison, seems to have only one 32-bit program, and it's part of GRUB.  I doubt this has any noticeable impact on performance, but if my Mac is "fully 64-bit", then my Linux box is "super fully 64-bit"!

Re:I vote Apple

[daran0815]

I simply could put the Carbon calls into the C++ classes. I'm still okay, 32-bit carbon is still around, but yeah now I have been working on those icky little .m files. I hope you know that in .mm files you can mix C++ with cocoa?

Re:I vote Apple

[Guy Harris]

Some parts are:

...

but almost no apps are:

...

and most libraries are, but not all:

Another part that's not 64-bit is usually called "the kernel":

$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.5.2
BuildVersion: 9C31
$ file /mach_kernel
/mach_kernel: Mach-O universal binary with 2 architectures
/mach_kernel (for architecture i386): Mach-O executable i386
/mach_kernel (for architecture ppc): Mach-O executable ppc

Re:I vote Apple

[recoiledsnake]

You're wrong as of 10.5 Leopard. It's 64-bit completely through. The 64bit RDF converts a 32bit kernel to 64bit in your minds as you run it?

Re:I vote Apple

[recoiledsnake]

You're thinking of Tiger, I think. Leopard is fully 64-bit. http://www.apple.com/macosx/technology/64bit.html You expect Apple to reveal on their website that the kernel runs in 32bit? Can you give a more credible link showing that the kernel is 64bit and the OS is fully 64bit? The ability of fanboys and moderators to change reality on Slashdot is amazing.

Re:I vote Apple

[dotancohen]

Didn't Apple say nearly 10 years ago that Carbon was a stopgap solution and that you shouldn't particularly rely on it anyways? If that is so, then why isn't Photoshop (and other apps) not written in Qt? Qt is native to Mac, native to Windows, and native to Linux as well. Skype, Google Earth, Opera, and lots of other cross-platform, proprietary software is written in Qt.

This isn't a rhetorical question. I'm ME, not CS, so I'm really interested in knowing the reasoning. I'm sure there's a good reason, what is it?

Re:I vote Apple

[pato101]

Now, 64-bit Ubuntu, OTOH, is completely 64-bit if you don't install any 32-bit libs or applications. And, if you install the 32-bit libs you can run 32-bit software as well which can be handy specially for custom binaries around (old games such quake, ...). Older version of Ubuntu (Hardy if I recall correctly) were 64bit unless for OpenOffice which had not yet jumped to the 64bit wagon.
I'm a 64bit Ubuntu user for last two years and a half, and time ago it was trickier to use a 64bit OS, but nowadays is pretty the same to install a 32bit or a 64bit version. And with a 64bit version you can address more RAM, so IMHO it does not make sense to use a 32bit version unless your hardware is too old or you are in a certain production environment.

Re:I vote Apple

[default luser]

It's not much of a stopgap if you many millions of lines of code written against it. Which I expect Adobe have.

Yup. Apple, welcome to Windows's world. Microsoft didn't create and make 32-bit Vista the primary OS just because they were sadistic; they did it because vendors would have a hissy-fit if certain 16 and 32-bit legacies weren't supported.

You can't hope to compete with Windows if you don't offer the same legacy support. Apple has a habit of uprooting and tossing processors and operating systems whenerver they feel like it, and compatibility support is usually very limited. I think, in this case, Adobe is being a lazy, fat beast, but at the same time, Apple is being a pretentious prick that doesn't want to meet in the middle with the needs of developers.

Both companies are acting like children, and in the end, only the consumers will be hurt. Apple will save the money it would have cost to port Carbon to 64-bit, and Adobe will probably get some of their Mac users to convert to Windows just to get more memory support (more software sales). This leaves the Photoshop users willing to stay on OS X stuck with a castrated version (but they will buy it anyway), all because each company was busy being a hardass.

Re:I vote Apple

[IntlHarvester]

Well, it doesn't really matter because it supports 64-bit applications and 64-bit drivers.

I guess you lose a little performance to thunking, but IMO Apple's 64-bit approach is a more elegant than MS forcing you to install a different OS.

Re:I vote Apple

[jcupitt65]

I was wrong, apologies. Mod down (if anyone is reading this).

Re:I vote Apple

[LionMage]

Look up the WWDC presentation on YouTube. Steve Jobs *clearly* says that Carbon would be a transitional API to Cocoa.

Well, Steve said many things, and other people at Apple said many things, regarding Cocoa and Carbon. Depending on who they were talking to, the story might change. For political reasons, Carbon was often touted (though maybe not by Steve) as being "co-equal" with Cocoa -- so much so that the Finder for OS X was written in Carbon, not Cocoa, to reassure some 3rd party software developers that Apple was serious about supporting Carbon.

As we all remember, the Finder in 10.0 and 10.1 was kind of painful. It wasn't until 10.2 that the Finder became multi-threaded, and even then, there were still deficiencies. Since Leopard is now "fully" 64-bit, you'd expect Finder to be migrated to Cocoa, but I can't find anything to confirm that by doing some quick Google searches. (Maybe just not the right search terms?)

Re:I vote Apple

[mzs]

No I did not, my jaw just dropped, how could I have missed this!? man gcc explains a lot. Do you know when Apple added Objective-C++? Thanks

Re:I vote Apple

[LionMage]

What you're recalling is political spin that was promulgated by some engineers, both inside and outside of Apple, to allay fears of Carbon developers. Apple needed everyone they could get writing code for OS X in the early days, so they couldn't afford to be seen as obsoleting the investment many Mac developers had made in learning the Classic Mac APIs (which grew into Carbon). This is the same reason that Finder was written using Carbon instead of Cocoa (and, some would argue, why Finder sucked so badly in the early days of OS X, and why it still has so many warts).

Hell, when it was announced that the control strip would be replaced by the Dock, I got into an argument with some Mac software developer who decided to write a look-alike, work-alike replacement for the control strip using, you guessed it, Carbon! When I asked him why, he trotted out the same line that you recalled: Carbon is going to be co-equal with Cocoa; Carbon APIs are even being called behind the scenes by some Cocoa APIs; there are some things you can't yet do in Cocoa that you'll be able to do immediately in Carbon; and besides, why would Apple write the Finder for OS X in Carbon if they weren't serious about supporting it?

Here it is, 2007, and it looks like I got the last laugh in that argument... and the control strip this guy was working on has probably been shelved, since I never saw the final version (though he let me play with an early, mostly-functioning alpha). The Docklets concept was quietly dropped in favor of menu bar extras, and the Dock plus the menulets/status items worked out to be a pretty decent replacement for the control strip. (And incidentally, you use Cocoa to develop menu bar extras -- Apple provides a NSStatusItem class, as well as a NSMenuExtra class for their own private use.)

Re:I vote Apple

[daran0815]

AFAIR its been around for since before Xcode being called Xcode.

Comes at a price, though. mm files compile a lot slower then either cpp, c or m. They also tend to crash the compiler in certain situations (seems like the error reporting for mm files is semi broken at least for template related errors).

Still, easily good enough for writing gui adapters with simultaneous access to cocoa and the main c++ app.

Re:I vote Apple

[Scudsucker]

No dice. How does a promise made in 2006 and broken in 2007 explain the previous 9 years of footdragging, from 1997-2006? Sure, you can blame Apple for changing their announced development path, but that doesn't excuse Adobe dragging their feet on moving to Cocoa.

Re:I vote Apple

[crusty_yet_benign]

How does a promise made in 2006 and broken in 2007 explain the previous 9 years of footdragging, from 1997-2006? Footdragging? No. Adobe had no need to go down a 'rewrite-for-no-goddamn-reason' path, and received assurance from Apple that they wouldn't have to.

Re:I vote Apple

[Scudsucker]

but at the same time, Apple is being a pretentious prick that doesn't want to meet in the middle with the needs of developers.

Because a decade of transition time isn't good enough for you? Somebody may be being a pretentious prick here, but it sure isn't Apple. Thanks, but I'll take Apple's OS release schedule - major update every 2-3 years, actually useful new features - over Microsoft's glacial pace and bloat, thankyouverymuch.

Re:I vote Apple

[Scudsucker]

Wow, are you also pissed at Apple for not maintaining the same level of support for Pascal that they did in 1985? The writing has been on the wall for over ten years now that Classic API's were obsolete and Cocoa was the future and Carbon was a transition. 10 years, as another poster said, is a geological epoch in computer terms. If that's not enough time for you, you're in the wroooooooong industry.

You want über backwards compatibility, you can take Microsoft's 5-7 year release schedule and 10 frikkin gigabyte installs.

Re:I vote Apple

[stewbacca]

I work at a software company and if our developers spent half as much time coding as they did making excuses, they'd be twice as productive.

Seriously, when something pops up that doesn't work right, doesn't work well, or doesn't work elegantly, I get every excuse in the book: "functions as designed", "not a requirement", "don't have enough time", "costs too much". How about just shutting the hell up and fixing it? We all have jobs we have to do, but only the developers seem to be the ones trying to get out of doing their jobs.

blame Apple and/or Adobe?

[G3ckoG33k]

Sorry, but I will blame Microsoft.

It may be a knee-jerk reaction, but still. ;)

Re:blame Apple and/or Adobe?

[elrous0]

Don't worry, this is /. We could find a way to blame MS for the Dafur genocide.

Re:blame Apple and/or Adobe?

[kaizokuace]

Don't let the republicans know the secret political weapon that is /.

Re:blame Apple and/or Adobe?

[Ilgaz]

If we speak about Carbon, MS could be one of large companies to blame. Apple got sick of companies like Microsoft still pushing Carbon apps to users completely ignoring Cocoa and they have taken some measures against them on Leopard.

In fact, Microsoft got a surprise when XCode 3 refused to compile (and ship?) MS Office without them fixing the issues at their code first.
http://blogs.msdn.com/macmojo/archive/2007/10/29/there-s-a-new-cat-in-town.aspx
"When I led our transition from CodeWarrior to Xcode back in late 2005, I noted just how picky the tools were. I'm pleased to note that the gcc toolset is even pickier now, and has helped us find and fix a few bugs that Xcode 2.4 missed."

translation: It refused to compile :)

Apple's philosophy is really different from MS. They say "We are moving fast, if you keep up with us, that is fine. If you don't? Your app icon will bounce and it won't launch".

Adobe Photoshop could be huge, really huge but there is another huge thing which will ship 64bit Leopard version completely moving to Cocoa. Trolltech Qt 4. They had same issue, they heard the Carbon 64bit issue from WWDC. They didn't use it as excuse (like Adobe) and I am sure they are working on 64bit Qt 4 right now. Add Microsoft too. Seriously, a XCode 3 compiling, Cocoa Microsoft Office 08 is a huge thing. Besides jokes, we should congratulate them for not using it as excuse.

You must be new here!

[CaymanIslandCarpedie]

blame Apple and/or Adobe as you will

You must be new here, I don't even need to read the article to know MS and thier monoply is to blame for this :-)

Blame Apple?

[DragonHawk]

Blame Apple? I didn't think we could do that, here.

Re:Blame Apple?

[elrous0]

In the comic book world:

Superman is stronger than Hulk, who is stronger than Spiderman, who is stronger than Batman

In the /. world:

Linux is stronger than OSX, which is stronger than BeOS, which is stronger than Windows

Re:Blame Apple?

[mgblst]

Blame Apple? I didn't think we could do that, here. Ha,ha,ha that is hilarious. Please, keep it coming...

Why? Because once you said something against apple and somebody disagree with you? Get of your bloody high horse. Their are plenty of apple lovers and haters, but most people don't really care about anything except for Apple and Linux.

Re:Blame Apple?

[neumayr]

Superman is stronger than Hulk, who is stronger than Spiderman, who is stronger than Batman What the..? You got that pretty much exactly backwards!
And OSX, or anything, stronger than BeOS? What were you thinking?

Re:Blame Apple?

[elrous0]

I'm pretty sure that Superman could kick Batman's emo ass--on a bad day, using only one finger, while drinking a shot of Kryptonite whiskey.

Re:Blame Apple?

[kaizokuace]

Yes, Windows is Superman. He has the publicity and DRM. Linux has to be Batman because he has all those wonderful toys and he does end up kicking Superman's face in when it came to a confrontation.

The blame falls solely on Apple

[antifoidulus]

they promised, and then rescinded, 64 bit Carbon, and didn't even bother to tell developers until WWDC 2007. This is the big problem with Apple's secrecy, sometimes they are secret just to be secret. There was NO reason not to let developers know there would be no 64 bit carbon as soon as the decision was made, but Apple waited until the last possible second for who knows why.

Yeah, Carbon is dead and they should be going to all Cocoa, but that takes time, and if it was your intention to kill Carbon, why even promise a 64 bit version at all? Why not state from the getgo that you plan to phase out Carbon and that if you want a 64 bit GUI you better be making it in Cocoa? Apple goes out of their way to piss people off sometimes I swear.

Re:The blame falls solely on Apple

[zootm]

Yes, it's Apple's fault, and the blame should lie pretty much just with them. From what I can tell of the situation, though, I don't think they made the wrong decision - I think they just administered the right decision very poorly. They made the decision fairly late in the day, and without prior notification this will push back the schedules of many projects.

The article pushes this very even-handedly, and I do think that Apple's decision will pay off in the longer term. They just could have handled the short term a little better.

Re:The blame falls solely on Apple

[elrous0]

I don't think they made the wrong decision

32 bits should be enough for anybody.

Re:The blame falls solely on Apple

[zootm]

I think that the fact that we've been stuck with as many as that has been a testament to the waste in our industry. Clearly the only true solution is 4 bits, where the fourth can be a rudimentary checksum for data integrity.

Re:The blame falls solely on Apple

[LWATCDR]

"Yeah, Carbon is dead and they should be going to all Cocoa, but that takes time, and if it was your intention to kill Carbon, why even promise a 64 bit version at all?"
Actually killing carbon is DUMB. To use Cocoa you have to use Objective-C for the GUI. There is a lot more experienced c++ developers than Objective-C developers. Objective-C isn't widely used on Windows or Unix so cross platform is now going to be a bigger pain for developers.
This is going to be a great thing for TrollTech.
The end result will be a lot of 32 bit apps will stay 32 bit apps.

Re:The blame falls solely on Apple

[Henriok]

Apple have never promised 64-bit Carbon. Everything that's in developer seeds are subject to change. As far as I can tell Apple didn't make the decision to drop 64-bit Carbon until about same time as WWDC'07, so Adobe and everyone else, including many developers inside Apple, found out at the same time. Adobe are going to migrate to Cocoa at some time or another, and it will be in everyone's best interesst to do it sooner rather than later. Adobe is lazy and they've shown it time after time.. just watch their poor support for OSX in the beginning and Universal Binaries. They promosed to be the first, but they were the last..

Re:The blame falls solely on Apple

[TejWC]

I think that even if they were told a year or 2 in advance about this decision, Adobe still would not have been able to make the port to Cocoa in time. I suspect a lot of their code is in C++. Carbon is also C++ which makes it easy to integrate while Cocoa is Objective-C. There is a way to combine C and C++ code, but if the wrong person does it, it can lead to a big mess. Even open source projects like OpenSceneGraph (OSG) and Qt are having trouble making a Mac 64-bit since its so hard to combine the Objective-C and their C++ together (but it can be done). So its easy to blame Apple for their "last minute" change, but for a large codebase like Photoshop, it wouldn't have made much of a difference.

Re:The blame falls solely on Apple

[mini me]

I'd be very cautious of any developer who knows C++ but can't pick up Objective-C at a moment's notice. Getting to know Cocoa will be the bigger challenge, but that would be true even if it were implemented in C++.

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:The blame falls solely on Apple

[LWATCDR]

There is a difference between being picking up a language and knowing the language. Yes a good C++ developer can start coding in Objective-C in a few days or maybe weeks. I would bet that it will take a few months before they are really comfortable with it. Then toss in Cocoa and you have a pretty steep learning curve. It will just make it harder to develop software for both Windows and Mac. There are few companies that will choose to drop the Windows market for the Mac market.
I would love to try Objective-C but the lack of bindings for GTK, QT, and Windows keeps me from putting in the effort.
It is a shame since I hear that Objective-C is better than C++ in many ways.

Re:The blame falls solely on Apple

[Anonymous Coward]

I don't think so. It doesn't matter what they promised regarding 64-bit carbon. EVERYONE knew carbon was going away and was only meant to be a bridge. Adobe should have used carbon to get PS to OSX and then went to work recoding it to cocoa.

Re:The blame falls solely on Apple

[Caiwyn]

There was NO reason not to let developers know there would be no 64 bit carbon as soon as the decision was made, but Apple waited until the last possible second for who knows why.

Actually, it sounds like Apple waited until the last possible second to make the decision to drop 64-bit carbon in the first place.

Still their fault, but because of planning, not because of secrecy.

Re:The blame falls solely on Apple

[Anonymous Coward]

"...that you plan to phase out Carbon and that if you want a 64 bit GUI you better be making it in Cocoa?"

Not only that, I can't understand why developers put up with them at all. For example, they have this tendency towards only wanting to support Objective C (nothing wrong with that particular language, but it's pretty obscure). I can't think of any other major platform (linux, Win32) that feels the need to control what language the user wants to use in that way.

Re:The blame falls solely on Apple

[Black-Man]

YEARS have passed w/ everyone knowing that Carbon was a stop-gap and was certainly NOT the go-forward approach for software development on OSX. Code Warrior has been gone for how many years - and these companies are basically still leverging their legacy code base. Adobe probably sent the code to India for a port to Carbon and now that the exchange rate is cost prohibitive, they refuse to move to Cocoa.

And spare me the "oh... but objective-C is SO hard".

Re:The blame falls solely on Apple

[Siker]

I think that perhaps you are a little negative. Objective-C and Cocoa are different from C++ in some aspects but otherwise fairly straightforward. I believe a good C++ developer would have their first Cocoa mini application within a day and fancier stuff, such as drag and drop and custom UI components, within a week. From there on it only gets easier. There's a lot of power in the Cocoa UI kit.

What works in Adobe's advantage in this case is that they most likely have a pluggable UI architecture already since the application is already cross platform. The rest of the code base such as image opening and saving, filters, manipulation and so on is unlikely to contain even a line of Carbon code.

Re:The blame falls solely on Apple

[LWATCDR]

I have not looked at Objective-C in much detail. And yes a mini app in a day is almost a sure thing. However I can tell you that just from moving between PHP, Perl, C++ and Java that there is a big difference between knowing a language and just knowing how to use the language. I worked in C++ for months after working in Java for months and still didn't feel like I knew C++.

I can tell you from experience that a GUI on a large complex program like Photoshop is far from a simple construct.
I agree that it can be done. I just don't know if for a lot of companies if it will be worth the effort.
As I said it will be good news for QT.

Re:The blame falls solely on Apple

[The Analog Kid]

The end result will be a lot of 32 bit apps will stay 32 bit apps.

and the large percentage of Apple users won't care even then, you don't think companies will eventually put out 64-bit Cocoa apps anyway?

Re:The blame falls solely on Apple

[mini me]

I worked in C++ for months after working in Java for months and still didn't feel like I knew C++.

I'm not sure it's possible for anyone to know everything there is to know about C++.

But in this case Objective-C is C with objects and C++ is pretty much C with objects. If you know C++, you already know most of what you need to know. Although Obj-C is a dynamic language, it's really not a huge paradigm shift like you find moving between other languages.

Re:The blame falls solely on Apple

[Jesus_666]

Any nonprime bittage is evil. I propose a 7 bit memory with floating parity (in the Nth byte the (N % 7)th bit is the parity bit). Storage would use 13 bit bytes with reverse floating parity (in the Nth byte the ((13 - N) % 13)th bit is the parity bit). Every 91st (13 * 7) byte in both storage and memory is a leap byte and has no parity bit.

Re:The blame falls solely on Apple

[prockcore]

Years have passed with everyone knowing that the only way to run C++ apps on OSX is to use Carbon. I'm sure adobe was waiting for Apple to finally provide c++ bindings for Cocoa.

It probably will happen eventually. After all, there's a reason iTunes is still a carbon app.. Apple doesn't want to rewrite it from scratch.

Re:The blame falls solely on Apple

[Eccles]

I think that even if they were told a year or 2 in advance about this decision, Adobe still would not have been able to make the port to Cocoa in time.

Agreed.

I'm a professional developer on a commercial Mac/Windows app similar in scale to Photoshop. We've had to port from OS9 to OSX, and from PPC to universal binary. Both have been significant transitions, and developer time spent supporting them is time not spent improving the product in other ways. Using Cocoa rather than Carbon would have delayed our product with no benefit to the user, so as long as it was available, we went with it.

If we have to switch for 64-bit Appleness, we'll do it, but only when there's a definite benefit to a goodly percentage of our users. Hopefully this will be the last major transition for a long time, and we can devote our time to improving the feature set.

Re:The blame falls solely on Apple

[Anonymous Coward]

"Actually killing carbon is DUMB. To use Cocoa you have to use Objective-C for the GUI. There is a lot more experienced c++ developers than Objective-C developers."

Killing Carbon is GOOD, and it's about time! Carbon is crap, and there is very little (if any) reason to use it anymore. Being experienced in C++ has absolutely nothing to do with using Cocoa or not. You can program Cocoa with Objective-C++. Anyone who has enough brains to understand how to program in C++ can learn Objective-C/C++ in a weekend and be proficient with Cocoa in two weeks -- master it in two months. And on top of that, you can use C++ and C (or whatever else) right along-side the Cocoa code. Cocoa is *very* easy to work with compared to any other API out there (actually .NET isn't too bad, but it runs through a virtual machine so I don't really count it in the same category).

Adobe is always bitching at Apple for changing anything, and then they drag their feet getting their software up to date. Their attitude is that Apple *needs* them for the Mac to be successful so they can bog Apple down when they want. While there is a degree of truth to that, Adobe isn't going to benefit from that strategy in the long run because Apple's attitude back is becoming more and more: Fuck Adobe.

Re:The blame falls solely on Apple

[bnenning]

I'm sure adobe was waiting for Apple to finally provide c++ bindings for Cocoa. It probably will happen eventually.

It won't, unless C++ changes significantly. The fundamental issue is that Cocoa needs to be able to call arbitrary methods on arbitrary objects when both are determined at runtime (see the NSObject "performSelector" method). As far as I know C++ can't do that.

Re:The blame falls solely on Apple

[PitaBred]

Sure, you can build a trivial app without much issue. How about porting an existing C++ behemoth like Photoshop? That's nowhere near trivial, even for an experienced Obj-C developer. Because you can't just use what you already have... you have to rewrite EVERYTHING. And in a codebase like Photoshop, that's not quite like porting Notepad.

Re:The blame falls solely on Apple

[Sentry21]

Well C++ developers can opt to use Obj-C++ for their glue code, which is going to be 'similar enough' for any good C++ programmer. There's no requirement to rewrite your application - just rewrite the GUI code (which you have to do anyway) and any OS-dependent code, and you're off to the races.

If nothing else, hire an Obj-C programmer on contract to do the integeration for you, and they'd proably do a better job than someone new to the platform would anyway.

Re:The blame falls solely on Apple

[laffer1]

It looks like there is an Objective-C GTK wrapper among other things.

http://www.foldr.org/~michaelw/objective-c/

Re:The blame falls solely on Apple

[catmistake]

Adobe is the new Microsoft. As they got huge, they got slow and lazy. They have abandoned Apple before, the company that put them on the map and made them great (once), and now, because they are slow and lazy, they will do it again. Adobe, like Microsoft, is no longer interested in developing new products. Software development is too hard and expensive. They'd much rather take old source, bugs and all, and run it through translating compilers, put it in a new box, and sell it as if new. Carbon was a transitional solution, and now the transition is complete. But Adobe is not impressed with Apple's slick new dev platform. It will require them to hire sharp new developers and task them to (gasp!) develop something. God forbid Adobe ever start from scratch, when their 15-year old source has been pulling them along with such slow but predictable momentum. Apple's only crime here is attempting to push technology forward. The Big tech co.s don't need trailblazers... they just want to repackage and resell the same old crap.

Re:The blame falls solely on Apple

[anarkhos]

I would love to try Objective-C but the lack of bindings for GTK, QT, and Windows keeps me from putting in the effort. Uh, what does GTK or QT have to do with anything? Is there something inherently nice about a GTK app? Qt's API, if you actually like it for that reason, would not work in a language other than C++.

The only awesome thing about ObjC is Cocoa, so wanting a non-Cocoa ObjC framework makes no sense.

If you want Cocoa on Linux and Windows, however, you already have it. It's called GNUStep.

Re:The blame falls solely on Apple

[anarkhos]

64bit Carbon was on the verge of beta testing before it was axed for purely political reasons.

There's no reason to axe Carbon. It doesn't even 'compete' with Cocoa. Cocoa is more like PowerPlant, and uses some Carbon APIs.

At least PowerPlant's source was available so we could fix bugs instead of filing radars.

Re:What will happen?

[falcon5768]

IF you RTFA you would know that what you said has NO basis on whats being talked about. But then you where just trolling anyway.

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:bad summary - there will be a 32-bit version

[Anonymous Coward]

But this is exactly what is stated in the summary:

There will be a 64 bit version.
It will be only for Win64.
Not for OSX.

There is absolutely nothing said/inferred with respect to the 32bit-Version.
The Summary would be misleading if it stated "Photoshop CS4 Windows-only", but it does not.

How the heck is a wrong "correction" modded +5 informative?
Bunch of illiterates! I'm heading back to digg!

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:bad summary - there will be a 32-bit version

[Schnapple]

I think you misunderstood the intent of the summary/headline. The issue is not that there won't be a 32-bit version for Windows or that there won't be a version for Macintosh (that would be suicide). The issue is that the 64-bit version of Photoshop, an app which could really use the extra muscle and RAM of a 64-bit machine, is going to be Windows-only because Apple hasn't gotten their shit together yet.

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

[Fri13]

"What's Adobe doing with Photoshop?" Or other naturally raised question is "What Microsoft is doing with Adobe". Microsoft will "kill" Adobe much easier if Windows is only OS what can have professional tools. I dont drop of idea that this is low strike from Microsoft.

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

[Fri13]

Damn, "Microsoft will "kill" Apple much easiero.." (why this kind typos cant be found when previewing :-/)

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.

Re:What will happen?

[Dr. Eggman]

Isn't that debate just a relic of days past anyways?

At any rate, as a user of Windows XP 64-bit edition, the anger at being treated like a second class citizen knows no bounds. I have Vista on one machine and XP 64-bit edition on another; XP 64-bit edition still has fewer compatability issues than Vista and runs faster and more reliably, too.

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:But AMD64 could be...

[jackbird]

Well, for those of us working with large images, programs speed up because they aren't constantly thrashing the swapfile.

Re:But AMD64 could be...

[crusty_yet_benign]

The speedup comes from the fact that, in addition to increasing the bits, AMD also added a bunch of extra registers to the spec.

Vendor-specific registers aren't the point (and I doubt whether Adobe spends much time on them, as "Optimized for Intel" as they've become). The extra address space speeds things up by preventing (much) swapping/paging.

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:But AMD64 could be...

[crusty_yet_benign]

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

Re:But AMD64 could be...

[K. S. Kyosuke]

The additional GPRs and XMM registers are not vendor-specific, as they are a natural part of the AMD64/EM64T platform, and Intel has adopted them as well, as they are a required part of the specification. These registers may speed up tight inner loops by allowing to keep more data a hand. Yes, I know that this is not going to help many applications, for example data structures with a large percentage of pointers/references (trees and graphs, for instance) might actually get slower on 64 bits due to the size increase and memory "speed" (unless you are using something like DataDraw), but expensive computations on packed homogeneous data can get much faster under right circumstances.

If you can generate tight inner code from a node tree, for example, even if the expression trees you can compile are very simple, things can get much faster, because less accesses even to cache equals more speed. You basically cannot saturate a modern PC CPU's execution units from memory today - if you're not running from registers and have to hit the memory to reach the big picture (pun intended :)) in order to just multiply and add some pixel values from several layers, you might be losing an order of magnitude of performance compared to the theoretical limit. If the operations are more complex, and you have dozens of layers and you are adding them and multiplying them and processing them all over the place, it is faster to keep the intermediate the values in registers even at the cost of having to generate some code. The other option is to spill the values into intermediate buffers and that is not a good thing for performance.

I do not think that the people at Adobe are dumb. VirtualDub uses this idea, and I think I read something about the Windows GUI kernel using such techniques as well. I fail to see why the leader in the market of graphics editors would avoid such opportunity.

Re:But AMD64 could be...

[afidel]

I don't think the GP was suggesting that the extra registers were AMD exclusive, more giving credit to AMD for the x64 design.

Re:But AMD64 could be...

[Hal_Porter]

The benchmarks I've seen seem to imply that the speedup is not that great. Probably because all x86 processors have more internal registers than the architected ones and use register renaming to allow code to take advantage of them, even though the code only thinks it is using the architected number of registers.

Re:But AMD64 could be...

[pato101]

My experience with numeric code, compiled in 32bit and 64bit is that the same code tends to be about a 15% slower in the 32bit case.
When the code uses more than 1Gb of RAM, the differences are much higher.
The tests where done in a 64bit install with a 32bit chroot (so the kernel was 64bit). The 32bit executable performed exactly under the 32bit chroot or directly on the normal 64bit usage. (the 32bit chroot was used to compile the binary, since it is quite easy to setup)
I'm not sure if at that time I did dual-boot to check the 32bit executable in a 32bit kernel, but I guess I would get the same results: poorer performance of about a 15% when memory usage is directly addressable with 32bit...

XP too...?

[snarfies]

Will it run on 64-bit editions of Windows XP? I certainly hope so, as I have zero intention of downgrading to Vista, but I do intend to run XP x64 on the computer I'm currently building for video editing work. If 64-bit Photoshop works out, I'm hoping 64-bit Premiere Pro will be following.

Re:XP too...?

[Anonymous Coward]

Why would they support 64-bit XP? The support for 64-bit XP is much worse than 64-bit Vista, and Vista is the future - like it or not.

Re:XP too...?

[Anonymous Coward]

Windows XP 64 bit edition? How many people use that? Four?

Re:XP too...?

[Zebra_X]

Speaking from experience, you will gain nothing by using XP x64 as opposed to Vista X64. XP64 has the same problem that Vista 64 has - lack of driver support and lack of most apps supporting x64.

Things like the old Cisco VPN client simply don't work.

Just go to Vista 64 if you think you want or need to use 4GB of RAM.

Despite what you've heard there are some nice things about it too, it isn't that bad and you will get more drivers for it as the years wane on. It is also more secure, and you don't run the risk of not getting support in the near future.

Re:XP too...?

[CogDissident]

Wow, can nobody here answer the man's question with anything except sarcasm?

Yes, it will run on 64 bit editions of XP, it says so in the article. The summary just assumes that 64bit means "vista". Great slashdot editors as always./sarcasm

Re:XP too...?

[harry666t]

> and Vista is the future

I thought I read "futile".

Re:XP too...?

[neumayr]

I too was tempted to write a sarcastic reply, but it seems that is taken care of.
So, trying to be somewhat constructive, if you're used to XP64 with all its support issues and weird driver hacks, Vista64 wouldn't be a bad update. In my experience at least, its market share and better support from Microsoft makes it a lot more usable.

Re:XP too...?

[Anonymous Coward]

You sir, are an idiot.

LOL

[Zebra_X]

Really amazing.

How can Apple get away with essentially discontinuing updates to one of its core programming environments. You can't just tell your partners "oh hey, yeah we just decided that we're not going to support X anymore".

Re:LOL

[Zebra_X]

Cocoa and Carbon are not just API's they are core system interfaces.

It is equivalent to MS saying they will not support 64 bit platforms for MFC.

Re:LOL

[elrous0]

Your clever use of the term MacroSuck as a parody of Microsoft was comic genius. The fact that you added the (tm) at the end just sweetened the deal!

On behalf of myself and all the other "According to Jim" writers, I would like to offer you a job on our writing staff. We call ourselves the "yuck yuck factory" (get it? it's because we write jokes!) and could use a sharp comic wit such as yourself. Tell me, how good are you at writing my-annoying-mother-in-law gags? Because, since Peter left during the strike, we've been really weak in that area.

Re:LOL

[Raffaello]

You're clearly unfamiliar with the history. Apple have been saying that Carbon was a temporary transitional framework and that developers should move to Cocoa since the late 90s.

Dropping 64 bit support for Carbon *GUI* code (yes, there is 64 bit Carbon, just not 64 bit Carbon GUI libraries) was just the latest in Apple's long litany of warnings that Carbon is eventually going bye bye and developers should transition to Cocoa, something they were told to do nearly a decade ago.

Re:LOL

[mini me]

It's the only way to keep technology moving forward. If you take the Microsoft approach of maintaining backwards compatibility with just about everything ever written, you end up with an operating system that hasn't seen any real improvement in a long, long time.

Discontinuing Carbon is a good thing. Carbon applications don't play very well with the rest of OS X and, as a user, that is frustrating. It sounds like Apple could have done a better job at making the fact known that it was going to be discontinued, but never discontinuing it would have been a bad thing for the future of OS X.

Re:LOL

[mnoel2]

You're clearly unfamiliar with Carbon. There are really two kinds of GUI Carbon: ancient stuff from Mac OS 9 and older, and new hot HIToolbox APIs introduced in 2002-2004, for 10.2 and 10.3. The new APIs are clean, written in a prototype OO, near-Core Foundation style, with increasing integration with Cocoa and a basis on composited windows, opaque Carbon Events which interact well with Foundation (Objc) and Core Foundation (C) types, Quartz graphics, and suppport for embedded Cocoa controls.

If Carbon were a stopgap, why would Apple spend all this money on 'modern Carbon'? From what I understand the Modern Carbon I had management's full support until suddenly they didn't.

I work on one of the largest Carbon apps out there, and I'm a huge Cocoa bigot. I'm happy about Cocoafication, but i understand the business justification for staying Carbon while Apple kept giving us an improved HIToolbox with each release. Denying that apple went to considerable expense to modernize and extend Carbon in a useful and interesting direction, and then killed the project in mid flight when they'd been telling us about and then doing all this cool carbon modernization, is just being their apologist. We were encouraged to keep using it, it made sense to do so, and then suddenly it's our fault that we did.

Re:LOL

[mrchaotica]

It is equivalent to MS saying they will not support 64 bit platforms for MFC.

No, MFC is like Cocoa (object-oriented and all that, C++ vs. ObjC). Carbon is more equivalent to the Win32 API (both procedural C).

Re:LOL

[macs4all]

I replied to this, but something ate my reply...

I thought all the "bad mother-in-law-jokes" wrote themselves!

But if your offer isn't some kind of sad, belated April Fools' joke, gimme a shout at dmcintosh256_at_gmail.com

Re:LOL

[Zebra_X]

You're clearly unfamiliar with the history. Apple have been saying that Carbon was a temporary transitional framework and that developers should move to Cocoa since the late 90s.

And you don't really seem to be familiar with the platform. Puma was released in 2000/2001 - So I'm not sure how you arrive at "should move to Cocoa since the late 90's" as there was nothing to program against during the late 90's.

Dropping 64 bit support for Carbon *GUI* code (yes, there is 64 bit Carbon, just not 64 bit Carbon GUI libraries) was just the latest in Apple's long litany of warnings that Carbon is eventually going bye bye and developers should transition to Cocoa, something they were told to do nearly a decade ago.

It doesn't really matter what code it is. Dropping support for a major API is not something that a business should reveal at a developer conference. It is something that you put in a "roadmap" to let your "partners" know where you are going. Such a transition should be executed on the scale of years so that no one is caught by surprise. That is not what is going on here - and thus the reason for my post.

I have to blame Apple

[MegaMahr]

You have to think that by now Apple would have their SDK in order concerning 64bit apps. The 64 bit achitecture has only been around for 10+ years...

Re:I have to blame Apple

[ruiner13]

Apple has basically 2 frameworks to create OS X apps, carbon and cocoa. Cocoa is the "native" version, per se, for OS X. Carbon is a transition environment for people to get OS 9 apps running in OS X quickly, usually with just a recompile. Apple has said since OS X came out that carbon (which Photoshop is written in) was not the way of the future. So, last year, Apple announced that there would be no 64-bit support in carbon. Cocoa has had 64-bit support for a long time, since the G5 came out. Much of the OS in the latest version of OS X itself is 64-bit code now, and more of it is each OS revision.

Re:I have to blame Apple

[IntlHarvester]

Nope, 64-bit Cocoa is new in 10.5. Apple had no way of running 64-bit GUI applications prior.

Also your description of Carbon is incorrect, RTFA.

Equality

[Slimee]

I suspect a government coverup here. I think us slashdotters could blow this whole thing wide open with a little snooping...

But seriously, I enjoyed the articles neutral point of view in that both parties are to blame, apple for bailing on Carbon, and Adobe for neglecting Cocoa. Oh well, I'm still stuck in the middle ages with my CS2, so I'm wholly unaffected by all of this.

Seriously, software just keeps changing too fast.

Fudge you Adobe

[theaceoffire]

Think that it is pretty clear at this point:
No Linux version as well.

CS5 will be there

[HalAtWork]

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

So the mac is not cut off. They just need time to move from carbon to cocoa. At least they are not trying to rush something through the door.

Re:CS5 will be there

[EraserMouseMan]

They couldn't even get through the door if they wanted to. It isn't a matter of being prudent and taking time to do it right. Adobe is able to get through the door on the Windows platform with no trouble.

Let the blame game begin!

[MrMacman2u]

Personally, I'm taking Adobe to task on this one.

Carbon was initially meant to be a "type" of backward compatibility with old Mac OS "less than X" applications so that they would require minimal re-writes of code to allow the program to be Mac OS X "native".

Apple has been pushing people to use the "more native superior" Cocoa framework for a number of years now by not only urging programmers and developers to use Cocoa but, by also enhancing the speed, stability and capabilities of Cocoa while Carbon stagnated (comparatively) and Adobe has constantly and stubbornly refusing to re-write ANYTHING they make to use the superior Cocoa framework.

This has been the case since the "Photoshop 7 ver.2" generation of Adobe's Mac products.

Lightroom uses Cocoa because it was made from scratch. That's it. If it was a hold over from pre-X days, I would bet my geek creds that it would be written in carbon.

Yes, I do fully realize that re-coding all of Adobe's Creative Suite to the Cocoa framework is a monstrous task, but Adobe has been severely dragging their feet regarding the switch-over which, I might add, they "hoped for in CS2 and "promised" for CS3!

That totally happened..... oh wait, it didn't! So now Adobe is caught with their pants down and doesn't want to admit it, despite Apple saying "You're not supposed to use Carbon anymore!" for years.

So no, this is not Apple's fault. It's Adobe's and I look forward to seeing any counter-arguments!

This should be interesting!

Re:Let the blame game begin!

[elrous0]

Ah, don't worry. It's not like anyone uses Apples for graphic design.

Re:Let the blame game begin!

[Tridus]

So no, this is not Apple's fault. It's Adobe's and I look forward to seeing any counter-arguments! TFA said that Apple promised Carbon would get 64 bit support in 2006, then changed their minds and cancelled it in 2007.

If Adobe expects Carbon to get 64 bit support (because Apple said so) and then it suddenly doesn't, its pretty easy to see how that is going to screw things up. That part is Apple's fault.

So since their Carbon version isn't going to ever be 64 bit, they need to do a Cocoa port to get there. Thats only necessary because of Apple's cancellation of 64 bit Carbon, so its Apple's fault.

(Though I tend to agree with TFA that Apple's decision to do that was right, in the long term.)

Re:Let the blame game begin!

[MrMacman2u]

You act as if planned and/or announced features/products have never been canceled or abandoned and Apple is the only one to ever do this. *COUGH!*M$VISTA*COUGH!**COUGH!*

They decided to cancel 64 bit support for carbon and announced it. It's not like they simply decided to ship the next update/version of Carbon as 32 bit only and never told anyone.

Adobe's fair warning came 10 years ago. Carbon has always been a stop-gap. IMHO, no amount of blame directed anywhere but straight at Adobe should be cast.

Re:Let the blame game begin!

[Jeff DeMaagd]

You act as if planned and/or announced features/products have never been canceled or abandoned and Apple is the only one to ever do this. *COUGH!*M$VISTA*COUGH!**COUGH!*

Why should an Apple fan have to justify it by comparing it to Microsoft?

From what it sounds like, at WWDC 07, people had to ask Apple reps where Carbon 64 went, there were no dev sessions in 07, when there were Carbon 64 dev sessions in WWDC 06. It sounds like Apple went out of their way to hope that people forgot about it. Maybe we should ask Apple when Final Cut Studio will be all Cocoa.

Re:Let the blame game begin!

[Anonymous Coward]

Carbon was initially meant to be a "type" of backward compatibility with old Mac OS "less than X" applications so that they would require minimal re-writes of code to allow the program to be Mac OS X "native".

Apple has been pushing people to use the "more native superior" Cocoa framework for a number of years now by not only urging programmers and developers to use Cocoa but, by also enhancing the speed, stability and capabilities of Cocoa while Carbon stagnated (comparatively) and Adobe has constantly and stubbornly refusing to re-write ANYTHING they make to use the superior Cocoa framework.

This a complete misrepresentation of how Carbon was presented to developers. As an Objective-C audio developer who was seeded with pre-releases of OS X, a perfect example of Apple's attitude is that much of the CoreAudio APIs were made solely available under Carbon (C++) and the support for Cocoa has been grudging at best - utterly pathetic would be a more accurate description for most of the years since OS X was announced. As someone else pointed out, Apple's solution to this is to redefine the two such that APIs that were called Carbon are now being called Cocoa with no significant changes made.

Re:Let the blame game begin!

[Anonymous Coward]

Counter argument: Apple needs to accept that telling a developer of an undoubtedly huge code base to just rewrite the whole damn thing in a different language, and then again iron out all the bugs, rebind the GUI, reoptimize it, etc just might be a bit much to ask for a platform that has, what, 8% of the market ? Yeah so Apple's market share might be bigger in a graphics environment. That's because historically, they had a huge lead up on windows in what their machines could do graphically. That advantage won't last them forever if they keep cutting off established code bases with changes "just because".

Why do you think MS makes absolutely sure that developers understand that C++ keeps working, keeps improving and keeps evolving in the new Visual Studio's, despite the fact that MS would really really really like us to use .Net ?

Re:Let the blame game begin!

[Reverend528]

If apple is going to force adobe to rewrite most of photoshop's user interface, then they should port it to a graphical engine that isn't going to disappear when apple eventually gets bored with it. That's why the next photoshop should be ported to X11. The X-windows system isn't going away any time soon and it would allow adobe to more easily port the application to other Unix/X11 operating systems.

Re:Let the blame game begin!

[Blakey Rat]

There's this thing called "usability" that Apple customers are kind of a fan of. X11 (at least on OS X) don't got it... not even remotely close to the usability of native apps. About half of OS X's usability features simply do not work in X11, and another quarter are crippled in some way.

So, no, porting to X11 is not a good move.

Re:Let the blame game begin!

[Daimaou]

So no, this is not Apple's fault. It's Adobe's and I look forward to seeing any counter-arguments! I agree. I think Adobe has been far too lazy for years with their codebase. It is huge, bloated, slow, and needs desperately to be rewritten. Instead of clinging on to all that legacy code, I think Adobe should have put together a small team of engineers to work on a rewrite of both Photoshop and Illustrator to improve and sync up the UIs, streamline the code, and amongst a lot of other things, use Cocoa like Apple has been saying for years. If there were another option for me, I would have left the Adobe boat a long time ago.

Re:Let the blame game begin!

[Reverend528]

About half of OS X's usability features simply do not work in X11.

I hate to burst your bubble, but X windows supports all of the same gui abstractions that OS X has:

• icons
• menus
• tabs
• scroll bars
• buttons
• text fields

In fact, The X Windowing system had many of these usability features before there even was an OS X.

Re:Let the blame game begin!

[croddy]

Perhaps Apple should ask the X.org foundation for help with their X server. I've noticed that Apple's X11 is pretty poor compared to the ones distributed wtih Unix OSes.

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:Let the blame game begin!

[bnenning]

That totally happened..... oh wait, it didn't! So now Adobe is caught with their pants down and doesn't want to admit it, despite Apple saying "You're not supposed to use Carbon anymore!" for years.

Except that's not what Apple had been saying. They've always encouraged developers to use Cocoa for new apps (mainly because it's almost always more productive), but never said that you needed to rewrite your existing Carbon apps. Furthermore, they specifically said that 64-bit Carbon would be available in Leopard, and shipped it on developer releases, which undoubtedly led many developers down what turned out to be a blind alley. If Apple had officially put Carbon in maintenance mode with Tiger or earlier, there would be a lot fewer complaints.

Re:Let the blame game begin!

[nbritton]

"TFA said that Apple promised Carbon would get 64 bit support in 2006, then changed their minds and cancelled it in 2007."

They probably canceled it because everyone already switched to Cocoa... Except for Adobe.

Re:Let the blame game begin!

[Anonymous Coward]

Carbon was only originally going to be around for two or three years during the transition from OS 9 to OS X. I'm not sure why Apple ended up keeping it around (probably because of Microsoft and Adobe), but it is long past its original intended EOL.

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 .

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.

Re:Let the blame game begin!

[Louai]

So no, this is not Apple's fault. It's Adobe's and I look forward to seeing any counter-arguments!

TFA said that Apple promised Carbon would get 64 bit support in 2006, then changed their minds and cancelled it in 2007.

If Adobe expects Carbon to get 64 bit support (because Apple said so) and then it suddenly doesn't, its pretty easy to see how that is going to screw things up. That part is Apple's fault.

This also happened to Trolltech. Qt on the mac is written on top of carbon.

Re:Let the blame game begin!

[Skuld-Chan]

When Adobe as is all developers are told Carbon was going to have the same features are Cocoa - mainly to make it easy to transition from OS9 to OSX, and are told in 2006 that 64 bit Carbon was a promised feature, and Apple pulls support for 64 bit Carbon in 2007 that gives Adobe less than a year to react. I honestly don't see why Apple can't continue to develop it until OSX is eol'd.

In an already small product cycle (about 18 months to 2 years) that means essentially making a pretty significant design decision on a very big project midway through the product lifecycle - not 10 years ago.

Also Apple hasn't been saying "you're not supposed to be using Carbon anymore!" - if anything they encouraged developers by a) saying it was going to be feature equivalent to Cocoa and b) was going to have 64 bit support.

Re:Let the blame game begin!

[jtranber]

Adobe has been severely dragging their feet regarding the switch-over which, I might add, they "hoped for in CS2 and "promised" for CS3! For a Cocoa port? Where did you pull that quote from? I wouldn't attribute a quote to someone unless you can cite the reference.

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

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.

hey

[Neuropol]

who cares.

GIMP runs well on macs with xcode & developer tools installed.

Re:hey

[Anonymous Coward]

hahaha!

I like the GIMP just as much as anyone, but I have no illusions that it's a full Photoshop replacement.... especially for the professional market who would benefit most from 64-bit.

Re:hey

[Tatsh]

GIMP runs on nearly everything it can compile on (Windows, Linux, Mac, 64-bit versions as well). I don't care about this news because Adobe is irrelevant to me until they open up Flash or something open replaces Flash. I haven't used Photoshop in at least a few years now. GIMP has replaced Photoshop for me. I know there are a lot of people who will say Photoshop cannot be replaced with GIMP, but I disagree for what I do. In many aspects, I found some things easier to do in GIMP than in Photoshop. The only thing I would say that I miss from Photoshop is borders and shading option dialogue and the basic shapes you could easily make.

Re:hey

[Abreu]

But, does Gimp have CYMK color already?

(honest question, really)

Re:hey

[Neuropol]

CMYK color profiles may be loaded from a disk though.

Re:hey

[Culture20]

When I want to make a huge working image (bigger than 3GB in RAM) on a mac, I'll have to do it with something other than PS (or make a ramdrive and put the "HDD cache" on the ramdrive).

Bad move by Adobe, but Apple will suffer for it more than Adobe will.

Adobe's foot-dragging? Most users won't care.

[argent]

I've been using 64-bit systems since 1994... including ILP64 Alpha processors... and unless you're memory starved 64-bit software tends to be slower than 32-bit software... with one exception: there's a serious problem with 32 bit mode that the 64-bit mode doesn't have.

On the Alpha, the problem was that 32-bit mode requires trapping many accesses because the CPU is *purely* 64-bit.

With AMD64, AMD implemented a large register file efficiently, so a good compiler can generate better code for it. Intel's implementation of AMD64 doesn't seem to be as good, and since Apple is on Intel...

Also, Adobe has to have a 64 bit version for Windows, because Windows comes in 64- and 32- bit versions, but OS X has the same support for both 64- and 32- bit in the same OS...

So unless you're editing truly enormous images, far larger than most users ever deal with, this doesn't matter.

On the plus side, Apple's been trying to kick Adobe into converting to NeXTSTep/Yellow Box/Cocoa since 1997, and Adobe's knuckle-dragging over abandoning Classic is what made Carbon necessary in the first place, so I don't think Adobe's in any position to say Apple didn't give them plenty of warning.

It's been 11 years and they're finally going "oh, man, I guess Apple's really serious about this Objective C stuff!".

Re:Adobe's foot-dragging? Most users won't care.

[Joehonkie]

What are you talking about? 64-bit Windows runs 32-bit software just fine.

Re:Adobe's foot-dragging? Most users won't care.

[Coopjust]

x64 Windows runs 32-bit applications fine unless they rely on some 16-bit components, or it relies on some form of virtual driver. Photoshop CS3 is a x32 program, and it runs on my x64 Vista.

Re:Adobe's foot-dragging? Most users won't care.

[dubl-u]

I don't think Adobe's in any position to say Apple didn't give them plenty of warning.

Adobe's just a civilian casualty in an internal war in Apple. If the writing were so obviously on the wall, then why would iTunes still be a Carbon app?

Early on in the merger (circa WWDC 97), the NeXTies believed that everybody would quickly convert to what is now Cocoa, because it was obviously superior. To them, anyhow. But a lot of people were perfectly happy with the way they were doing things, and that included many of the developers inside Apple. The way I read it, the war went on for TEN YEARS, which is why you saw them promising 64-bit Carbon. And then the Carbon side finally lost, explaining the sudden cancellation.

Re:Adobe's foot-dragging? Most users won't care.

[argent]

If the writing were so obviously on the wall, then why would iTunes still be a Carbon app?

Because it doesn't matter if iTunes is 32-bit? More importantly, it has to run on Windows, and keeping the OpenStep on Windows project alive for one application is a poor use of resources?

And don't forget that Adobe wasn't just foot-dragging on Cocoa, they were footdragging on XCode and Apple's compilers as well. And they did get advance notice that they'd need to switch for Intel, there, so they don't have the "Carbon Excuse" there.

Re:Adobe's foot-dragging? Most users won't care.

[argent]

64-bit Windows runs 32-bit software just fine.

Except when it doesn't.

There's quite a few programs that don't work as well or don't work at all on 64-bit.

Re:Adobe's foot-dragging? Most users won't care.

[Kasracer]

"Also, Adobe has to have a 64 bit version for Windows, because Windows comes in 64- and 32- bit versions, but OS X has the same support for both 64- and 32- bit in the same OS..."

That makes no sense. Microsoft's 64-bit OS is just like Leopard in that it can work with 32-bit and 64-bit on the same OS.

Adobe doesn't have to do this as Adobe Photoshop CS3 runs just fine under 64-bit.

This does, however, prove that the Photoshop project manager (or whoever it was from Adobe) was full of shit saying they weren't going to move to 64-bit because their code is so optimized that any benefits of moving to 64-bit are neglegable.

Re:Adobe's foot-dragging? Most users won't care.

[Anonymous Coward]

Adobe has dropped the ball on their applications more than you think. I used to be the Mac specialist at the number one luxury media magazine company in the US. I have used Photoshop since version 2.5 and I continue to use it today so I was interested in how the program ran on the new 8 core macs. You would figure that after 8 years of a usable OS X Adobe would have re-written their code to take advantage of the unix underpinings. Not so. I challenge anyone to create a large image in Photoshop, say resize something 3000 x 3000 pixels to 10,000 x 10,000 pixels and then run a filter like gaussian blur on it and watch the activity monitor. All the activity from this operation goes to only one of the 8 cores. So you sit in front of one of the fastest computers on the planet and wait becuase Adobe hasn't re-written a single line of their filter code since before OS X shipped. Their memory management sucks too. The thing is, for the kind of processing that you do in Magazine publishing, a core 2 duo iMac is totally sufficient, you will not get better performance out of the high end machine because Adobe's ancient code can not take advantage of it, except maybe relating to video card issues. Nobody cares anymore anyway, why publish magazines when you can make movies on Final Cut Pro with the same machine. The professionals that drive the publishing industry will never go PC, I have seen art departments threaten to walk out at the mere suggestion. You have to ship the book, and PCs have never done it. So when the rest of the world accelerates, the core industry that paid for Adobe's rise to greatness gets shafted. Thanks guys. Here's an answer to all Print production and Prepress shops -- You have a working solution...don't upgrade. Don't upgrade ever till you get what you deserve, or until Adobe gets what it deservers.
'

Re:Adobe's foot-dragging? Most users won't care.

[interval1066]

What exactly is a "large register file"?

Re:Adobe's foot-dragging? Most users won't care.

[_|()|\|]

What exactly is a "large register file"?

According to Wikipedia, "A register file is an array of processor registers in a central processing unit (CPU)." AMD64's sixteen 64-bit registers make for a larger register file than IA32's eight 32-bit registers.

Re:Adobe's foot-dragging? Most users won't care.

[Anonymous Coward]

You don't know what the hell you're talking about. First, CS2 runs just fine on 64-bit Windows today. Second, new applications are going to be QA'd on all supported versions of Windows (including Vista x64), so there aren't going to be any compatibility gotchas in major software like Photoshop going forward. Finally, the 32-bit Windows-on-Windows system in Vista works just fine; the only instances where 32-bit applications have difficulty running on 64-bit Windows fall into four main categories:

1. 1. You're trying to use a 32-bit plugin in a 64-bit application. (Example: Flash/Java in a 64-bit browser.) Obviously, this can't possibly work--no mixing 32-bit and 64-bit code in the same address space. 32-bit applications using 32-bit plugins still work just fine, though. (This does raise an interesting question about plugin availability for 64-bit Photoshop.
2. 2. You're trying to use 16-bit code, which isn't supported on 64-bit processors. If you're still using 16-bit code at this late stage, you're the laughing stock of the industry. (Hellooo, old versions of InstallShield.)
3. 3. You have issues with the no execute (NX) bit introduced in the x86-64 architecture. This mainly applies to applications like the Java runtime, which dynamically generate executable code. Everyone who needs to has worked around it by now, and it's not exclusive to 64-bit mode.
4. 4. It's a compatibility problem with Vista, which is the only widely-deployed 64-bit desktop Windows. Since you'd have the same issue in 32-bit or 64-bit, presumably, QA will work around it during development.

For a major application like Photoshop, 32-bit will work just fine on both 32-bit and 64-bit editions of Windows, even if there were any major compatibility issues, just because QA testing would ensure developers worked around any issues. (But they won't have to, because compatibility is just fine.) As for whether you need 64-bit address spaces... keep in mind that many of the people who work with images in Photoshop have hundreds of layers, are working with dimensions in the thousands of pixels on each side, have multiple images open, and may want to take advantage of deep color. The people who don't use Photoshop as a glorified version of MS Paint (serious artists, the special effects industry, scientists visualizing large data sets, etc.) actually need these sort of advanced capabilities. No, you don't need 64-bit address spaces for removing red eye from your vacation photos, but you don't really need Photoshop for that, either. Some rough calculations: Windows normally provides 2 GB of memory to applications in 32-bit mode. Photoshop has been specially coded so that it supports a mode where Windows runs with 3 GB of memory to applications, but it's not commonly used. One of the advantages of 64-bit Windows is that it supports a full 4 GB address space for applications, but again, not commonly taken advantage of. Now, let's say you have a 4000x4000 image with 4 channels of 32-bit floating point color (not unusual at all in scientific or cinematic applications). You're already up to about a quarter of a gigabyte of memory. Throw in a few working copies, levels of history, and large numbers of detailed layer work (not to mention the memory needed for the application and its associated plugins and any associated temporary memory, along with fragmentation), and you'll quickly go bust on address space. This is often why, right now, people recommend working in 16-bit or even only 8-bit color for some of these applications, if you can get away with it. Photoshop has support to swap data to disk, of course, and tiles the image to minimize memory usage where possible (serious users already have a problem with a 2-4 GB limit), but it's as clunky a hack as memory overlays were back in the 16-bit DOS era. A 64-bit implementation makes a lot of sense, and in some ways, is overdue. You don't need a 64-bit implementation of Microsoft Word; a 64-bit implementation of Photoshop is a no-brainer.

Re:Adobe's foot-dragging? Most users won't care.

[prockcore]

Because it doesn't matter if iTunes is 32-bit? More importantly, it has to run on Windows, and keeping the OpenStep on Windows project alive for one application is a poor use of resources?

Seems to me like you just explained exactly why Photoshop will stay a 32-bit carbon app.

Re:Adobe's foot-dragging? Most users won't care.

[Guy Harris]

On the Alpha, the problem was that 32-bit mode requires trapping many accesses because the CPU is *purely* 64-bit.

If by "*purely* 64-bit" you mean "has no instructions that directly load and store 32-bit words on 32-bit boundaries in memory", that's false (LDL/STL, where a "longword" is 32 bits even though "long int" is 64 bits on UN*Xes on Alpha - although it's 32 bits Windows for Alpha; a 64-bit quantity is a "quadword", as in LDQ/STQ). (I'll leave out the BWX instructions to load or store 8-bit or 16-bit quantities directly, as they showed up later, although 8-bit and 16-bit loads and stores weren't done by trapping, they were done by the compiler synthesizing them out of other instructions or by the assembler programmer doing so.)

With AMD64, AMD implemented a large register file efficiently, so a good compiler can generate better code for it. Intel's implementation of AMD64 doesn't seem to be as good,

Presumably you're talking about code scheduling, etc. issues rather than instruction set issues. What issues are you referring to?

Re:Adobe's foot-dragging? Most users won't care.

[RzUpAnmsCwrds]

Also, Adobe has to have a 64 bit version for Windows, because Windows comes in 64- and 32- bit versions, but OS X has the same support for both 64- and 32- bit in the same OS...

Photoshop CS2 (32-bit) runs fine on Vista 64.

You want a 64-bit Photoshop for one reason: it can use more than 4GB of memory.

Re:Adobe's foot-dragging? Most users won't care.

[argent]

If by "*purely* 64-bit" you mean "has no instructions that directly load and store 32-bit words on 32-bit boundaries in memory",

I mean that if you built a 32-bit executable on Digital UNIX (-xtaso/-taso), you got "Unaligned access" traps. Whether the compiler didn't generate good code, or it was simply because we started with the 21064, but we simply did not use 32-bit on Alpha - 32-bit was slower than 64-bit. We *did* use 32-bit on other platforms because it was generally faster.

Presumably you're talking about code scheduling, etc. issues rather than instruction set issues.

I'm basing this on the results of posted 32-vs-64-bit benchmarks comparing AMD's and Intel's implementations. I assumed that this was either due to better instruction scheduling on AMD or better hardware register allocation (register coloring, etc) on Intel in Intel's 32-bit model.

Re:Adobe's foot-dragging? Most users won't care.

[argent]

Seems to me like you just explained exactly why Photoshop will stay a 32-bit carbon app.

Possibly. Except that Photoshop's blog posting contradicts that.

Re:Adobe's foot-dragging? Most users won't care.

[shutdown -p now]

Also, Adobe has to have a 64 bit version for Windows, because Windows comes in 64- and 32- bit versions, but OS X has the same support for both 64- and 32- bit in the same OS...

64-bit Windows versions also run 32-bit Windows apps just fine, so you're wrong here. The sole reason to go pure 64-bit is to get more than 2Gb of RAM available in a single process; but it is a very strong reason for Photoshop in particular.

Re:Adobe's foot-dragging? Most users won't care.

[Guy Harris]

I mean that if you built a 32-bit executable on Digital UNIX (-xtaso/-taso), you got "Unaligned access" traps. Whether the compiler didn't generate good code, or it was simply because we started with the 21064

Probably a compiler bug, then, as the LDL/STL instructions date all the way back to the 21064.

I assumed that this was either due to better instruction scheduling on AMD or better hardware register allocation (register coloring, etc) on Intel in Intel's 32-bit model.

By "instruction scheduling" I assume you mean the scheduling done by the processor, not by the compiler, and by "hardware register allocation" I assume you mean assigning hardware registers to architectural registers (register renaming) rather than register allocation done by the compiler, unless you're saying that the compiler or compilers being used were not optimizing correctly for the processors being used.

Re:Adobe's foot-dragging? Most users won't care.

[argent]

Probably a compiler bug, then, as the LDL/STL instructions date all the way back to the 21064.

I don't know about a "bug", since it was documented in the manual. That makes it a "feature". :)

By "instruction scheduling" I assume you mean the scheduling done by the processor

Yes. I'm referring to scheduling of microinstructions and hardware register renaming.

Re:Adobe's foot-dragging? Most users won't care.

[Ilgaz]

If I was Adobe, I would be very mad of tools which are native OS X apps (which uses latest technologies) and communicate with non GUI Unix tools (like imagemagick) which can be run as 64bit since Tiger 10.4.0. Add the Apple CoreImage to the program, you have something very powerful in hand.

http://www.versiontracker.com/dyn/moreinfo/macosx/26426 (iMaginator)
http://www.versiontracker.com/dyn/moreinfo/macosx/30452 (ChocoFlop)
http://www.versiontracker.com/dyn/moreinfo/macosx/33411 (Pixelmator which uses imagemagick)

They weren't seeing imagemagick or Core Image as threat until some gifted, real OS X developers started to take advantage of them. If Adobe coded their application in same manner (which Apple expected them to do), they could ship 64bit Photoshop in Tiger 10.4.0 ages.

If I was developing them, I would release a 64bit version tomorrow right while people argue about 64bit Photoshop. It could be simple as a single click in XCode 3.

Isn't Adobe making sure that they can't release a Linux/OpenStep based version by ignoring Cocoa BTW? Wouldn't it be lot simpler to port to Linux/OpenStep from Cocoa?

Re:Adobe's foot-dragging? Most users won't care.

[Douglas Goodall]

In the classic x86 architecture, there were only a few registers, and they had pre-determined uses. ds:si pointed to a source and es:di pointed to a destination and bx was often an offset, and cx was often a counter. These associations were important for the repeating opcodes for moving scanning... In comparison to other architectures with lots of general purpose registers, the Intel chips have placed a huge burden on the compiler code generators during optimization. Having a pile of extra general purpose registers allows for more efficient optimized code generated. My example is more about real mode x86 then x86_64, but the example does point out the value of having lots of general purpose registers, like the 68xxx processors did in the old Mac days.

Re:Adobe's foot-dragging? Most users won't care.

[dubl-u]

Because it doesn't matter if iTunes is 32-bit?

So your argument is that Adobe should have understood that Apple liked Carbon enough to write key in-house apps in it, and enough to announce that that were taking it to 64-bit, but not enough to actually follow through? Yeah, that's persuasive.

More importantly, it has to run on Windows, and keeping the OpenStep on Windows project alive for one application is a poor use of resources?

Well clearly, Carbon on Windows is a hugely popular platform.

And the reason that OpenStep got killed is all about The Steve's inability to play well with others, and nothing to do with Adobe or iTunes. They killed OS X on Intel as a product and OpenStep as a cross-platform approach along with the Apple clone industry.

They could have kept OpenStep alive, benefiting all the NeXT developers, and, once OS X was out, anybody who wanted to do cross-platform apps. But Jobs doesn't want anybody to do cross-platform apps. He thinks just like a telco head. If he had a choice between him making a dollar and you making a dollar, or him making 50 cents and you making nothing, he'd take the latter. Because then you wouldn't be stealing "his" dollar.

Re:Adobe's foot-dragging? Most users won't care.

[argent]

So your argument is that Adobe should have understood that Apple liked Carbon enough to write key in-house apps in it, and enough to announce that that were taking it to 64-bit, but not enough to actually follow through?

Apple said from the start that Carbon was a temporary measure. And "from the start" means 1997 or so. I'm saying that Carbon was only introduced reluctantly in the first place, and Apple has a history of pulling the rug out from under developers. Not only that, Adobe didn't seem to pay attention when Apple gave them warning the last time they pulled the rug out from under them: Photoshop was about the last major Mac app to be Universal, despite Apple giving them advance warning.

Well clearly, Carbon on Windows is a hugely popular platform.

There is no "Carbon on Windows". There's "whatever bits of Carbon iTunes, which started out as a Classic application in the first place, happens to require to run on Windows".

And the reason that OpenStep got killed is all about The Steve's inability to play well with others, and nothing to do with Adobe or iTunes.

Where did I say that Steve Jobs was a nice guy or that Apple is a nice company?

I'm not defending Apple here.

I would be much happier running Rhapsody on a generic PC than OSX on a Mac... and I would even if the Mac didn't cost 40% more. I would be much happier having Openstep as a cross platform development environment. I think Apple's fascination with style over functionality under jobs sucks. I think Apple does a lot of crummy stuff, and a lot of dumb stuff. If I was running Adobe I would be mighty pissed off with Apple, too, and make sure they knew it.

But Adobe has been badly behaved as well. Adobe shares some responsibility for the death of Rhapsody, and maybe even for the end of OpenStep as an independent product. And Adobe's reluctance to make Photoshop a first class OS X application isn't just something that happened recently, it's been going on since 1997. Whatever their motivation (and I can understand why they didn't want to, in 1997, honestly I do) it's an awful long time to hold a grudge.

On the upside

[elrous0]

At least you can run Windows on Macs now.

Re:What will happen?

[arachnoprobe]

Adobe does not feel like rewriting an entire program at a moments notice

There is no "moments notice" for Cocoa. Instead it's been there since Mac OS X. Carbon is the "old" OS 9 compatibility environment, where it was clear that it will not be ready for the future. Adobe should have ported the Creative Suite to Cocoa a long time ago.

Sheesh

[MyDixieWrecked]

At my old job, I worked in the art department doing production work and created a whole range of applications for CS2, Office, Mail.app and Transmit using PERL and Applescript. There's a whole workflow that's been built around the products they use on the platform that they use (OSX).

The guys in charge of purchasing hardware/software know little about the details of technology, although they gloss over eWeek and read the Technology section of the Times. Inevitably, they will read about this and try to convince the art department that maybe they should put Vista on the MacPros, or maybe get some standard PCs (if they decide to upgrade the hardware).

this news is especially relevant to that shop since they frequently get 2GB and 3GB files (and that's compressed!).

The good news is that the majority of their clients are running OSX, as well, and this lack of 64-bit photoshop should not cause them to start sending in even larger files... however, I do know that many of the larger clients get whatever the latest and greatest Mac is and max it out. This means that they could just get a copy of Vista and use Bootcamp.

Apple kinda shot itself in the foot with this one. Shops that can, may install Vista and get CS4 for windows just to keep up with incoming work. If MS gets Vista's usability up, and can offer a competitive experience, users may get used to it and stick with the platform... although I seriously find that highly unlikely.

Re:Sheesh

[mgblst]

Apple decided to move over from some old technology left over from support for pre-OS X, to the current technology. They had to do this sometime. This is a big decision, but not one that was taken lightly.

Re:Sheesh

[van308]

>>>>> If MS gets Vista's usability up, and can offer a competitive experience, users may get used to it and stick with the platform... although I seriously find that highly unlikely. Speak for yourself... I on the other hand switch from mac to pc during my 'college' years and haven't looking back! I am so glad that I did the switch because without my pc experience I could never stay on the same job for the past six years as a graphic designer. All I ever used during my middle and high school years were mac and nuthing butt mac; hell, even my first computer was a clamshell mac!

Re:Sheesh

[MyDixieWrecked]

Speaking from my own experience, I've never really had any issues switching back and forth between windows and macOS. ]

I never really liked windows, but had to use a windows box when started working at a screenprinter. They were an all-windows shop and after about 2 months, I was able to switch back and forth between holding ctrl and holding cmd for photoshop/illustrator's move tool.

At my current job, I was on an XP machine for my desktop up until about 2 months ago when they finally got me a mac (I need to do a lot of unixy stuff and windows just wasn't cutting it... cygwin didn't work as well as terminal.app).

I'm extremely proficient with OSX, windows and linux and know them all inside and out from the systems side (although I'm weakest in windows)...

For normal day to day stuff, I don't see any huge differences between the OSs, especially for a graphics shop. The main hurdles that a mac user would have going over to PC is how cumbersome it is to work with the filesystem and navigate using Explorer. Going from windows to a mac feels much more natural because the windows users are already missing most of the shortcuts (eg for creating new folders).

So, I don't see exactly how being a windows user allowed you to hold onto your job. Not taking an art job because of the platform they use is childish, especially since the vast majority of applications are available for both. Using Macs in a design environment, to me, makes the most sense mostly because of the ability to do some incredible things with automation. I've learned VBA and have created scripts for photoshop using javascript, VBA and applescript, but JS and VBA just didn't give me as rich of an experience.

Although, I am curious... is there a decent solution for font management in the windows world? I used to use ATM, but was never completely satisfied with it. The mac side, I was always a huge fan of Suitcase until OSX came along... now I'm into FontAgent Pro.

Bloody Apple

[kramulous]

The reason why I fled the Windows programming environment was because I was getting sick and tired of having to rewrite parts of my code to run on other platforms. Having to change what should be standard stuff was the final straw.

I moved to OSX and what did I find there? The same shit with Carbon and Cocoa. I absolutely refuse to program in them because they are only supported by one platform. I've since moved to Linux. One size fits all ... as it should be. Thanks to Trolltech.

For once, I can actually understand one of these larger companies doing this. More of these bigger players need to send a message to stop this childish crap of platform specific programming.

I vote Adobe

[Thelasko]

1. They have taken entirely too long to come out with 64-bit versions of their software.

2. They aren't very good at change. Basically all Adobe does now is buy other companies that have good software or market share. After the company is acquired they make few efforts to improve the software. If they make any changes it's to make it more bloated and riddled with advertisements.

Or maybe I'm just bitter because they don't have a 64-bit version of Flash and there is no Shockwave for Linux.

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:Use QT, like the rest of the world

[anarkhos]

Except that no Qt app in existence behaves like a Mac app, and this problem will only be exacerbated with their transition to Cocoa.

What DID Apple pledge at WWDC 2000?

[dpbsmith]

The thing is... and if anyone else was there and still has their notes I'd appreciate it if they'd confirm or deny this... I could swear that Apple pledged at WWDC 2000 that Carbon and Cocoa would be co-equal on Mac OS X.

I do not remember Apple saying that Carbon would be discontinued, and I do not remember their suggesting that there was any reason to move to Cocoa _other than its intrinsic merits_.

I realize that computer companies have a very bad track record of keeping any long-term commitments, and that a sophisticated developer should take whatever is said with a grain of salt, but my recollection was that Apple was very, very definite at the time.

Re:What DID Apple pledge at WWDC 2000?

[MrMacman2u]

I do not remember Apple saying that Carbon would be discontinued... *siiigh*

Carbon is not being discontinued. It just won't be 64-bit like Cocoa.

...and I do not remember their suggesting that there was any reason to move to Cocoa _other than its intrinsic merits_.

Apple has been pushing developers for more than 9 years to move away from Carbon and use the "shiny new" Cocoa. Drop by Apple's developer page sometimes, it's not hard to find then urging you to use Cocoa. (And they make their related Carbon stuff harder to find! lol!)

windows 64bit tradition

[sgt scrub]

It must be because Windows has had such a long and stable history of running on 64bit hardware.

http://www.gimp.org/macintosh/

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:windows 64bit tradition

[shutdown -p now]

XP 64-bit was pointless, and soon discontinued

What do you mean by "discontinued"? It is still being sold, and it receives the same updates as 32-bit XP. Of course, MS is pushing for Vista now, but it's the same deal for all XP versions, not just XP x64.

Pirates ahoy!

[AioKits]

Call me paranoid, but maybe they figure making it the 64bit version of it Vista only, there will be fewer pirated copies about. I know of few people who run the 64bit version of that OS and they're not really into photo editing. It does make their email download faster! So they keep telling me...

Re:What will happen?

[Raffaello]

Exactly. Adobe, along with all Mac OS developers were warned almost a decade ago - essentially a previous geological epoch in computer terms - that going forward they would have to move their apps from Carbon, the old OS 9 compatibility layer - to Cocoa, the new Mac OS X framework which has been the fully native Mac OS X framework since the developer previews of Mac OS X in the late 90s.

Adobe was busy focusing on the windows market and betting that Apple would go out of business so they put 0 effort into porting Photoshop to Cocoa - OOOPS!

Apple not only survived but thrived, so Adobe simply dug in their heels and assumed that Apple would keep Carbon around forever rather than risk losing Adobe. Instead, Apple simply built internal Cocoa replacements for all the Carbon software whose absence could threaten the platform:

Microsoft Internet Explorer -> Safari
Microsoft Outlook -> Mail and AddressBook
Microsoft Word -> Pages
Microsoft Excel -> Numbers
Microsoft PowerPoint -> Keynote
Adobe Photoshop -> Aperture

This 64bit issue is no one's fault except Adobe who have had nearly a decade's warning that they needed to move from Carbon to Cocoa.

Re:What will happen?

[mrchaotica]

Adobe does not feel like rewriting an entire program at a moments notice

What do you mean, "moment's notice?" Apple has been telling people to switch to Cocoa for years and years now, ever since 10.0 came out!

Re:What will happen?

[Anonymous Coward]

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.

Why not? Don't change the release date, just made the developers work extra hours, its not like they get OT anyway. Unless they're contractors in which case Adobe gets what they deserve.

1 GB is not gone to 'code sharing'

[Anonymous Coward]

Whatever that means. It's gone to devices that have their own memory. Video card is the best example. 32 bit can only address 4GB of memory space including the addressable memory on the video card. Remove a GB of RAM from a 4GB machine with a big video card and observe the available memory doesn't go down. MS rounds down on the amount of memory reported.

64 bit is certainly faster when it comes to working with large files or multiple processors (assuming the application is written for many processors which many 64 bit apps are) As an owner of a new DSLR popping off 8 35mb files a second this is a good thing not only for editing but for rushing through a series of images at high resolution looking for the best shot. Then you get into HDR photography where you are layering 7 or those files together and well.. more memory is a very good thing.

Re:1 GB is not gone to 'code sharing'

[joaommp]

Sorry, but I think you're incorrect. The OS can give the applications a virtual address space of 4GB as however it sees fit. Applications don't see the devices memory mapping zones.
Since the Pentium Pro that the x86 processors have extensions allowing them to actually use more than 4GB of physical memory independent of the virtual address space. They had a 36bit addressing scheme that would allow them to address up to 64GB of memory. One thing is the linear adressing of the physical memory in a flat addressing model (visible by the OS and in which there will be gaps for mapping devices and leaving some upper memory accessible only by remapping it), another thing is having a virtual address space. If you had 64GB of memory you could have all your applications scattered anywhere on those 64GB.
See http://en.wikipedia.org/wiki/Physical_Address_Extension/. The 32-bit applications always see their own 4GB virtual address space (that can be mapped as randomly as you can possibly imagine) independant of the physical resources. That first 1GB is actually reserved to maping code between the OS, DLL's, etc, allowing the application to call system services and shared libraries.

Re:1 GB is not gone to 'code sharing'

[Anonymous Coward]

I'm talking about addressable PHYSICAL memory by MS windows. You can dump plenty into the "virtual" space but the OS can only see 4GB of RAM at a time. Since a video card RAM claims some of that RAM space as it's own you that RAM from the OS/applications. Whats more the OS will lay claim to a good portion of physical memory for itself leaving even less for the applications. Sure you can have another 8 GB or more of HD swap space but the key is you a SWAPPING addressable RAM memory with stuff the OS can't use until it's pulled back into Physical RAM. The larger your HD pagefile is the larger your RAM virtual address table is as well.. eating it's own dedicated chunk of physical RAM. 64bit's speed boost comes from a larger PHYSICAL (RAM) address space and thus less HD swap access.

Re:1 GB is not gone to 'code sharing'

[joaommp]

no, that's not it. You can actually have 64GB of physical memory on a pentium pro. I'm not talking about swap. read the article

Re:1 GB is not gone to 'code sharing'

[IntlHarvester]

Doesn't really matter because Windows XP/Vista doesn't support it and even if they did, most 32-bit processor mainboards didn't support it either.

The "3GB" problem described by the AC you replied to was a real problem on real hardware.

Re:1 GB is not gone to 'code sharing'

[joaommp]

For what I could understand, but it may just be the language barrier here, I think the 3GB problem the AC mentioned I believe that applies to the virtual address space of applications that can only have 2-3GB for data because the remainder of the address space is reserved for code mapping... in real hardware, yes, but to the virtual address space.
Because when it comes to physical memory, AFAIK the NT kernel has since long been able to use PAE.

Re:1 GB is not gone to 'code sharing'

[IntlHarvester]

AC's problem is that older consumer hardware had a 32-bit MMU which meant that the device space was carved out of the 4GB limit. Install 4GB RAM in an Intel 945-based system for example and the OS will only see 3.0 to 3.5 GB.

NT does support PAE but only in the server versions, so that's commercially useless for Adobe.

No, blame Adobe

[kherr]

This is likely incorrect. Adobe is one of Apple's key development partners. Companies like Adobe and Microsoft get privileged developer information from Apple, always have. I'm sure Apple was alerting Adobe to the Carbon issue long before WWDC 2007.

Keep in mind Adobe's track record on software development for the Mac. They (along with Microsoft, shocking) were one of the last to deliver an Intel-native version of their premier software, over a year after Apple's switch to Intel. I don't think Adobe's that impressive of a development company, probably carrying around a lot of ugly legacy code that's mostly a cross-compile from Windows.

Re:No, blame Adobe

[LordNimon]

They (along with Microsoft, shocking) were one of the last to deliver an Intel-native version of their premier software, over a year after Apple's switch to Intel.

Adobe's bread-and-butter is professional graphic designers who predominantly use Macs, and usually old Macs. Their customers were probably telling them, "We don't have any plans to switch to Intel for another couple years anyway, so just make sure your stuff works on Rosetta." My wife is one such customer, and her primary machine is still a PowerMac from 2000.

Re:No, blame Adobe

[_|()|\|]

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

Actually, John Gruber claims 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.

Nope. 64-bit Vista only

[realmolo]

You *do* realize that 64-bit XP is an orphaned operating system, right? I don't expect that any forthcoming 64-bit applications from *any* developer/vendor are going to support 64-bit XP. Why would they bother? Hardly anyone uses it. 64-bit Vista has a VASTLY larger userbase, and it's officially supported by MS.

What about the "series of tubes" version?

[xactuary]

Not that I believe every newsflash I see, but didn't adobe announce recently that within some vague timeframe, future versions would be browser-based? How does that jibe with this new Windows-Only "feature"?

Business Driven Decision Making Screws Up Products

[Austerity Empowers]

News at 11. There's no shock here that if you let any corporation make decisions about the fate of technology, they'll make the wrong one. Here we have 2 that both made the wrong choice. Another caution about putting all our faith in Apple.

True 64 bit or WoW64?

[njhunter]

The article seems mostly to lament Mac stuff. But one has to be curious whether this 64 bit version of Photoshop is truly 64 bit or uses 64 bit emulation like AutoCAD 2008.

Re:True 64 bit or WoW64?

[Anonymous Coward]

But one has to be curious whether this 64 bit version of Photoshop is truly 64 bit or uses 64 bit emulation like AutoCAD 2008. You have misunderstand the purpose of WoW64, which lets older Win32 apps run on a Win64 OS. The only "emulation" that occurs is when you run an x86 win32 app on Itanium (Itanium's WoW64 has to emulate a 32bit x86 CPU, whereas WoW64 running on x64 just switches the CPU into x86 mode, when needed). The original WoW let 16bit Windows 3.1 apps run in a virtual DOS machine for NT 3.x, 4, 2000, and XP, but was removed from Vista.

Back to AutoCAD 2008. You are mistaken again: a native 64bit binary version exists. It might use WoW64 to run older VBA and .NET add-ins, but otherwise it's native 64bit. The 2009 version also has separate binary releases for Win32 and Win64.

Cheers,

JD

ob

[Anonymous Coward]

64 bits ought to be enough for anybody

-1, Wrong as of Leopard.

[ciroknight]

n/t.

Re:-1, Wrong as of Leopard.

[recoiledsnake]

-1, Wrong as of Leopard. Only wrong if you're under the influence of RDF and can't think for yourself. For the rest of us, the Leopard kernel is 32bit.

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.

OK

[Anonymous Coward]

Somebody sacrifice a (ugly) virgin

but first, we need to know where you live.

Adobe had no other choice

[courtarro]

When it comes to software development, companies prefer to make changes that affect the customer directly, and in the short term. The Ars article mentions that it would take a serious redistribution of resources to begin the port from Carbon to Cocoa, which means that feature development and stability improvements (things that the customer sees) would have slowed significantly. CS4 might come out with a few new features, but users would complain that it is basically a rehash of CS3 and there would be significant negative press. Arguments would intensify that Photoshop has hit a plateau, and future sales would be hurt.

All that would be the result of the forward-looking decision to port to Cocoa far before this point, and that decision would have had the potential to cause more problems for Adobe than they're seeing now by not having a Cocoa version ready. Today's news is bad press for Adobe, but it's not as bad as it could have been. In reality, people will get along with a 32-bit Mac version or the 64-bit Windows version instead. Since the problem of making a Cocoa port is now very customer-facing, the marketplace will likely be more forgiving of a feature stall over the next few years.

Um... Adobe just re-wrote CS3 from the ground up

[Toe, The]

Remember the enormous delay Adobe had in bringing CS3 to OS X? Their excuse for that was that they the Intel chipset was making them abandon their CodeWarrior-developed code and they had to start over from scratch.

So now they are saying that when they made the decision to start over from scratch, they chose the older, backward-compatible API instead of a forward-looking modern one? If their mumbling about the delay of CS3 were true, then there was no reason at all that they wouldn't have just moved to Cocoa right then.

Adobe needs to get their lies straight if they hope to be as awful of a company as Microsoft (something they seem to be striving for with increasing vigor).

Re:XP too...? (yawn)

[Anonymous Coward]

Yawn. "Downgrade to Vista" is an old meme. Did you get that memo?

Recently I've actually tried *using* it (as opposed to just complaining about it), and it turns out that Vista is actually a decent product once you get used to the silly "let's change things for the sake of change" issues like renaming all of the control panel items and attempting to hide "advanced" features. For example they added 3-4 clicks just to get to where you can change screen resolution, network adapters, and computer name/domain. I'm not talking about UAC -- the new "newbie friendly" layout sucks for people like me, but it turns out that you don't make those changes every day so it's not a huge issue.

Actually I've been using both Vista SP1 and Server 2008, and it was Server 2008 that really opened my eyes. Fyi: Vista SP1 and Server 2008 share the same version + point number. That means they're the same behind the curtains (same kernel at least). Server 2008 screams -- it's night and day faster than Sever 2003 on the same physical hardware. So it turns out that all of the perceived bloat in Vista is due to Aero. Just disable that, and you'll be golden. Or get Server 2008.

p.s. I'm going to have to go ahead and ask you to come in on Saturday.

Misleading title?

[penguin_dance]

When I read the title, "Adobe Photoshop CS4 Will Be 64-Bit For Windows Only" it sounded like it will ONLY run on 64-bit computers with Windows. Which sounds crazy that they would limit their market to 64-bit Windows Vista. But after you read the article and comments, it will be able to run on 32-bit computers also. There are 32-Bit macs, aren't there? (I realize the 64-bit is especially useful in all things graphic that take up a lot of memory.)

Perhaps a better title would have been, "64-Bit Macs Snubbed by Photoshop CS4"

I dunno...

[mutube]

This is pretty damning.

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

Adobe should use QT

[CrunchyPCB]

Adobe should port Photoshop to use Trolltech QT. They already use it in Photoshop Elements since 2003.
http://trolltech.com/company/newsroom/announcements/00000120/
http://trolltech.com/customers/allcustomers/adobe/

It also has the advantage of working on Windows and Linux with little or no changes.

Re:Adobe should use QT

[FunkyELF]

Interesting that they're using QT yet they don't release any native Linux binaries.
Shouldn't it be as easy as running qmake on a Linux box?

They should call it Photoshop C64.

[starfiend]

Adobe Photoshop CS4 Will Be 64-Bit For Windows Only I think they should call it Photoshop C64, to better make clear it is for 64-bit only.

Re:They should call it Photoshop C64.

[russlar]

I think they should call it Photoshop C64, to better make clear it is for 64-bit only. I think calling it "C64" would do nothing, except confuse a bunch of old-schoolers, and piss off everyone who's ever used a Commodore 64.

Re:They should call it Photoshop C64.

[TeknoHog]

Whoosh.

Re:Um... Adobe just re-wrote CS3 from the ground u

[Morky]

There was no CS3 delay, they just said they wouldn't patch CS2. Pretty impressive, really. Now if they had to tried to move to XCode and reprogram their entire application suite in Cocoa during one release cycle, that may have caused a delay. Adobe has been incredibly supportive of Apple's OS, platform, and development environment changes. This is all a non-issue. CS5 will be here in 2 - 2 1/2 years and Adobe will finally be fully OSX native and 64-bit. The number of pros that will need to use Windows for it's 64-bitness on Photoshop is really, really small.

Non free software is slow to the punch.

[twitter]

It's obvious there will be some benefit to removing a fundamental limit. Editing a movie that's larger than 4GB springs to mind and high definition cameras can make those quickly. Scientific users broke out of 32 bits long ago but home users could have used the same years ago.

What's funny is how long non free software systems are taking to get there. 64 bit computing is old hat in the free software world, arriving shortly after the first widely available 64 bit processors like DEC Alpha ten years ago. The only problem free software users have is with non free software like Adobe Flash, which is only released for i386. There are ways of running that but non free software is just a drag.

Re:Non free software is slow to the punch.

[joaommp]

OMG, this must have been twitter's least bashing and less far from the truth comment I've ever read!

sorry... I had to do it =P

Re:Non free software is slow to the punch.

[willyhill]

With the exception of the server space (which users hardly care about), your claims of superiority are irrelevant without a meaningful application base.

Re:What will happen?

[mc moss]

If you can use Aperture as a replacement for Photoshop, then you really didn't need photoshop in the first place.

Adobe...

[neowolf]

I generally loathe Adobe and I know the Art Department in my company is going to be pissed about this, but I have to admit they have a good reason for doing it.

Re:What will happen?

[neumayr]

Adobe Photoshop -> Aperture Heh. Not serious, are you?
Still, I agree with your point - it's far from "a moments notice", OSX has been around so long I imagine a very large part of current Mac users have never experienced MacOS Classic. (Lucky them.)

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.

Let me see if I understand correctly

[UnknowingFool]

Adobe is not releasing a 64 bit OS X version of Photoshop CS4. But they are going to release a 64 bit Windows version. Both platforms will get a 32 bit version.

Adobe says the issue lies with Apple stopping development of 64bit Carbon framework; but they have developed a 64bit Cocoa framework. Adobe has used Carbon previously and rewriting Photoshop from Carbon to Cocoa will take a lot of effort says Adobe. So they will skip CS4 but will have a 64bit version for CS5.

I don't know the scope of work required to migrate Photoshop from Carbon to Cocoa but it would seem that Adobe isn't going to meet the demands of most of their customers. I don't know the breakdown of Windows/OS X customers of Photoshop but I would think that there are fewer 64bit Windows customers than 64bit OS X customers. For Windows users, they have to run 64bit XP or 64bit Vista whereas OS X has been mostly 64bit since Tiger. I'm not sure the limitations on the 64bit but my understanding is that 64bit programs will run on Tiger. So a 64bit Windows version is going to have fewer customers than a 64bit OS X version.

Re:Let me see if I understand correctly

[ZachPruckowski]

Or Adobe customers with Intel Macs (and when CS4 comes out, that'll be most of their Mac base) will install and run Windows to do Photoshop stuff. The Mac advantage is that 64-bit is seamless (same drivers, same OS install), while Windows 64-bit requires buying a different version of Windows with different drivers. It's a lot of work to port from Carbon to Cocoa. They're moving from C++ -> Objective-C and linking against different libraries. Hopefully the move will result in better software (because Cocoa is a better framework than Carbon), but it's a difficult move.

64 bit apathy

[ThirdPrize]

how long have 64 bit machines been available now, 5 or 6 years? 64 bit OSs are only really now starting to become mainstream and thats only with Vista and Leopard. There just hasn't been the incentive for the average user to upgrade to one and so that has delayed the OSs and the software. It is only now when 4Gb is stabdard on a PC that people are starting to see it as a limitation, especially in the hight end market.

Re:64 bit apathy

[Fishbulb]

Try 16 (http://en.wikipedia.org/wiki/Alpha_chip#Model_history). Even Sun has had 64-bit chips and OS for 10 years now (http://en.wikipedia.org/wiki/Solaris_%28operating_system%29).

The only reason 64-bit isn't "mainstream" yet is due to Microsoft dragging its heels not wanting to bare its ass to world that its 32-bit codebase is a horrible mess and damn near impossible to move up to 64-bit (being that up to XP, there were still 16-bit tie-ins to their 32-bit architecture).

Re:64 bit apathy

[Anonymous Coward]

Ha! Microsoft has almost no pull in the hardware market, and could barely convince their customers to upgrade to 32-bit software. Hell, most of my clients (healthcare/financial industries) are still running Win2k. There's no way MS could somehow make people upgrade to 64-bit hardware.

If MS stopped making 32-bit editions and only supported 64-bit versions from now on, people would just pirate Vista and XP for the next decade.

dom

Odd...

[Mutiny32]

The one company that has the guff and will to push 64-bit exclusive apps that many people rely on has yet to release a 64-bit build for Linux (Flash). Why?

Re:What will happen?

[cyberjessy]

This 64bit issue is no one's fault except Adobe who have had nearly a decade's warning that they needed to move from Carbon to Cocoa.

Except that the first OS X version with true 64-bit support was unavailable until a few _months_ back.

As if all of PS needs to be 64bit

[cheekyboy]

Surely Adobe could make the GUI in carbon, but place the processing stuff in cocoa libs and have some interaction via ipc/tcp or something.... like a CS4-daemon or something.

Then again, why cannot apple just release carbon source code, then it could be ported to win32/linux, or is carbon really how win32 itunes is made? I did hear that QT for windows basically contains
90% of carbon apis in it as wrappers.

Here at my work...it won't matter

[greymond]

I work as a Marketing and Design manager and we are, for the most part, OS X exclusive. We do have a couple older windows machines we use for some web related items, but as far as print ready designs go and even websites we're all mac based. That said we don't have the budget to upgrade every year when the latest and greatest items come out. Instead we usually upgrade software about once every two to three years and our hardware every four years (though small upgrades like memory are evaluated each year)

Besides our budget limits, the other reason for this is that most of the printers we work with as well as publication companies follow a similar trend in their upgrade patterns. As it is right now we just finished migrating all of our offices over the last year from CS (a couple offices did have 2 already) to CS3. Depending on when CS4 comes out, we'll more than likely just wait until CS5 is released.

With that said if we run into an issue where we need to have the latest for some given reason chances are we'll require only InDesign or Illustrator upgrades as those are our main priorities. While photoshop seems to add in yet another ten ways to adjust the shadows/highlights of an image every version, it never seems to be high on our list of requirements.

This is why OSS is good.

[serviscope_minor]

OSS is often claimed to be the "idealists" choice as opposed ot the "pragmatists" choice. I suggest that idealism is simply pragmatism with an outlook to the future. And this is one of the problems with closed source software: it will come to bite you in the end. Adobe, relying on a closed source API have now been duly bitten. Customers who wanted 64 bit photoshop on OSX have now been bitten as well.

Adobe's to blame

[MacAttack7388]

Discussed more here: http://gregstechblog.blogspot.com/2008/04/bad-adobe.html Adobe shouldn't have been using the old API, Carbon. They should have switched to Cocoa when Mac OS X came out, over 7 years ago.

I'm hoping for a 64bit version of After effects

[BlueshiftVFX]

64 bit After Effects, then i can finally do away with all the frame buffer errors and memory full type errors, making High def and film go smoothly. Or at least see them less frequently. And as some people were talking about higher bit depths, which does have no bearing on the bits of the processor, it will be nicer to be able to access more frames at once while in 32float (thats 32bits per colour channel x at least 3) eats up more ram per frame.

Re:What will happen?

[Anonymous Coward]

Just how long do you think it will be before we see CS5? My guess is 5 years at the earliest. So not the end of the world? 5 years in computer time is an eon.

http://savage2.s2games.com/main.php

[GNUPublicLicense]

http://savage2.s2games.com/main.php ... game loaded with free linux 32 bits and linux 64 bits clients... But what is the relationship with that news?? Well adobe not able to provide photoshop on linux 32 bits and 64 bits? Ok their devs suck big time.

Apple called Adobe's bluff....

[HeavyDevelopment]

While in 2006 Apple had said that they were going to have Carbon 64bit support(as it is only 32bit currently), in 2007 Apple pulled that off the table and said that they would abandon moving Carbon over, thus forcing everyone to Cocoa (for 64bit). That left Adobe in a lurch because they were depending/betting that Apple was going to support Carbon 64bit. My thought is Apple decided that they weren't going to go to put a lot of effort into doing something that was primarily only for Adobe's benefit and supporting a dying API. Adobe is entirely to blame for this because they were too lazy/apathetic to start converting the millions of lines of code over to Cocoa years ago. What no one is pointing out is that this is only a concern to photographers and designers that deal with particularly large images (ie 2GB+) and use the Mac OS. While an important market niche for both Apple and Adobe, its still rather small. I for one will probably skip CS4 and wait for CS5, unless of course Adobe comes out with the "God" filter in PS that makes all your photos look like they were shot from heaven....then I'll buy it.

Re:What will happen?

[Anonymous Coward]

Your comparison was valid until you got to Photoshop.

Photoshop does not lead to Aperture. They are fundamentally different approaches to image editing that cannot replace each other. That's why Adobe responded to Aperture not with Photoshop but with Adobe Lightroom, which is quite analogous to Aperture.

Bottom line is that Apple currently has nothing close to a Photoshop competitor. They only have a Lightroom competitor, while Photoshop continues along unmolested.

Re:What will happen?

[zten]

I was subject to Mac OS 9 in school. Terrible, terrible garbage. It made me wonder how anyone could actually like that platform, given its utter failure at any sort of responsible multitasking.

What a huge dead-end for Apple!

[randolph]

I don't have time to learn another proprietary language. Neither does Adobe. What a mess!

This Wouldn't Have Anything To With iPhone/Flash..

[ausoleil]

If Adobe is developing a superior product for Apple's computer/OS competition, but not for the Mac, one has to wonder if this is a just wee little bit of payback for the iPhone/Flash Light drama from a few weeks back.

Sure seems like quid pro quo to me.

That will teach Apple to open Pandora's Box....

Re:What will happen?

[_|()|\|]

Apple simply built internal Cocoa replacements for all the Carbon software whose absence could threaten the platform

A more cynical view is that Apple leveraged its control of the O/S to gain a competitive advantage. The Ars article on which this thread is based is really a pretty balanced look at the situation. Saying that Adobe was warned, or that it bet on Apple going out of business, is neither fair nor balanced. If you look at similar applications, Adobe's handling of Photoshop is not unreasonable. Look at Maya, LightWave, or, for that matter, Final Cut Pro.

The chose the standard language

[randolph]

Apple Objective-C is a proprietary language. Developers who've been working for 20 years in C++ are not going to take a year off from productive work to learn a new language, especially since this is just Steve Jobs ego at work.

Re:The chose the standard language

[prockcore]

Don't forget that if they port photoshop to Cocoa (and thus to ObjC), then they'll have two *completely* separate code bases. One for windows and one for osx and they won't share any code what-so-ever.

Re:The chose the standard language

[tikram]

20 years in C++? It was standardized 10 years ago... I wouldn't think it was that heavily used before that.

Re:The chose the standard language

[seriesrover]

I remember first picking up on C++ in about 1991 using Borland C++...I even remember anxiously waiting for these things called Templates to be implemented.

Re:The chose the standard language

[Anonymous Coward]

Er, why exactly wouldn't it share any code? I've worked on Cocoa/Objective-C applications which shared the majority of the code with multiple other platforms. Objective-C can easily incorporate portable C/C++ code, and absolutely does not require you to throw away your cross-platform code. The stuff that becomes Objective-C is the stuff that won't be portable anyway.

Oh, but you're coming at this from a position of ignorance. Please forgive my compulsion to inject facts and experience into such an argument.

Blame?

[fm6]

I'm not a Mac person, but I do work for another computer system manufacturer, and from where I sit, Apple's behavior is neither unusual nor "secret just to be secret".

First of all, you can't make promises about unreleased products. The legal issues are mind-boggling. Right now I'm involved in releasing — well, I better not say, but if you've followed the x64 server news lately, you can probably guess what I'm talking about. I know what the release schedule is for this product and how firm it is. Our customers are clamoring for this information. If I let any of this info slip, I'd get fired and sued. And I'd deserve it, because I'd have seriously screwed over my employer, opening them up to a vaporware lawsuit.

If Apple promised Carbon-64 (is that radioactive?) this year, they were really stupid. But I doubt that. More likely what you're reading as promises were just statements that they were working on Carbon-64.

Nor is it particularly unusual for a company to suddenly abandon a project. Sometimes it becomes obvious after a project starts that the numbers just don't add up. It's particularly unsurprising in this case. Apple is basically competing with Microsoft. They have a fraction of MS's customers, fewer resources, and a much more complex product.

Until I looked on Wikipedia just now, I didn't realize how complex. OS/X supports five distinct, complete application programming interfaces. This number gets bigger if you count the 64-bit versions as separate APIs (and you should). If you have to scale back, support for a legacy API like Carbon is the logical place.

If you're looking for someone to blame, maybe Adobe is a better choice. To me, it seems really dumb for them to assume that Apple would continue to upgrade Carbon in tandem with Cocoa forever. Then again, the Mac version of Photoshop can't be a big profit center, and moving the product from Carbon to Cocoa has to be expensive. So it would be natural for them to avoid the change as long as they could.

If you're going to blame anybody, you should probably blame the economics of the computer marketplace. That's what limited the options for both Adobe and Apple.

Even if you were to blame Apple and/or Adobe, this is not exactly worth getting bent out of shape over. The number of users affected is tiny. When was the last time you edited a gigabit photo? Of course, the coolness factor of having all your apps 64-bit is huge. I guess reducing the CF for a Mac product is a major thing with for its more religious users. Me, I judge a product on how well it does the job.

Can't unload DLLs

[Myria]

Another problem that's probably sure to bite Adobe is that you cannot unload DLLs that contain Objective-C code. Once a DLL/dylib/bundle with Objective-C code is loaded, it is stuck until process termination. If a Carbon application has GUI code within DLLs that are dynamically loaded and unloaded, it will take a *lot* of re-engineering to fix it. 64-bit programs can't use the GUI without Objective-C.

Re:Can't unload DLLs

[bnenning]

As of 10.5 you can unload bundles.

The Linux community response

[Cctoide]

Following in Adobe's footsteps, the Linux community will tomorrow announce that future releases of yum will run only on 128 bit versions of Microsoft Windows 7.

OS X isn't 64-bit

[Anonymous Coward]

I'm afraid you're mistaken. The 64-bit version of XP came out in 2003 for Itanium and 2005 for x86-64. That means you could run fully 64-bit or 32-bit Windows apps at the same time for 3 years or more. Meanwhile, OS X has had no support for 64-bit GUI apps until Leopard. Prior to that only POSIX apps could be 64-bit. I don't even know of any major 64-bit OS X apps.

dom

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:Um... Adobe just re-wrote CS3 from the ground u

[Toe, The]

There was no CS3 delay, they just said they wouldn't patch CS2.

You're right, sorry about that. However they said they couldn't patch CS2 for Intel because they wrote it in CodeWarrior and had no clear path to Intel. That was why they had to start over in Xcode.

Now if they had to tried to move to XCode and reprogram their entire application suite in Cocoa during one release cycle, that may have caused a delay.

But they did have to reprogram the entire application. That's what they said, anyway. So why reprogram it in other than the most modern API? I'm not saying they're anti-Apple (though they seem to give that appearance), just that they seem to be making some really bone-headed decisions about how they program (or else they're simply not telling the truth). After all, their CodeWarrior excuse was pretty thin too... all it meant was that their codebase was becoming archaic and they weren't doing anything to keep it up to date.

32 more bits to suck at

[billcopc]

Perhaps I'm too cynical, but I don't think Adobe should even try to write 64-bit apps when they can barely manage to make a 32-bit app marginally stable.

CS3 was a big improvement over CS2 in terms of speed and reliability, but that's like saying light poop tastes better than dark poop. It's still crap.

This is a problem for a lot of software

[spitzak]

What people are failing to notice is that Cocoa is a "higher level" api than Carbon. That sounds good to a PHB, but in many cases it is worse.

It is an entire toolkit, similar to Qt, except it only runs on one platform. This is a serious impediment to anybody wanting to make software that runs on something other than that platform. The closest Linux equivalent would be to say that all software on Linux must use Motif, and that if you want to port to Windows or Mac you must emulate Motif.

"So write a wrapper for it to make a portable api". The problem is that it is vastly easier to write such a wrapper over a lower-level library, than to try to adapt two different high-level apis. This is why EVERY portable toolkit in existence uses Carbon and all programs using them are not going to have 64 bit osx versions for awhile. This includes Qt, incidentally!

Qt is probably going to be the first to solve it. But the solution is going to be by figuring out how to get Cocoa to make a "blank" window with no widgets and then drawing everything inside it. This may represent the waste of considerable overhead. My experience with NeXTStep indicates that a lot of required communication about the windows, such as what program they belong to, is intricately tied up with stuff that makes the window less "blank", and that trying to get a working low-level api that seems to be a native program is going to be a real pain to implement.

Re:This is a problem for a lot of software

[Sentry21]

You can see Ars Technica's writeup on the Cocoa port of QT4 for more information on how they've actually done so far.

The Cocoa API is also being unofficially open-source ported to other platforms (most actively Windows platforms) through the intriguing Cocotron project. It's still a work-in-progress, mind you.

Every portable API uses Carbon, not because of high-level vs. low-level, but because Carbon can be easily integrated with existing C/C++ code, whereas Cocoa requires a little more effort. Carbon provides what a lot of Mac users consider a sub-standard experience, and worse integration, but for most people porting their apps to Mac, they rarely know or care.

In OS X, there's not a lot of 'communication' that needs to be done to make the window 'less blank', though I'm not sure exactly what that means. You can put together a UI in Interface Builder, put your code into XCode and add whatever the Mac port needs, compile it together, and off you go.

You can write most of your app in C++, write the GUI-management code in Obj-C (or Obj-C++), and then glue it all together with Obj-C++.

Re:This is a problem for a lot of software

[pato101]

The closest Linux equivalent would be to say that all software on Linux must use Motif, and that if you want to port to Windows or Mac you must emulate Motif. Close, but not exact. One can use Motif in windows if you install a proper X-server (e.g. cygwin) and compile there either Lesstif or OpenMotif (the last one is illegal -since Windows is not an open operating system but it is OK at Mac-OSX- but I guess you can get a license from the OpenGroup; the first one is already available under cygwin but its no 100% replacement for Motif yet).
Whereas your comment is insightful and your comparison to the eldest Motif is appropriate, it is funny that even in such case there exist a way to make a Motif program run inside a windows box (besides the obvious vmware way).

Re:This is a problem for a lot of software

[spitzak]

There is also OpenStep or GnuStep or whatever it is called. Seems like Cocotron should get together with them, I searched but see no mention of it on their web site. They should at least explain how they are different.

I'm not sure what problems will be run into in making a "blank" window. I suspect it will be better than NeXTStep because Apple had to support the Carbon api which required such an interface at a low level.

Typical problems I ran into in NeXTStep was the inability to make a window that you could cut & paste to without also making an associated floating menu.

Re:This is a problem for a lot of software

[Ahruman]

The way to get a "blank" window in Cocoa is:
NSWindow *window = [[NSWindow alloc] initWithContentRect:someRectangle styleMask:someFlags backing:NSBackingStoreBuffered defer:NO];

If you want to add a button to it, that's:
NSButton *button = [[NSButton alloc] initWithFrame:someOtherRectangle];
[[window contentView] addSubview:button];
[button release];

It's a bit verbose, because it's *gasp* the low-level way of doing things. The mechanisms used to implement the high-level approach are generally exposed. The only difficulty is learning a small amount of syntax and a large amount of framework, but you get the latter on any new platform.

Objective-C is much simpler than C++

[mbessey]

C++ is this massive, complex language. It's not at all unusual to take YEARS to get very proficient in C++.

By comparison, Objective-C is much simpler. Since all message dispatching is dynamic, you don't have the virtual/non-virtual distinction to deal with, there's only one "kind" of casting, there's no operator overloading, and no use of Templates to specialize collections for a particular type (collections are all heterogenous).

If you're targeting 64-bit exclusively, you can also count on all of the Objective-C 2.0 features being there, like garbage collection, Properties, Fast Enumeration, and non-fragile member access.

Re:Objective-C is much simpler than C++

[LWATCDR]

Objective C sounds very nice but the lack of bindings is the problem for me. Of course then you have the problem of thinking between Objective-C and C++. I don't know how big of a problem it would be but a project I an close to ran into issues thunking between STL strings and MFC strings. It caused a huge performance hit in part of the program. Of course MFC is a nightmare but it was what the program used when it was written and now we are trying to move to STL.

Re:Objective-C is much simpler than C++

[pato101]

I don't really know Objective-C, but if you know C, you can get incrementally improving in your knowledge of C++.
C++ is massive, but one can use a subset that full fills her needs.

So if this signals Carbon's imminent demise...

[PCM2]

...does this mean that Apple finally plans to rewrite the Finder in Cocoa?

Re:What will happen?

[vought]

Nor is Aperture Cocoa.

However, with the plugin architecture for local adjustments and other Photoshop-like features, Aperture may be a serviceable replacement for most functions that digital Photographers need.

It still won't work for me, due to the lack of a way to do custom difference of gaussian sharpening automation, but hey - for 90% of customers, LIghtroom and Aperture will do what they need it to.

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.

Cocoa affects users directly!

[Anonymous Coward]

Has Adobe made any significant changes to their flagship products in the past 5 years? I have Photoshp 7 and Illustrator 10, and whenever I happen by an Apple store, I go play with the newer versions, and all I can say is "yup, you can still edit pixels and vectors".

In fact, the biggest problem I've had with either is that they're hard to install on newer Macs, but you know what? The fact that Adobe was dragging their feet on OS X compatibility in 2002 does not inspire me to buy new versions of Adobe products which are dragging their feet on 10.5 and Intel and 64-bit compatibility in 2008. I'm going to go buy something like Pixelmator, which is cheap, fast, and runs great on a new Mac. (I'm not a professional photographer, so I can afford to say "screw Adobe" when I find their products suck.)

The biggest change I've heard about Adobe products (since they moved to their confusing "CS-" versioning system) is that they added product activation. (Wasn't that negative press?) Gee, thanks, make me feel like a criminal. This is progress? Photoshop and Illustrator *have* hit a plateau.

Dear Adobe, release an Intel 64-bit Cocoa version of Illustrator and Photoshop with no product activation, and I'll leave work to go buy new copies *today*. Keep releasing "hey new useless 3d feature" with product activation and trying to tease Cocoa into making a usable GUI and I'll keep ignoring you. If you're wondering why everybody's clinging to their old verions of your software, it's your own damn fault.

This is the difference between Adobe and Apple. Apple had a hit product with the iPod mini, what did they do? Kill it, and replace it with the iPod nano, which offered no real improvements, but went on to be an even bigger success. Adobe is becoming irrelevant because they don't have the balls to say "we're going to do the right thing".

yum on 128-bit Windows 7 only?

[Jesus_666]

As a Gentoo user I'm perfectly fine with that.

Grammar Police Here!

[Anonymous Coward]

Apple "HAS" been saying. Not "have." Apple is singular, not plural. Why do people on Slashdot and Digg make this mistake so often? Anyone have any insight?

Re:Grammar Police Here!

[Anonymous Coward]

in Britain, companies are plural

Re:What will happen?

[IntlHarvester]

> Adobe simply dug in their heels and assumed that Apple would keep Carbon around forever

Adobe didn't assume this you mactards, Apple told them so.

Re:What will happen?

[ultramk]

Wow, you made my comment for me, thanks.

Re:Um... Adobe just re-wrote CS3 from the ground u

[catmistake]

they had to start over from scratch

They should have, but there's proof that they did not. Mouse over the startup splash screen on Photoshop CS3, and you will see the old pre-OS X wristwatch. This means there is ancient code in there being translated via Carbon. Adobe is the new Microsoft, therefore, they will avoid creating anything new at all costs, even if that means abondoning the platform that put them on the map, as they have shown they are willing to do in the past.

Wikipedia says 1979 (sorta)

[Toe, The]

http://en.wikipedia.org/wiki/C%2B%2B says it was developed in 1979, and named C++ in 1983.

However, the standard wasn't ratified until... 10 years ago, 1998. But I don't think people usually wait for ratification to begin using something.

802.11n is ratified yet and I'm using it right now. :)

Re:Um... Adobe just re-wrote CS3 from the ground u

[Toe, The]

Yeah, I see it. Was that icon totally removed from OS X? I can recall seeing that icon more recently than my move to OS X... but I can't guarantee that those occasions haven't all been with Adobe software.

Wasn't the Classic version of Photoshop written in some sort of BASIC?

Thank you Adobe!

[John Pfeiffer]

Last year, I was scanning and cleaning up some old (1800s) maps of Vermont for prints... My god... 1200dpi scans of large maps? I can't tell you how many times I caused CS3 to UTTERLY SELF DESTRUCT...and I think it actually burned up a pair of 1gb sticks of DDR2... My new machine has 8gb, so I can definitely get crap like that done easier, and I can actually DO other stuff at the same time... But it's still not difficult to reach the 32-bit memory limit D:

Could have started 64bit OS X, too

[weston]

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

To some extent, this is true of OS X, too -- if Adobe had started in on a Cocoa port anytime in the last five years, 64 bit support wouldn't be the issue it appears to be becoming now. I agree Apple plays a part in the problem, given that they said they'd offer full 64 bit support in Carbon, but it's also been clear for a long while now that long-term, Cocoa was the future.

I'm also a little puzzled. If I read correctly, it's only an issue for the UI -- partial 64 bit support, possibly including RAM addressing, will still be available for Carbon. Performance gains are really most likely to come there, so it's not clear to me exactly what the trouble here is.

Re:Um... Adobe just re-wrote CS3 from the ground u

[Anonymous Coward]

> Remember the enormous delay Adobe had in bringing CS3 to OS X? Their excuse for that was that they the Intel chipset was making them abandon their CodeWarrior-developed code and they had to start over from scratch.

That wasn't an "excuse", it was a fact. CodeWarrior did not support Intel, period. Sheesh...

> So now they are saying that when they made the decision to start over from scratch, they chose the older, backward-compatible API instead of a forward-looking modern one? If their mumbling about the delay of CS3 were true, then there was no reason at all that they wouldn't have just moved to Cocoa right then.

Adobe NEVER "started over from scratch", it modified their existing C++ code to build on Intel (and PPC) under Xcode/gcc. It was not a trivial job, but it fell far short of "starting over". Moving to Cocoa WOULD require starting over, because COCOA REQUIRES A DIFFERENT PROGRAMMING LANGUAGE.

Clear enough for ya?

Ummmm

[Sycraft-fu]

"Also, Adobe has to have a 64 bit version for Windows, because Windows comes in 64- and 32- bit versions, but OS X has the same support for both 64- and 32- bit in the same OS..."

This is just wrong. Windows 64-bit runs 32-bit apps just fine. There's not even a measurable performance penalty. So you can release 32-bit only apps, and support both just fine. In fact, probably in part because the support is so good, most companies are still doing that. 32-bit Windows can't run 64-bit apps, but 64-bit Windows runs 32-bit apps just fine. So Adobe doesn't need to release a 64-bit Windows version. Photoshop 7.0 still runs fine on 64-bit Windows, I use it at work since that's what we have a license for and my usage is extremely simple and thus doesn't need an upgrade.

MacOS will be the same way. The 64-bit MacOS will have no problems running 32-bit apps (or at least it'd better not) but old versions of MacOS that are 32-bit only will not be able to run new 64-bit apps.

If you want to run a 64-bit app, you must be running a 64-bit OS. To run a 64-bit OS, you must have hardware that supports 64-bit mode (called long mode in the x86 case).

Re:What will happen?

[Christopher Rogers]

I think he meant "Nor is Aperture Photoshop."

CARBON CAN NOT BE PORTED TO 64 BIT

[tlambert]

CARBON CAN NOT BE PORTED TO 64 BIT

It stores 32 bit values in the file ID database; how the hell are you supposed to have 64 bit Carbon applications interoperate with 32 bit legacy applications that are passing around 64 bit values and truncating them down to 32? How are you supposed to maintain binary compatibility with 32 bit applications that have on disk and in-resource values that are expected to be laid out a specific way?

This was a technical decision, and it was the only possible one that could have been made; those structures and data contents were never written with 64 bit in mind. Anyone who is complaining about this obviously understands nothing about the Carbon internals.

-- Terry

Re:CARBON CAN NOT BE PORTED TO 64 BIT

[antifoidulus]

Then why did Apple promise it? I don't disagree with the decision per se, I just think it was very poor form to make it then rescind it right before Leopard was released.

Re:CARBON CAN NOT BE PORTED TO 64 BIT

[tlambert]

It was never promised by engineers. I have no idea who you were talking to. Can you point to a URL where there was a written statement that said it was promised?

-- Terry

Re:CARBON CAN NOT BE PORTED TO 64 BIT

[Anonymous Coward]

Find the 2006 WWDC schedule.

Adobe still giving nothing to Linux users!

[Helldesk Hound]

64bits for Micro$oft Windows, 32bits for AppleCorp, but still Adobe has released no version of Photoshop/CS for users of the widely supported Linux OS that was fully 64bit when Vi$ta/Longhorn was merely a twinkle in Bill Gates' eye.

Why the heck why not!!

Actual linguist here!

[Anonymous Coward]

You're an idiot, you know nothing about grammar, and you have no business telling people what's a "mistake."

Subject/verb agreement often works off the semantics of the subject instead of the inflectional or syntactic form of the noun; take a sentence like Ham and eggs is my favorite breakfast. Names of companies can be construed to refer either to the company itself or to the people who make up the company; it is no surprise that they often trigger either singular or plural agreement on the verb.

As somebody else remarks, this is more common in Britain, but it's certainly not uncommon in the USA, though.

Um, no.

[Anonymous Coward]

Objective C works with C and C++. This means that the core of your application can be written in portable C and/or C++, with only the OS X UI bits in ObjC. Assuming your app is built cleanly to separate the UI from the core, architecturally this is really not much different than writing any other cross-platform app, since the UI bits need to be different for each platform anyway.

Oh the irony

[Godji]

So Apple won't get 64-bit Photoshop, while Vista will. Then, at some point of time, wine will be good enough to run that on Linux. So in the end, the number one "creativity application" that has always belonged in the Apple world will run on Linux and not run on Mac!

How could is that?! :)

Yes, I know. They have Parallels, and Boot Camp, and what not. But but... just imagine the look on a Mac fanboi's face. Priceless.

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.

Is Adobe on Drugs?

[Douglas Goodall]

I recently discovered that Adobe has dropped the ball on their support for the Apple platform. This is not about 16/32/64 bit issues. It is about support for case sensitive filenames.

The Photoshop Elements, and Creative Suite are both unable to install on an Apple with an extended, journaled, case-sensitive, file system.

I formatted by MacBook with case-sensitive filenames because I am a software engineer and I work with open source software. As you may know, when you untar a source archive, the extraction fails if the case sensitive file names collide. This open source software comes primarily from the Unix world where we have had case sensitivity for many years.

It is my opinion that if Adobe wants to have an Apple version of their software, they need to support the target environment. Since Mac OS X, the exctended, journaled, case-sensitive format is the best option because the journaled filesystem is hardened, and the case sensitive file system retains the most basic file attribute, it's name.

I have no statistics about how many people use the case-sensitive format, but I assume it is non trivial. Having Unix unde the hood was a major upgrade for the platform and has been responsible for many people switching there.

Again, when I write software for a platform, I bother to learn about the environment, and I do what it takes to support the target. If a client retained me to write software for a platform, I would be expected to have the software operate within the specifications and constraints of the target environment. It does not say on the Adobe requirements page, "Must be installed on a non-case-sensitive system drive. As far as I am concerned, Adobe has dropped the ball big time on this one, and I don't buy their excuses, or software in this case. It is a kick in the ass of the creatives to suggest they should wipe out their hard drives and reformat for one vendors application. I have a huge amount of licensed software loaded and it would takes days to reconfigure my notebook. I AM NOT WILLING TO BUY A SEPARATE COMPUTER JUST TO RUN PHOTSHOP.

Adobe can kiss my ass.

Re:Is this the end of carbon based life forms?

[Douglas Goodall]

I am a developer and have been porting to Mac OS X since Panther. I looked at the Carbon/Cocoa question and it was clear even then that carbon was there for legacy support of existing applications and that new software design work would benefit from being Cocoa oriented. I seem to remember something like if you wanted Aqua, you had to go Cocoa. Having just moved my development to the Mac, I had to decide learn Carbon and Cocoa for my new App, of learn Cocoa. It seems to me that focusing on the roadmap to the future is the efficient way to go when you have limited resources.

Re:What will happen?

[NaugaHunter]

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.

... yet.

Re:What will happen?

[Skuld-Chan]

This 64bit issue is no one's fault except Adobe who have had nearly a decade's warning that they needed to move from Carbon to Cocoa.

You make it sound like software development is so simple. Especially when everything on the Mac is a moving target. They change API's every patch and every OS version. I know in my own Mac development we spend most of our time QA'ing the existing code against every little thing Apple does to OSX. Maintaining code for Photoshop on X86, Intel 64 and 32 bit versions has to be a daunting task. I'll bet the spent most of this time this last couple years porting the product from code warrior to xcode - and I've heard from friends close to Adobe that they had a lot of problems with xcode handling such a large project. Little crap like that can severely delay development of a product feature on a platform.

Ultimately the user doesn't care - after all the OS is supposed to be transparent - and Apple certianly didn't make it easy on developers.

The fact that everyone is so pissed off at Adobe about this move shows they care deeply about the product though :).

Also - Aperature is no Photoshop killer - or even replacement.

64bit Windows PCs are cheaper than CS3

[cheekyboy]

For crying out loud.

Is any company that cheap that they cannot afford a $500 PC to run PS on?

Even home made $500 PCs 4gig ram + cheap MB + core2 2.6 is going to run damn fast today for under $500.

So realy, adobe should up the price of CS4 by $500, and include a free PC with it. Call it a complete editing workstation solution for $2000.

not buying it

[Scudsucker]

How does a promise made in 2006 and broken in 2007 explain the previous 9 years of footdragging, from 1997-2006?

not buying it

[Scudsucker]

How does a promise made in 2006 and broken in 2007 explain the previous 9 years of footdragging, from 1997 to 2006?

Re:What will happen?

[Scudsucker]

You make development sound so hard, as if Apple randomly changes API's for shits and giggles so developers have to keep rewriting code. The Cocoa app you write in 2002 might not be able to use CoreImage, but it should still work just fine.

Objective-C

[DragonHawk]

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. I know basically nothing about Objective-C, but I was curious, so I went searching. I can find no information on any standardization of Objective-C. And this FAQ claims there is no such standard, that the only references are vendor implementations. That makes it as "open" as Visual Basic (Microsoft) or Object Pascal (Borland). In other words, not very.

Am I wrong?

Re:Objective-C

[danaris]

Mmm, not exactly wrong—not in a quantifiable sense, anyway. However, Objective-C was around long before Apple took it up as the language of choice for Cocoa, and is also used for GNUstep and other OpenStep-derived environments. Apple didn't develop Objective-C and doesn't control it in the same way that Microsoft developed and controls VB and the .NET languages. I don't know enough about Object Pascal to comment on the comparison to it, I'm afraid.

But, as I said, it is not a "proprietary language", and it is certainly not "Apple Objective-C".

Dan Aris

This is the second strike against Apple

[Anonymous Coward]

This rather plainly shows that Adobe does not view the Mac platform as the core of their business in the future. Sure, they will crank out an app for Macs when it is convenient for them and as long as they can make some money off of it, but it is now clear that the top end professionals who buy whatever hardware saves them money because they have a photoshop guy running stuff all day for them (such as David Muench) will be moving to the platform that works for them. The additional processing power of a 64 bit system is just too useful to pass up when processing large files. (E.G. drum scans of medium format film.)

Others such as George Lepp (who has been writing for some time that the choice of platform for image processing is not that big a deal anymore) and others who use the Canon top of the line cameras (or Nikon full frame D3s, for example) need the processing power.

I foresee that they will not be using Apple products that much longer. They are not attached to a name. Whatever works best for them is what they choose.

This is not good news for Apple.

Re:Um... Adobe just re-wrote CS3 from the ground u

[jtranber]

Remember the enormous delay Adobe had in bringing CS3 to OS X? Not really, since the port to OS X happened for Photoshop 7.

Objective-C does appear to be owned by Apple

[DragonHawk]

Objective-C was around long before Apple took it up as the language of choice for Cocoa, and is also used for GNUstep and other OpenStep-derived environments. Well, now, I don't know much about OC, but I do know that NeXT was Steve Jobs's baby -- Apple Version 2.0. GNUstep is just a clone of NeXTSTEP. So pointing to them as examples of how OC isn't an Apple-only thing does more to suggest that OC is indeed an Apple-only thing.

And I just found this Wikipedia article, which claims that NeXT Inc. acquired the rights to OC from its original owner. And Apple, of course, has acquired NeXT.

And, hmmm, yes, the USPTO confirms Apple owns the trademark on Objective-C. So legally speaking, Apple does indeed own OC.

Do you have any sources to counter the information I'm finding?

Re:Um... Adobe just re-wrote CS3 from the ground u

[anarkhos]

What exactly makes Cocoa a forward-looking API?

Please don't answer if you're not a Mac developer, because in that case you opinion doesn't matter.