Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

badNameErr

macrumors regular
Jun 13, 2007
238
38
Above ground.
MS-Office, PhotoShop, Quark are all Carbon apps.

So it's going to be a very very very long time before we see 64-bit versions of MS-Office, Adobe PhotoShop, Quark XPress for Leopard.

:mad: :eek:
 

Fairly

macrumors regular
Sep 24, 2006
160
0
Cambridge UK
MS-Office, PhotoShop, Quark are all Carbon apps.

So it's going to be a very very very long time before we see 64-bit versions of MS-Office, Adobe PhotoShop, Quark XPress for Leopard.

:mad: :eek:
Too right. Another thing as there's been a lot of talk about whether Carbon itself is deprecated: I think maybe it already is? For a lot of typical Carbon calls are being flagged by the GCC in Xcode already as deprecated. I don't know what they plan to do here as these calls are totally necessary at the moment - there's no way to get into resource forks without them and yet Apple's GCC will spit back "deprecated". So maybe we haven't heard the end of this story yet.
 

fly75

macrumors newbie
Jun 13, 2007
23
0
Simpler? Have you ever thought about what you'd have to do to implement applications with this model?

Go try it. Write a simple text editor that uses mmap() and shuns all of the file I/O. I think you'll find your code more difficult to write, more complicated, and impossible for anybody else to figure out.

When you don't have any concept of a file system, and applications are directly accessing disk-blocks for storage (as they often did 35 years ago), this might make perfect sense. On a modern system, where you've got millions of files, possibly scattered all over a network, and dozens (or even hundreds) of apps running at once, that design would quickly lead to insanity.

Not necessarily. IBM midrange systems (s/38, AS/400, iSeries) have been using single level storage for the past 20 something years without needing to directly reference the hardware from within an application. Basically the system treats secondary storage as a big swap file, applications are written to a virtual machine API that know nothing about disks, and OS takes care of moving data in and out of memory as needed.

Different, but it works.
 

retroneo

macrumors 6502a
Apr 22, 2005
769
140
This is very bad news.

