Originally posted by whooley
I wouldn't be so sure though that there's no difference between porting Carbon and Cocoa apps. The fact that many Carbon apps are 'legacy' apps which I'd expect would have built up platform dependencies over time, newer Cocoa apps are less likely to do so.
Ok, let me qualify what I said a little then. When I speak of Carbon, I talk of Carbon Applications that run on OS X. If it is a Carbon app that doesn't run on OS X (there are a few) or an app that is source compatable but still only runs on pre-OS X (and there are a few of those too) then I don't consider it a true Carbon application. The former are CarbonLib apps, the latter Classic (InterfaceLib) apps. This is basically the terminology used by Apple as well, as Carbon is a specification of APIs that provide source compatability for existing applications (the moral equivalent of Win32) while CarbonLib is an implementation for OS 9 (similar to the old Win32 libraries that ran on Windows 3.1x).
Plus, Carbon apps are more readily optimised, IMO. Carbon is more of a set of APIs dressed as a framework than a true framework; your average Cocoa app is likely to involve significantly less code than a Carbon app, and thus there's less scope for tinkering. And generally the more optimised an app is, the less portable it is.
It depends on the nature of the optimizations, but in general optimizations don't always "need" to be ported. The kind of optimizations that you can't port are generally the kind that you can foist on any app anyway (e.g. inline assembly, altivec). Some optimizations may not be optimal on some platforms, but that doesn't mean the code won't work. The only major exception that I can think of offhand are endian issues if your platform is moving from big to little endian or vice versa.
In most applications, most of the code optimization is done by the compiler. The parts that aren't are generally well known if the application is already cross platform. The framework that you write your application to generally doesn't affect the non-hand optimized code in your application. It may be more code to do something in one framework or the other, but the code to do it is generally pretty standard and not optimized because event/interface code generally doesn't need (or benefit from) many optimizations.
And I admit, there are always exceptions. I'm sure there are some Carbon/Cocoa applications out there that would be an immense pain in the arse to port to a different architecture (heck, VirtualPC is going to be giving M$ some pain just to make it to the G5 and that isn't a huge change of platform!). But generally these issues aren't a matter of the framework they use (VPC would be just as hard to get working on the G5 if it were Cocoa based - the problem is with the emulation engine, not the interface). I've been doing Carbon work for a long time (I jumped on the bandwagon back in the OS X Public Beta days when Carbon Events weren't even documented!) and I can't see anyway in which the framework of apis it provides would cause headaches in porting from one 32-bit architecture to another 32-bit architecture (yes, there may have to be changes to Carbon to support 64-bit memory spaces, fortunately, they aren't that many).
