Re: When does Carbon completely?

On 9 Oct 2009, at 04:18, Lothar Scholz wrote:

> Apple isn't that stupid to force everyone on Cocoa for low level. This
> would be a dead end even for them. Thats why Grand Central is written
> in portable C - you might call it carbon.

No, you wouldn't call that Carbon.

Things aren't Carbon just because they're implemented in C or have a C  
API, in just the same way that they aren't BSD or POSIX things just  
because they're implemented in C or have a C API either.

Generally speaking, things that are part of Carbon have the word  
"Manager" or "Toolbox" in their name (e.g. "File Manager", "Resource  
Manager", "High Level Toolbox"...).  QuickDraw is also part of Carbon,  
but doesn't have either of these words in its name.  The old QuickTime  
API *might* be considered to be part of Carbon too I suppose (though I  
tend to think of it as a separate thing).

Some people erroneously include all of ApplicationServices.framework  
or CoreServices.framework under the Carbon umbrella, but those  
frameworks include plenty of things that IMO aren't really part of  
Carbon or Cocoa... CoreGraphics, CoreText, ColorSync, ImageIO,  
CFNetwork, LaunchServices, SearchKit and so on.

> EG> My current thinking is that OS 11 will be the line in the sand  
> (both
> EG> for 32-bit apps and Carbon). You will need to be Cocoa/Core  
> Foundation
> EG> & 64-Bit and anything else will just cease to function.
>
> There will always be the ability to run 32-bit because for 90% of
> applications a pure 64-bit mode has only disadvantages. Cache usage
> is and will always be more important then more internal registers.

I'm pretty certain Apple said that all of the apps they'd moved to 64- 
bit (on Intel) were faster than they used to be in 32-bit.

I agree that cache usage is an issue for 64-bit code, but IA32 is *so*  
register poor that just expanding the number to 16 as has been done  
for Intel64 is a huge win, and there's also a faster system call  
interface.

If we were talking about 64-bit PowerPC, I'd largely agree with you,  
since there are no more registers and you're just going to increase  
the amount of cache space required.

The other issue worth mentioning, of course, is that if you're running  
on a system where most apps are running 64-bit, loading a 32-bit app  
means loading all the 32-bit versions of the frameworks on which it  
depends.  That's worth considering too.

> Well i don't see any reason why there shouldn't be a 10.10 or 10.11
> I would assume there X is now a fixed trademark and would be very
> complicated to change this.

If they were going to bump the initial version number to 11, I don't  
see why Mac OS XI would be such a big deal.  But I think you're right,  
it's more likely to say Mac OS X 10.nn instead.

Kind regards,

Alastair.

-- 
http://alastairs-place.net