He's a quick summary for people who can't be bothered reading the long and boring article: It doesn't matter for most people.
People who care are: those who want photoshop to use more than 4GB of memory (keep waiting guys, should be here in a couple of years) and people who run memory hungry server applications.
It's a technicality that makes little impact on most things right now, especially desktop users.
Hmm, I don't think that is going to be the case for end users; as RIA start to rise, so will the grunt to run complex javascript/actionscript/etc will rise with it. Believe me, provide a programmer with more power, and they'll find a way to not only utilise it but complain there isn't enough.
As for Photoshop and the lack of 64bit, it actually tells me that they're very poor programmers at Adobe. If they wrote their application properly, then their back end and front end shouldn't be so reliant on each other that a re-write is required - it would be just a matter of reconstructing a new front end in Cocoa. Yes, it would take a while, but it would still allow them to maintain and port the back end to 64bit carbon, and use Cocoa 64bit for the front end (as mentioned in the article that Carbon/Cocoa code can be mixed and matched).
I hope, however, they do something about h264 encoding, its terrible that something like x264 can encode faster and produce better results than a commercial product.
He's a quick summary for people who can't be bothered reading the long and boring article: It doesn't matter for most people.
People who care are: those who want photoshop to use more than 4GB of memory (keep waiting guys, should be here in a couple of years) and people who run memory hungry server applications.
It's a technicality that makes little impact on most things right now, especially desktop users.
Quote:
Originally Posted by Foo2
The most important contributor to the speed of Snow Leopard is barely mentioned!
Most apps don't need more than the ~3 GB addressable memory that's available with the ancient X86 architecture. In fact, on most microarchitectures (e.g., Alpha, UltraSPARC, G5), apps typically run slower if compiled for 64-bits, because some data elements become twice the size (64-bit instead of 32-bit).
The speed of Snow Leopard will come from moving apps and the OS to the X64 instruction set, which provides for twice as many GPRs. Nearly every application will benefit from more GPRs--and benefit more than the speed hit that's incurred by using larger data elements. Other, more modern microarchitectures don't provide more GPRs just because an app is compiled for 64-bits. This is only a feature of the ancient X86.
Amazingly, very few apps for Mac OS X are 64-bit. Chess is one of them, presumably because it uses a lot of CPU relative to what's needed to drive the UI. Perhaps someone here knows whether the GUI part of Mac OS X, 64-bit Cocoa, under Leopard 10.5 is for some reason slower than the 32-bit version and that's why we don't see more 64-bit GUI apps yet? Or is it just because building, testing, bundling and distributing yet another binary isn't worth it to the software manufacturers?
(By the way, later PowerMacs could address 16 GB of physical memory, not just 8 GB.)
I think the convention assumption is that applications must be 64bit to take advantage. If one has a look at the architecture documentation in reference to the original hammer/amd64 design - the whole idea was that you could recompile 32bit applications running on a 64bit operating system and access the new registers. 32bit OS on amd64 was in compatibility mode, 32bit recompiled with the amd64 switch on a 64bit operating system meant that it was running in long-mode, which enabled it to access a wide variety of features by the processor running in native (long-mode).
I'm sure there is the original PDF still out there, it goes into great detail about how 32bit and 64bit applications both benefit merely from a recompile with the amd64 switch, even if they aren't written from the ground up to be 64bit.
I've been looking for one, but none of them offer online classes.
On a more serious note though; I remember seeing this 'internet addiction' BS that was going around - the only reason why there isn't 'television addiction' is because apparently it is socially acceptable to vegetate in front of a one-way device for hours on end versus using a computer that requires mental agility. The double standards in society is amazing imho.
Summary: despite its name the Core Duo processor was not based on the "Core" microarchitecture - it was actually just a fairly minor evolution of the Pentium-M, itself based on a 32 bit microarchitecture called "P6". Core 2 processors are based on the "Core" microarchitecture, which brought many changes, including "64 bit-ness".
Not really. Developers have been told repeatedly that the future is Cocoa if it wasn't obvious already.
Apple's given a lot of mixed messages on the relative weighting of Cocoa and Carbon. While I agree with you that Apple's made it clearer in the last few years, there was little reason to suspect in mid-2007 that Apple would drop 64-bit Carbon, especially after demoing and releasing it.
I didn't catch it in the article, but will 10.6 run on a Core Duo system? Or is Snow Leopard going to drop support for 32bit systems entirely? Forgive my ignorance... I'm not really up on this stuff so I need the experts to dumb it down a shade.
Amen to that. There still hasn't been any real confirmation that 10.6 will be intel only, just speculation.
Logic Audio. Big sample libraries are multi gig these days. I'd kill for a 64 bit version of the app, there have been 64 bit audio apps on the windows side for a couple years now, and us mac users are left out in the cold (Logic maxes out about 2.8 gigs of memory) while they can load up as much ram as they can afford to buy.
And isn't photoshop one where it could make a difference?
Sadly, right now Apple IS lagging behind windows in terms of 64 bit apps that are available. Of course it would be great to see APPLE release one of their own apps as 64 bit, but they seem to find doing it as difficult as everyone else.
So that's two applications (I already mentioned PS), used my a small minority of professional users, and only some of those have come up against the limits.
As I said, this doesn't really mean much for most people, even if it is important to get it done. It's a meaningless technicality and nothing to get excited about unless you're a nerd who wants to allocate more than 4G of memory for some reason.
Hmm, I don't think that is going to be the case for end users; as RIA start to rise, so will the grunt to run complex javascript/actionscript/etc will rise with it. Believe me, provide a programmer with more power, and they'll find a way to not only utilise it but complain there isn't enough.
As for Photoshop and the lack of 64bit, it actually tells me that they're very poor programmers at Adobe. If they wrote their application properly, then their back end and front end shouldn't be so reliant on each other that a re-write is required - it would be just a matter of reconstructing a new front end in Cocoa. Yes, it would take a while, but it would still allow them to maintain and port the back end to 64bit carbon, and use Cocoa 64bit for the front end (as mentioned in the article that Carbon/Cocoa code can be mixed and matched).
I hope, however, they do something about h264 encoding, its terrible that something like x264 can encode faster and produce better results than a commercial product.
Are you seriously saying that people need more than 4G to run Javascript programs? I hope I never see the day. And you seem to be making a case for software bloat. I predict Microsoft Word will be the first program that requires 64 bit to launch.
Adobe programmers are not bad programers and it's just not that simple. It's not just about the front end, there are more APIs than that involved. Apple is the guilty party for misleading developers.
I think the convention assumption is that applications must be 64bit to take advantage. If one has a look at the architecture documentation in reference to the original hammer/amd64 design - the whole idea was that you could recompile 32bit applications running on a 64bit operating system and access the new registers. 32bit OS on amd64 was in compatibility mode, 32bit recompiled with the amd64 switch on a 64bit operating system meant that it was running in long-mode, which enabled it to access a wide variety of features by the processor running in native (long-mode).
I'm sure there is the original PDF still out there, it goes into great detail about how 32bit and 64bit applications both benefit merely from a recompile with the amd64 switch, even if they aren't written from the ground up to be 64bit.
That's not going to make a whole lot of difference to the speed of the code and is not the point of 64 bit at all. Intel CPUs use register renaming and implements more than 8 registers in the CPU. Any advantage would spring from the compiler doing a much better job compiling given the extra registers, which is questionable.
New Hampshire has mountains? You mean geological pimples, don't you?
Well I grew up thinking we had mountains in Scotland so The White Mountains in NH being twice the size of those seem pretty big to me I am guessing you are in Tibet?
Apple's given a lot of mixed messages on the relative weighting of Cocoa and Carbon. While I agree with you that Apple's made it clearer in the last few years, there was little reason to suspect in mid-2007 that Apple would drop 64-bit Carbon, especially after demoing and releasing it.
Just by looking at the direction Apple apps were taking for their UI I'd suggest it's been obvious for a long time. Carbon UIs stand out like a sore thumb.
I think the problem is Adobe's cross platform UI library and also the old Macromedia crap they've inherited - carbon and Javascript based! Merging all that together and stepping up to Cocoa style UI guidelines and cross platform is going to be some job.
Not really. Developers have been told repeatedly that the future is Cocoa if it wasn't obvious already.
I don't think it was so, really. Non-Cocoa code is alive, growing, and supplying functionality to Cocoa. Also, Apple directed everyone to adopt new Carbon UI parts to be 64bit-able and gain certain new UI features.
A year later, with these Carbon UI parts nearing completion, and some software companies carrying app prototypes to test, Apple cancelled them and left Adobe, Trolltech, AutoDesk and others facing having to redo their apps' UIs on a non-multiplatform-friendly biggie conversion project-unproven API (where is, say, Cocoa FCP?) and with an unsatisfying IDE to work with.
We could say Apple did it's real Cocoa statement then. But I don't think that was good news at all for multiplatform programmers and OS X as a big players multimedia platform.
When Apple unveiled Carbon and Cocoa at WWDC, the message was loud and clear: Cocoa for new apps, Carbon for legacy code *only*, move to Cocoa as soon as you can. I was there. This was the constant, consistent message.
And what happened? All the devs who screamed bloody murder about Rhapsody, and threw a fit until they got Carbon *STILL* weren't happy, and continued to scream bloody murder. So Apple backed off the intensity of the message.
They went so far as to continue developing Carbon, spending time and resources that could have been used to move the platform ahead, just to appease the legacy devs. At that time, the legacy devs were a significant portion of the dev community.
Now, the message has been received by pretty much everyone except Adobe, Microsoft, and Eclipse. (Although oddly, some of Adobe's engineers are coming to the rescue of Eclipse by porting SWT to Cocoa for them...) Further, they aren't quite as critical to the success of the Mac as they used to be. Apple can push back a bit.
The yanking of 64-bit Carbon at the last minute was kind of assholish, IMO, but the move to 64-bit was, from a technical POV, the right time to drop as much legacy cruft as possible. Who was going to benefit from 64-bit Carbon, really? Adobe and Microsoft. That's pretty much it. This was one rare case where technical reasoning overrode inter-company politics.
To us who have been around a long time, the message has *always* been: Cocoa is the future, Carbon is a stopgap. The only variance was how loudly that drum was banged.
snafu: care to explain how Cocoa is any worse for cross-platform production than Carbon? They're both proprietary Mac-only APIs, they both can call C and C++...
As for Photoshop and the lack of 64bit, it actually tells me that they're very poor programmers at Adobe. If they wrote their application properly, then their back end and front end shouldn't be so reliant on each other that a re-write is required - it would be just a matter of reconstructing a new front end in Cocoa. Yes, it would take a while, but it would still allow them to maintain and port the back end to 64bit carbon, and use Cocoa 64bit for the front end (as mentioned in the article that Carbon/Cocoa code can be mixed and matched).
You really think that even if they only had to rewrite the front end of Photoshop, that still wouldn't be an absolutely enormous job.
And since Apple has showed no signs of shipping 64 bit versions of any of their apps, wouldn't you say that that would make them "very poor programmers" as well?
Quote:
Originally Posted by merdhead
So that's two applications (I already mentioned PS), used my a small minority of professional users, and only some of those have come up against the limits.
As I said, this doesn't really mean much for most people, even if it is important to get it done. It's a meaningless technicality and nothing to get excited about unless you're a nerd who wants to allocate more than 4G of memory for some reason.
No, it's just something that isn't useful to a majority of users yet. Just because the advantages are only helpful to a minority right now doesn't make the (real!) advantage a "meaningless technicality" nor does it make those who have a use for it "nerds".
We get it, you don't care. Why not move on instead of trying to defend the notion that it's somehow useless?
Just by looking at the direction Apple apps were taking for their UI I'd suggest it's been obvious for a long time. Carbon UIs stand out like a sore thumb.
Devs make decisions based on Apple announcements, not speculation based on "the direction Apple apps were taking for their UI". And up until mid 2007, Apple was telling devs that Carbon would work for 64 bit.
So specifically which Apple apps are on Cocoa now? I'm particularly interested in pro apps. Is there a list somewhere? Is there an easy way to tell from looking at the app?
Quote:
Originally Posted by Kickaha
Now, the message has been received by pretty much everyone except Adobe, Microsoft, and Eclipse.
That would imply that Apple itself gets that Cocoa is the way to go, and that the smart move would be starting to switch to Cocoa years ago. So again, how many apple apps are Cocoa?
Can you really blame any company for not supporting something that apple hardly uses themselves?
So specifically which Apple apps are on Cocoa now? I'm particularly interested in pro apps. Is there a list somewhere? Is there an easy way to tell from looking at the app?
That would imply that Apple itself gets that Cocoa is the way to go, and that the smart move would be starting to switch to Cocoa years ago. So again, how many apple apps are Cocoa?
I can't find a repository so unless someone comes along with an answer I'll devise a method to find out which are which and then post them to a Wikipedia page for easy viewing and editing. It would also be nice to see how much attention Apple has given Cocoa over Carbon with each new OS revision.
I can't find a repository so unless someone comes along with an answer I'll devise a method to find out which are which and then post them to a Wikipedia page for easy viewing and editing. It would also be nice to see how much attention Apple has given Cocoa over Carbon with each new OS revision.
That would be awesome. I'm kind of surprised there isn't already a list like that on wikipedia or somewhere similar.
You really think that even if they only had to rewrite the front end of Photoshop, that still wouldn't be an absolutely enormous job.
And since Apple has showed no signs of shipping 64 bit versions of any of their apps, wouldn't you say that that would make them "very poor programmers" as well?
No, it's just something that isn't useful to a majority of users yet. Just because the advantages are only helpful to a minority right now doesn't make the (real!) advantage a "meaningless technicality" nor does it make those who have a use for it "nerds".
We get it, you don't care. Why not move on instead of trying to defend the notion that it's somehow useless?
If you'd actually bothered to read any of the discussion you'd realise I'd already said exactly that. I was addressing another question: The question is if it's an interesting topic or a issue for your average reader. The answer is no.
Comments
He's a quick summary for people who can't be bothered reading the long and boring article: It doesn't matter for most people.
People who care are: those who want photoshop to use more than 4GB of memory (keep waiting guys, should be here in a couple of years) and people who run memory hungry server applications.
It's a technicality that makes little impact on most things right now, especially desktop users.
Hmm, I don't think that is going to be the case for end users; as RIA start to rise, so will the grunt to run complex javascript/actionscript/etc will rise with it. Believe me, provide a programmer with more power, and they'll find a way to not only utilise it but complain there isn't enough.
As for Photoshop and the lack of 64bit, it actually tells me that they're very poor programmers at Adobe. If they wrote their application properly, then their back end and front end shouldn't be so reliant on each other that a re-write is required - it would be just a matter of reconstructing a new front end in Cocoa. Yes, it would take a while, but it would still allow them to maintain and port the back end to 64bit carbon, and use Cocoa 64bit for the front end (as mentioned in the article that Carbon/Cocoa code can be mixed and matched).
I hope, however, they do something about h264 encoding, its terrible that something like x264 can encode faster and produce better results than a commercial product.
He's a quick summary for people who can't be bothered reading the long and boring article: It doesn't matter for most people.
People who care are: those who want photoshop to use more than 4GB of memory (keep waiting guys, should be here in a couple of years) and people who run memory hungry server applications.
It's a technicality that makes little impact on most things right now, especially desktop users.
The most important contributor to the speed of Snow Leopard is barely mentioned!
Most apps don't need more than the ~3 GB addressable memory that's available with the ancient X86 architecture. In fact, on most microarchitectures (e.g., Alpha, UltraSPARC, G5), apps typically run slower if compiled for 64-bits, because some data elements become twice the size (64-bit instead of 32-bit).
The speed of Snow Leopard will come from moving apps and the OS to the X64 instruction set, which provides for twice as many GPRs. Nearly every application will benefit from more GPRs--and benefit more than the speed hit that's incurred by using larger data elements. Other, more modern microarchitectures don't provide more GPRs just because an app is compiled for 64-bits. This is only a feature of the ancient X86.
Amazingly, very few apps for Mac OS X are 64-bit. Chess is one of them, presumably because it uses a lot of CPU relative to what's needed to drive the UI. Perhaps someone here knows whether the GUI part of Mac OS X, 64-bit Cocoa, under Leopard 10.5 is for some reason slower than the 32-bit version and that's why we don't see more 64-bit GUI apps yet? Or is it just because building, testing, bundling and distributing yet another binary isn't worth it to the software manufacturers?
(By the way, later PowerMacs could address 16 GB of physical memory, not just 8 GB.)
I think the convention assumption is that applications must be 64bit to take advantage. If one has a look at the architecture documentation in reference to the original hammer/amd64 design - the whole idea was that you could recompile 32bit applications running on a 64bit operating system and access the new registers. 32bit OS on amd64 was in compatibility mode, 32bit recompiled with the amd64 switch on a 64bit operating system meant that it was running in long-mode, which enabled it to access a wide variety of features by the processor running in native (long-mode).
I'm sure there is the original PDF still out there, it goes into great detail about how 32bit and 64bit applications both benefit merely from a recompile with the amd64 switch, even if they aren't written from the ground up to be 64bit.
I've been looking for one, but none of them offer online classes.
On a more serious note though; I remember seeing this 'internet addiction' BS that was going around - the only reason why there isn't 'television addiction' is because apparently it is socially acceptable to vegetate in front of a one-way device for hours on end versus using a computer that requires mental agility. The double standards in society is amazing imho.
Thank you very much but would you mind answering the question about what really changed going from Core Duo to Core 2 Duo?
Wikipedia is your friend.
Start here, here and here.
Summary: despite its name the Core Duo processor was not based on the "Core" microarchitecture - it was actually just a fairly minor evolution of the Pentium-M, itself based on a 32 bit microarchitecture called "P6". Core 2 processors are based on the "Core" microarchitecture, which brought many changes, including "64 bit-ness".
Amen to that. There still hasn't been any real confirmation that 10.6 will be intel only, just speculation.
Didn't you know speculation and opinions are the same as facts in this society? If somebody somewhere said so it's must be true.
Not really. Developers have been told repeatedly that the future is Cocoa if it wasn't obvious already.
Apple's given a lot of mixed messages on the relative weighting of Cocoa and Carbon. While I agree with you that Apple's made it clearer in the last few years, there was little reason to suspect in mid-2007 that Apple would drop 64-bit Carbon, especially after demoing and releasing it.
Amen to that. There still hasn't been any real confirmation that 10.6 will be intel only, just speculation.
Logic Audio. Big sample libraries are multi gig these days. I'd kill for a 64 bit version of the app, there have been 64 bit audio apps on the windows side for a couple years now, and us mac users are left out in the cold (Logic maxes out about 2.8 gigs of memory) while they can load up as much ram as they can afford to buy.
And isn't photoshop one where it could make a difference?
Sadly, right now Apple IS lagging behind windows in terms of 64 bit apps that are available. Of course it would be great to see APPLE release one of their own apps as 64 bit, but they seem to find doing it as difficult as everyone else.
So that's two applications (I already mentioned PS), used my a small minority of professional users, and only some of those have come up against the limits.
As I said, this doesn't really mean much for most people, even if it is important to get it done. It's a meaningless technicality and nothing to get excited about unless you're a nerd who wants to allocate more than 4G of memory for some reason.
Hmm, I don't think that is going to be the case for end users; as RIA start to rise, so will the grunt to run complex javascript/actionscript/etc will rise with it. Believe me, provide a programmer with more power, and they'll find a way to not only utilise it but complain there isn't enough.
As for Photoshop and the lack of 64bit, it actually tells me that they're very poor programmers at Adobe. If they wrote their application properly, then their back end and front end shouldn't be so reliant on each other that a re-write is required - it would be just a matter of reconstructing a new front end in Cocoa. Yes, it would take a while, but it would still allow them to maintain and port the back end to 64bit carbon, and use Cocoa 64bit for the front end (as mentioned in the article that Carbon/Cocoa code can be mixed and matched).
I hope, however, they do something about h264 encoding, its terrible that something like x264 can encode faster and produce better results than a commercial product.
Are you seriously saying that people need more than 4G to run Javascript programs? I hope I never see the day. And you seem to be making a case for software bloat. I predict Microsoft Word will be the first program that requires 64 bit to launch.
Adobe programmers are not bad programers and it's just not that simple. It's not just about the front end, there are more APIs than that involved. Apple is the guilty party for misleading developers.
I think the convention assumption is that applications must be 64bit to take advantage. If one has a look at the architecture documentation in reference to the original hammer/amd64 design - the whole idea was that you could recompile 32bit applications running on a 64bit operating system and access the new registers. 32bit OS on amd64 was in compatibility mode, 32bit recompiled with the amd64 switch on a 64bit operating system meant that it was running in long-mode, which enabled it to access a wide variety of features by the processor running in native (long-mode).
I'm sure there is the original PDF still out there, it goes into great detail about how 32bit and 64bit applications both benefit merely from a recompile with the amd64 switch, even if they aren't written from the ground up to be 64bit.
That's not going to make a whole lot of difference to the speed of the code and is not the point of 64 bit at all. Intel CPUs use register renaming and implements more than 8 registers in the CPU. Any advantage would spring from the compiler doing a much better job compiling given the extra registers, which is questionable.
New Hampshire has mountains? You mean geological pimples, don't you?
Well I grew up thinking we had mountains in Scotland so The White Mountains in NH being twice the size of those seem pretty big to me
Apple's given a lot of mixed messages on the relative weighting of Cocoa and Carbon. While I agree with you that Apple's made it clearer in the last few years, there was little reason to suspect in mid-2007 that Apple would drop 64-bit Carbon, especially after demoing and releasing it.
Just by looking at the direction Apple apps were taking for their UI I'd suggest it's been obvious for a long time. Carbon UIs stand out like a sore thumb.
I think the problem is Adobe's cross platform UI library and also the old Macromedia crap they've inherited - carbon and Javascript based! Merging all that together and stepping up to Cocoa style UI guidelines and cross platform is going to be some job.
Not really. Developers have been told repeatedly that the future is Cocoa if it wasn't obvious already.
I don't think it was so, really. Non-Cocoa code is alive, growing, and supplying functionality to Cocoa. Also, Apple directed everyone to adopt new Carbon UI parts to be 64bit-able and gain certain new UI features.
A year later, with these Carbon UI parts nearing completion, and some software companies carrying app prototypes to test, Apple cancelled them and left Adobe, Trolltech, AutoDesk and others facing having to redo their apps' UIs on a non-multiplatform-friendly biggie conversion project-unproven API (where is, say, Cocoa FCP?) and with an unsatisfying IDE to work with.
We could say Apple did it's real Cocoa statement then. But I don't think that was good news at all for multiplatform programmers and OS X as a big players multimedia platform.
And what happened? All the devs who screamed bloody murder about Rhapsody, and threw a fit until they got Carbon *STILL* weren't happy, and continued to scream bloody murder. So Apple backed off the intensity of the message.
They went so far as to continue developing Carbon, spending time and resources that could have been used to move the platform ahead, just to appease the legacy devs. At that time, the legacy devs were a significant portion of the dev community.
Now, the message has been received by pretty much everyone except Adobe, Microsoft, and Eclipse. (Although oddly, some of Adobe's engineers are coming to the rescue of Eclipse by porting SWT to Cocoa for them...) Further, they aren't quite as critical to the success of the Mac as they used to be. Apple can push back a bit.
The yanking of 64-bit Carbon at the last minute was kind of assholish, IMO, but the move to 64-bit was, from a technical POV, the right time to drop as much legacy cruft as possible. Who was going to benefit from 64-bit Carbon, really? Adobe and Microsoft. That's pretty much it. This was one rare case where technical reasoning overrode inter-company politics.
To us who have been around a long time, the message has *always* been: Cocoa is the future, Carbon is a stopgap. The only variance was how loudly that drum was banged.
snafu: care to explain how Cocoa is any worse for cross-platform production than Carbon? They're both proprietary Mac-only APIs, they both can call C and C++...
As for Photoshop and the lack of 64bit, it actually tells me that they're very poor programmers at Adobe. If they wrote their application properly, then their back end and front end shouldn't be so reliant on each other that a re-write is required - it would be just a matter of reconstructing a new front end in Cocoa. Yes, it would take a while, but it would still allow them to maintain and port the back end to 64bit carbon, and use Cocoa 64bit for the front end (as mentioned in the article that Carbon/Cocoa code can be mixed and matched).
You really think that even if they only had to rewrite the front end of Photoshop, that still wouldn't be an absolutely enormous job.
And since Apple has showed no signs of shipping 64 bit versions of any of their apps, wouldn't you say that that would make them "very poor programmers" as well?
So that's two applications (I already mentioned PS), used my a small minority of professional users, and only some of those have come up against the limits.
As I said, this doesn't really mean much for most people, even if it is important to get it done. It's a meaningless technicality and nothing to get excited about unless you're a nerd who wants to allocate more than 4G of memory for some reason.
No, it's just something that isn't useful to a majority of users yet. Just because the advantages are only helpful to a minority right now doesn't make the (real!) advantage a "meaningless technicality" nor does it make those who have a use for it "nerds".
We get it, you don't care. Why not move on instead of trying to defend the notion that it's somehow useless?
Just by looking at the direction Apple apps were taking for their UI I'd suggest it's been obvious for a long time. Carbon UIs stand out like a sore thumb.
Devs make decisions based on Apple announcements, not speculation based on "the direction Apple apps were taking for their UI". And up until mid 2007, Apple was telling devs that Carbon would work for 64 bit.
So specifically which Apple apps are on Cocoa now? I'm particularly interested in pro apps. Is there a list somewhere? Is there an easy way to tell from looking at the app?
Now, the message has been received by pretty much everyone except Adobe, Microsoft, and Eclipse.
That would imply that Apple itself gets that Cocoa is the way to go, and that the smart move would be starting to switch to Cocoa years ago. So again, how many apple apps are Cocoa?
Can you really blame any company for not supporting something that apple hardly uses themselves?
So specifically which Apple apps are on Cocoa now? I'm particularly interested in pro apps. Is there a list somewhere? Is there an easy way to tell from looking at the app?
That would imply that Apple itself gets that Cocoa is the way to go, and that the smart move would be starting to switch to Cocoa years ago. So again, how many apple apps are Cocoa?
I can't find a repository so unless someone comes along with an answer I'll devise a method to find out which are which and then post them to a Wikipedia page for easy viewing and editing. It would also be nice to see how much attention Apple has given Cocoa over Carbon with each new OS revision.
I can't find a repository so unless someone comes along with an answer I'll devise a method to find out which are which and then post them to a Wikipedia page for easy viewing and editing. It would also be nice to see how much attention Apple has given Cocoa over Carbon with each new OS revision.
That would be awesome. I'm kind of surprised there isn't already a list like that on wikipedia or somewhere similar.
You really think that even if they only had to rewrite the front end of Photoshop, that still wouldn't be an absolutely enormous job.
And since Apple has showed no signs of shipping 64 bit versions of any of their apps, wouldn't you say that that would make them "very poor programmers" as well?
No, it's just something that isn't useful to a majority of users yet. Just because the advantages are only helpful to a minority right now doesn't make the (real!) advantage a "meaningless technicality" nor does it make those who have a use for it "nerds".
We get it, you don't care. Why not move on instead of trying to defend the notion that it's somehow useless?
If you'd actually bothered to read any of the discussion you'd realise I'd already said exactly that. I was addressing another question: The question is if it's an interesting topic or a issue for your average reader. The answer is no.