Developers on the official carbon mailing list are freaking out saying their porting projects are now unviable, some will be cancelled. Unfortunately running windows versions of software is now preferred to porting windows software to the mac :-(

There are more details about this to be announced in a session on Thursday. It is speculated that 10.6 will be required for 64-bit carbon, as it was one feature that had to be cut to deliver Leopard on time.
 

retroneo

macrumors 6502a
Apr 22, 2005
769
140
Here's a sample of developer reaction:

We will probably just produce a 64 bit version for Windows and leave
the Mac at 32 bits and then suggest to those Mac customers that need
64 bits to switch platforms.

The Mac stuff is all Carbon-based and this is going to be a real blow and will probably spell the end for our product on the Mac. The other platforms already have 64 bit versions we've just been waiting for 64 bit support on the Mac.

I suspect the Mac version of our app is probably just going to fade away. There's no chance we're going to switch toolkits.

the management here [are] flying round in a panic.

This is very bad!
 

GreatDrok

macrumors 6502a
May 1, 2006
561
22
New Zealand
I have been working with 64 bit systems and writing 64 bit code for a *looong* time (10+ years) starting back on alpha AXP and MIPS R10000 boxes. 64 bit is useful when you need to directly address a lot of data at the same time assuming you have the memory to hold it all (ie > 4GB of RAM) otherwise, no biggie as you will have to page it anyway. Meanwhile, the are other benefits to 64 bit such as microparallelism such as Altivec and SSE although there have been much better implementations. I liked MVI on the Alpha because the instructions simply operated on any 64 bit register like any other instruction. Altivec and SSE are nasty hacks by comparison. Finally, dealing with very large files is pretty easy these days (fseeko() for example) so I wouldn't worry too much about what is 64 bit and what isn't. The situation isn't anything like as bad as it was when we moved from 16-32 bit, or for those of us who have been around far too long 8 bit (shudder).
 

ajbrehm

macrumors 6502
Aug 14, 2002
341
0
Zurich, Switzerland
64 Bit Carbon is NOT dead!

Ok, here's the thing.

If Apple are moving to 64 Bit, they will be moving as much as is possible. Carbon is a portable version of the Toolbox API, hence it should be possible.

64 Bit Carbon was mentioned in earlier versions of Leopard's feature list, this means Apple were working on it. It's too big a project to quasi-announce without some effort put into it.

All of Mac OS's bigger apps are Carbon: MS Office, Quark, Photoshop; everything except Apple's own.

MS Office might not need 64 Bit Carbon ever (seeing that Microsoft are apparently happy with it being a 32 Bit version on Windows as well), but Photoshop will, soon.

The upcoming Intel version of Photoshop is obviously 32 Bit, hence 64 Bit Carbon is not currently needed.

I predict that 64 Bit Carbon will come with the next OS X release after Leopard ("Lion").


On a sidenote... I was wondering how Tiger's 64 Bit support works and it appears that Tiger is a 32 Bit kernel running in "Compatibility Mode", which is a submode of "Long Mode".

See http://forum.parallels.com/showthread.php?t=11010.
 

Eraserhead

macrumors G4
Nov 3, 2005
10,434
12,250
UK
DISCLAIMER: I've only used Cocoa and am not a world expert so may be wrong on some of this stuff, but no-one seems to really have explained the implications of this move.

This move it is a bit of a shock, and I'm personally not convinced its a good thing, but time will tell.

This change isn't going to stop Adobe's applications having Mac versions (though some stuff like production suite may leave), but some of the applications which make 10% of their money from their Mac version (rather than the 40-50% of Adobe) could cease further development for the Mac. It could also make developers less likely to get their "feet wet" in the future on the Mac. In terms of specific applications it could well mean that MATLAB never goes aqua (it uses X11 at the moment), and that applications like Autocad never get ported to OS X, especially as Mac users can run them on Windows.

At the moment some stuff is Cocoa only (OS wide spell-check for example) and some stuff is Carbon only (e.g. Keyboard Layout). Some of the Carbon stuff is horrible and practically unusable and badly needs improvement. If the Carbon only stuff is available in Cocoa, then only having one framework (Cocoa) makes it easier for Apple to add new features to the operating system which is good.

I believe what really matters to developers is if moving an application to 64 bit Cocoa from Carbon is roughly as easy as moving to a potential 64 bit Carbon then that is OK.

Also if developers need to write the same or less code to use a Cocoa interface from their current (cross platform) code-base as a Carbon one then this move also makes sense to them as they do get additional features (like spell check) for free for their applications, it also seems to be easier to make Cocoa Applications chip neutral as they went from being PPC only to Universal fairly quickly.

Currently all the usual suspects (Adobe, Microsoft) use Carbon so it'll be interesting to see how they react to this.
 

Nutter

macrumors 6502
Mar 31, 2005
432
0
London, England
I believe what really matters to developers is if moving an application to 64 bit Cocoa from Carbon is roughly as easy as moving to a potential 64 bit Carbon then that is OK.

It's nowhere near as easy. For the Carbon developer, moving to 64-bit is (was?) just a case of making sure that code can cope with 64-bit longs and pointers, and rewriting any code that uses API no longer available in 64-bit Carbon.

Moving to Cocoa, 64-bit or not, means a complete rewrite of the whole user interface, at the very least. It's almost as difficult as porting an app from one OS to another.

In any case, this does also have implications for Cocoa developers. As has been mentioned, it isn't at all unusual to use little bits of Carbon in a Cocoa application. Not to mention the fact that parts of Cocoa sit on top of Carbon, NSMenu being a prime example. I don't see how it would be possible for Apple to drop 64-bit Carbon completely.
 

SPUY767

macrumors 68020
Jun 22, 2003
2,041
131
GA
So, this means AppleWorks will STILL be dog slow when placing 8GB image files :mad:

:p

Exactly. This is the meh of the year for me. Who cares. Carbon was never meant as a development API for OS X, it was a transitionary module from classic, and I could care less if it's 64 bit.
 

gnasher729

Suspended
Nov 25, 2005
17,980
5,565
good. we need to get away from carbon apps because they don't work as well for Universal Access stuff like VoiceOver.

any more motivation we can give developers to modernize their apps without taking away their ability to function currently is good IMO.

Actually, it isn't good at all, it is rather crappy. :mad:

It is worst for developers who write cross-platform applications. Carbon works at a much lower level, which means you sometimes have some extra work to do, but you can fit it into any existing application architecture. If you have code that needs to run on Windows, Linux, and MacOS X, you can do it easily with Carbon.

Cocoa does lots of things, and that makes it much more difficult to fit in. You have to actively work around to make it stop doing things. And it isn't built for that, making it even more difficult. This makes it all much more difficult to use the same code base with few changes on different platforms.

And if you think any different, and you think you are the expert in these things, then just tell me which >1 million lines of code you are implementing on different platforms.
 

gnasher729

Suspended
Nov 25, 2005
17,980
5,565
Also if developers need to write the same or less code to use a Cocoa interface from their current (cross platform) code-base as a Carbon one then this move also makes sense to them as they do get additional features (like spell check) for free for their applications, it also seems to be easier to make Cocoa Applications chip neutral as they went from being PPC only to Universal fairly quickly.

The only reason why Cocoa applications had fewer problems moving to a different processor was programmers using built-in functionality to store data in files. But that is of no value to programmers who have to read and write the same files in Windows or Linux, because there is no Cocoa in Windows, and there is no Cocoa in Linux.

And the first "if" is definitely wrong: Cocoa is much much harder to integrate in a cross-platform codebase than Carbon. Starting with the fact that you can't even use the same programming language! And then there is the problem that to switch to Cocoa, you have to do lots and lots and lots of work just to get to the same point where you are already!
 

Eraserhead

macrumors G4
Nov 3, 2005
10,434
12,250
UK
The only reason why Cocoa applications had fewer problems moving to a different processor was programmers using built-in functionality to store data in files. But that is of no value to programmers who have to read and write the same files in Windows or Linux, because there is no Cocoa in Windows, and there is no Cocoa in Linux.

That really makes sense, they are clearly totally different beasts for solving different problems and are complimentary. Interesting.

Starting with the fact that you can't even use the same programming language!

Forgive my ignorance but can't you use Obj C++ with Cocoa to at least solve that problem?

Exactly. This is the meh of the year for me. Who cares. Carbon was never meant as a development API for OS X, it was a transitionary module from classic, and I could care less if it's 64 bit.

As the posters above have said Carbon is far better for cross platform applications, it seems my "worst case" is far closer to reality.
 

shamino

macrumors 68040
Jan 7, 2004
3,443
271
Purcellville, VA
As the posters above have said Carbon is far better for cross platform applications, it seems my "worst case" is far closer to reality.
This is really hard to say.

Carbon, like Classic before it, follows the paradigm of event loops and event handlers. This is similar to the model used by many other GUIs at their lowest level (including X11, Windows, and others.)

Cocoa, on the other hand, hides this behind a lot of stock system objects. You override event handlers in object classes/instances as needed to provide your functionality. This is very different from traditional GUIs at the lowest level, but is not that far off from traditional GUI programming with OO frameworks (like MFC).

Of course, in all cases the actual APIs are quite different, but that's always the case, unless you're using a framework designed as cross-platform.
 

wrldwzrd89

macrumors G5
Jun 6, 2003
12,110
77
Solon, OH
This is good to know about - gives me, as a software developer, even more of an excuse to learn Objective-C, which I really need to do to write better Mac OS X apps.
 

yetanotherdave

macrumors 68000
Apr 27, 2007
1,768
12
Bristol, England
Correct me if I'm being stupid, I know sod all about programming (having only started looking at cocoa as my first language about a week ago), but why wouldn't apple make iTunes 64bit? Wouldn't that offer the best performance on 10.5?
 

truchmachin

macrumors newbie
Jun 14, 2007
1
0
Exactly. This is the meh of the year for me. Who cares. Carbon was never meant as a development API for OS X, it was a transitionary module from classic, and I could care less if it's 64 bit.

That's true for a subset of it, however there's also a good part of it that was made only for OS X (and was being updated/expanded in each OS X release).

Many companies have just spent much time (or are still ...) moving code to the more modern flavor of Carbon to do Universal Binary, now they are expected to scrap that code if they wish to have a 64-bit version?
 

shamino

macrumors 68040
Jan 7, 2004
3,443
271
Purcellville, VA
Correct me if I'm being stupid, I know sod all about programming (having only started looking at cocoa as my first language about a week ago), but why wouldn't apple make iTunes 64bit? Wouldn't that offer the best performance on 10.5?
The term "64-bit" is very much abused, especially by game console manufacturers - which is where the public at large has heard the term most often.

A processors "bitness" (i.e. 16-, 32-, 64-bit, etc.) is generally used to refer to one of the following:
  • The size of the processor's registers - that is, the number of bits it can perform math on in a single machine-instruction using a single register.
  • The size of the address bus - the maximum amount of memory that can theoretically be attached without resorting to external bank-switching hardware.
  • The size of the data bus - the maximum amount of data that can be moved to/from RAM in parallel.

In the case of Intel's 64-bit chips, all of the above are true. In addition, there are more registers. This isn't a 64-bit feature per se, but it is something that Intel and AMD added when they designed the x86_64 architecture.

Notice that speed has nothing to do with this. A 64-bit chip and a 32-bit chip that are otherwise identical will perform identically. And the 64-bit chip might even run more slowly, because many objects in memory (like memory pointers) will be larger, requiring more memory access and more cache.

A wider data bus can improve the performance of existing 32-bit code. The wider address bus can indirectly improve the performance of 32-bit code (a single app can only access 4G of RAM, but the system as a whole can use more.) More registers can (I think) improve the performance of 32-bit code, if the program is compiled to take advantage of them. And some features (wider registers) only affects 64-bit code.

Keeping this in mind, consider what iTunes does. It reads files from disk, it decodes the audio/video, and it pushes the decoded data to the operating system's A/V APIs.

Now consider what parts of this would benefit from being 64-bit. Reading files would not benefit unless the program tries to load the entire file at once (which would not be a good idea unless you can guarantee that there's enough RAM to hold it, since swapping would cancel out any performance benefits). 32-bit code can use file-system APIs capable of reading large files (greater than 4GB, whose length is too large for a 32-bit integer.) Decoding the A/V would definitely benefit from more registers. It might benefit from wider registers, but the existing SIMD instructions (AltiVec on PPC and SSE on Intel) already support 64-bit operations, and iTunes almost definitely uses these instructions. Pushing the decoded data to the OS wouldn't benefit from having more bits.

In other words, it is unlikely that a program like iTunes would benefit very much from being ported to 64-bit code. In general, the applications that get the greatest benefit are those that may need to access more than 4GB of data at once. Apps like Photoshop, FinalCut, etc. As 32-bit apps, these programs would have to swap data to/from disk, which is slow. As 64-bit apps, they can keep their data in-memory, which is fast (assuming there's enough RAM installed, of course.)
 

Krevnik

macrumors 601
Sep 8, 2003
4,100
1,309
And the first "if" is definitely wrong: Cocoa is much much harder to integrate in a cross-platform codebase than Carbon. Starting with the fact that you can't even use the same programming language! And then there is the problem that to switch to Cocoa, you have to do lots and lots and lots of work just to get to the same point where you are already!

That really depends, Handbrake is an example of an app that can and has been moved to Windows (and very likely works on Linux if you can build it) that uses Obj-C for the UI. All the DVD reading, encoding, and so on live in a C library (although it doesn't need to be), and the Obj-C UI calls into it.

Now, just because Cocoa provides the framework for something, doesn't mean you have to use it in your app. Carbon calls and POSIX calls are all accessible from a Cocoa app in addition to the Cocoa APIs. Sometimes, you /need/ to use something different, for various reasons (cross-platform, API doesn't exist yet in Cocoa, etc), but that hasn't stopped me from using Obj-C to run the UI for projects that needed some Carbon/POSIX love.

Too right. Another thing as there's been a lot of talk about whether Carbon itself is deprecated: I think maybe it already is? For a lot of typical Carbon calls are being flagged by the GCC in Xcode already as deprecated. I don't know what they plan to do here as these calls are totally necessary at the moment - there's no way to get into resource forks without them and yet Apple's GCC will spit back "deprecated". So maybe we haven't heard the end of this story yet.

I'm not sure this scenario makes Carbon out to be deprecated... resource forks, yes... but not Carbon. Resource forks currently stand in the way of making OS X able to boot/run from ZFS or UFS without additional hacks above the FS layer. Apple has been in a push that even Carbon apps migrate to using NIBs and other means to store resources using the Bundle/Package APIs instead of resource forks. Maybe not talked about it loudly from the mountains, but it is there.
 

wrldwzrd89

macrumors G5
Jun 6, 2003
12,110
77
Solon, OH
<snip>
More registers can (I think) improve the performance of 32-bit code, if the program is compiled to take advantage of them.
<snip>
Therein lies the problem - in theory what you say is correct, but in practice the additional registers are only accessible in 64-bit mode. We don't know if Leopard runs the CPU in 64-bit mode or not. If it does, then all programs compiled with them in mind will make use of them. If not, then they won't be accessible.
 

ajbrehm

macrumors 6502
Aug 14, 2002
341
0
Zurich, Switzerland
Therein lies the problem - in theory what you say is correct, but in practice the additional registers are only accessible in 64-bit mode. We don't know if Leopard runs the CPU in 64-bit mode or not. If it does, then all programs compiled with them in mind will make use of them. If not, then they won't be accessible.

Tiger already runs in long mode and a 64 Bit program already makes use of 64 Bit features.

You can test it. Create a primitive C program and compile it for i386, x86_64, and as a universal binary containing both. Run the three files on a 64 Bit Intel Mac.

You will see that the image in memory loaded from the universal binary is the 64 Bit image. Tiger already assumes that 64 Bit is "more native" and picks a 64 Bit image from a universal binary if available.

The Tiger kernel is 32 Bit but appears to run in Long Mode when available. See the Parallels forum discussion thread I linked to earlier.

Tiger running on a G5 will pick the 64 Bit PowerPC image in a universal binary, if available.

Priorities appear to be (assuming a universal binary with 32 and 64 Bit x86 and PowerPC images):

32 Bit PowerPC Mac: picks 32 Bit PowerPC image, fails if not available.

64 Bit PowerPC Mac: picks 64 Bit PowerPC image if available, if not picks 32 Bit PowerPC image, fails if not available.

32 Bit Intel Mac: picks 32 Bit Intel image if available, if not picks 32 Bit PowerPC image to run in Rosetta, fails if not available.

64 Bit Intel Mac: picks 64 Bit Intel image if available, if not picks 32 Bit Intel image if available, if not picks 32 Bit PowerPC image to run in Rosetta, fails if not available.

In short: Tiger on a 64 Bit Intel Mac runs everything except a 64 Bit PowerPC image.
 

wrldwzrd89

macrumors G5
Jun 6, 2003
12,110
77
Solon, OH
Tiger already runs in long mode and a 64 Bit program already makes use of 64 Bit features.

You can test it. Create a primitive C program and compile it for i386, x86_64, and as a universal binary containing both. Run the three files on a 64 Bit Intel Mac.

You will see that the image in memory loaded from the universal binary is the 64 Bit image. Tiger already assumes that 64 Bit is "more native" and picks a 64 Bit image from a universal binary if available.

The Tiger kernel is 32 Bit but appears to run in Long Mode when available. See the Parallels forum discussion thread I linked to earlier.

Tiger running on a G5 will pick the 64 Bit PowerPC image in a universal binary, if available.

Priorities appear to be (assuming a universal binary with 32 and 64 Bit x86 and PowerPC images):

32 Bit PowerPC Mac: picks 32 Bit PowerPC image, fails if not available.

64 Bit PowerPC Mac: picks 64 Bit PowerPC image if available, if not picks 32 Bit PowerPC image, fails if not available.

32 Bit Intel Mac: picks 32 Bit Intel image if available, if not picks 32 Bit PowerPC image to run in Rosetta, fails if not available.

64 Bit Intel Mac: picks 64 Bit Intel image if available, if not picks 32 Bit Intel image if available, if not picks 32 Bit PowerPC image to run in Rosetta, fails if not available.

In short: Tiger on a 64 Bit Intel Mac runs everything except a 64 Bit PowerPC image.
Good point - GUI apps excluded, of course. That tells me that Tiger (and Leopard) does indeed run the CPU in 64-bit mode, if it's supported by the Mac it's running on:D
 

ajbrehm

macrumors 6502
Aug 14, 2002
341
0
Zurich, Switzerland
Good point - GUI apps excluded, of course. That tells me that Tiger (and Leopard) does indeed run the CPU in 64-bit mode, if it's supported by the Mac it's running on:D

Almost...

The differentiation "GUI apps" vs "non-GUI apps" is not useful. It's Darwin apps vs Cocoa apps vs Carbon apps. 64 Bit Darwin programs already run and there is a 64 Bit set of X libraries for PowerPC (likely for Intel too), hence you can run 64 Bit GUI apps, just not Cocoa or Carbon apps.

X11.app is a Cocoa app, hence it is 32 Bit.

Tiger: 32/64 Bit Darwin, 32 Bit Carbon, 32 Bit Cocoa
Leopard (apparently): 32/64 Bit Darwin, 32 Bit Carbon, 32/64 Bit Cocoa

Now, Tiger's kernel and entire system (apart from some BSD libraries, apparently) are 32 Bit. The kernel appears to run in Compatibility Mode, a subset of Long Mode. Leopard is supposedly 64 Bit (and runs in Long Mode).
 

hayesk

macrumors 65816
May 20, 2003
1,460
101
Here's a sample of developer reaction:

blah blah - we'll have to abandon Mac version... blah blah

This is very bad!

Very bad melodrama, if you ask me.

- just because 64-bit Carbon won't be available until the next OS (or possibly even 10.5.something), why would you discontinue your product altogether?
- if it makes business sense to produce a Mac version, then it makes business sense. Real companies don't get all huffy and discontinue products just because they have a delay.
- most Windows users are still using 32-bit machines, and most corporations are still running Win2K and XP. It's going to be a long time before 64-bitness will be requirement for software developers.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.