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

Mac OS X 10.6 Snow Leopard: Cocoa Finder and 64-Bit Changes

Could someone explain to me what is and what isn't 64-bits in OSX already? What's the use in having a 64-bit beast like a Mac Pro without complete 64-bit support?

I thought that OSX was already native 64-bit...
 
iLLucionist said:
Could someone explain to me what is and what isn't 64-bits in OSX already? What's the use in having a 64-bit beast like a Mac Pro without complete 64-bit support?

I thought that OSX was already native 64-bit...
Click to expand...

AidenShaw said:
Along with these advantages comes the necessity of upgrading all of the [OSX] kernel's drivers to 64-bit, including any provided by third parties. Again, that's because 64-bit programs can't load and run 32-bit plugins, and vice versa. That means Mac users will need to do the same driver upgrade that Windows Vista users did.​

Graphic from that link - although I suspect that all of the blue disappears if you have an old 32-bit CPU:

leopard-081028.gif
Click to expand...

Originally Posted by Eric S.
Interesting article on AppleInsider today about Snow Leopard's 64-bit strategy:
http://www.appleinsider.com/article...c_os_x_snow_leopard_64_bit_to_the_kernel.html
 
akac said:
You won't ever see that. Only for the new gen. This is because the hardware chipset on older MBPs simply do not support more than 4GB. The new gen MBP has a chipset that supports 8GB, but at the moment it seems the OS driver for that chipset is not setup for it.
Click to expand...

In any case, I don't think we'd have to wait until Snow Leopard to get support for 8 GB - if Apple's going to do it, it's probably just as easy to update the firmware/software on current MBPs running Leopard.
 
snejj said:
Um, all of that already exists in Leopard! If you have a recent Core 2 Duo Mac, you're probably running 64-bit apps right now without realizing it :)

The only new bit in Snow Leopard (according to this report) is that the kernel itself will be 64-bit. That probably will not make any noticeable difference to apps, apart from improved speed of the overall OS.
Click to expand...

I realize that. I guess I didn't say it because the AppleInsider article was talking about it, but they were comparing Windows' transition to 64-bit and Apple's. My statement was pertaining to the Windows users that have no clue if they have the 32-bit version or 64-bit version.
 
Here's what I don't understand. Apple has been on this path for more than 2 years, four really, and only now they are tendering Cocoa Finder?

One thing that gets me a bit is how hypocritical Apple is about some things. Crippling USB to push FW, insisting developers focus on Cocoa for forward compatibility but not doing so internally even incrementally with core-n and Finder and kexts.

One wonders when Apple does the NEXT transition, and I can assure you it is already in process, will they put us all through that again?

Yep!

I have a suggestion. Make various generations of Macs compatible via INTERFACES not CODE BASES. Wires and OLD CPU's (networks and virtual instances) are cheaper than programmers!

Rocketman

"Apple's top-level strategy god."
 
albusseverus said:
I'm pretty tired of this 'Apple suddenly dropped 64bit Carbon support' nonsense. Developers have had 10 years (that's 100 years in computer time) to move to Cocoa !!

My indignation at such inability to actually move to OS X (basically) is somewhat tempered by Apple taking 10 years to move Finder (arguably the most basic OS X app) to Cocoa !!

10 years of legacy OS 9 code? It's a wonder OS X works at all !!

Can somebody please explain to me why it's taken so long ? I understand it's possible to convert parts of the code to Cocoa and it works seamlessly, so why haven't developers slowly been converting to Cocoa since Day 1 ??
Click to expand...

Don't sweat it. The AppleInsider writer has somehow managed to cite C APIs and thus Carbon being in it's place when they clearly don't grasp that Objective-C is a superset of C. Carbon is a deliberate set of design patterns and collection of C APIs designed to work with Objective-C and Cocoa during the transition.

One can no more remove C and continue to have Objective-C than fly. How this becomes, CARBON LIVES shows the desperation of the past to hang on to it.

All low level, but high level language APIs are in C. All high level, even higher level language MVC/KVC APIs are written in ObjC and the Cocoa Design Patterns not to mention the inclusion of C++ via ObjC++. Somehow this concept that Carbon was some necessity for OS X to continue in development shows how dense the people claiming such nonsense. We NeXT folks created Carbon clean up the > 5,000 all over the place C APIs that was Apple prior to the merger.

Cocoa's agnostic approach to dynamically typed and dynamically run-time based languages makes Python and Ruby natural fits, as well.

With LLVM there are all sorts of options for programming languages within the Cocoa environment.
 
fishy007 said:
I'm very new to the Mac world (just picked up a MBP last week) so please forgive this stupid question...but what exactly is Cocoa? and Carbon?
Click to expand...

They are programming environments used by developers. If you are at all familiar with programming it is like Fortran, C, Cobol, Pascal, or BASIC.

End users don't care. They just enjoy and exploit the hard work of developers in exchange for a free download or a license fee.

As it should be. :D

Rocketman
 
AidenShaw said:
Please note that many Windows apps and drivers package the 32-bit and 64-bit versions of the applications in the same kit - so the Windows user can also be unaware of the "bitness" of the computer. The installation kit decides which binaries should be copied, based on the current machine.

The avoids the "fat binary" problem - the Windows installer doesn't install code for the unnecessary architecture.
Click to expand...
This is a very misleading statement.

Windows only runs in 64 bit if you are deliberately running 64 bit Windows. The user would most definitely be aware of the "bitness." they would also be aware because, running Windows 64 bit, they would realise that there aren't hardly any programs for it.

As far as the original argument you responded to, (that the end user would not need to be aware of whether a program was 32 or 64 bit), it is most assuredly the case with OS-X and most assuredly *not* the case with Windows.
 
MrChurchyard said:
You do realize that Apple had announced a 64-bit extension of the Carbon API only to tell them later "no 64-bit Carbon for you"?


Some of the best code in MacOS X is from way back NextSTEP, which is also pretty old, or even Unix stuff which is even older ;)

Oh, and btw: Finder + Cocoa = Finder. Carbon is not bad code!
Click to expand...

I expect that Apple realised that offering 64 bit Carbon wasn't going to help the transition to Cocoa, it was only going to entrench legacy code even longer. Witness CS4 - no intention to go Cocoa, they'll hang on until the death. They already have to put out the Windows version because their developers lose interest once the Mac version is working... Adobe has a problem and I don't want their attitude to hinder my OS development.

And I totally agree that Apple should have dropped it. What I don't understand is why developers didn't want to change to Cocoa earlier anyway. It's like users saying - no I don't want to go to Leopard, Tiger works just fine for me, I refuse!

Every line of Carbon code slows down my computer (supporting legacy code etc) and prevents OS X from progressing.

10 years we've had to rid ourselves of OS 9 code, and believe me, I miss "the Mac OS" more than ANYBODY ! OS X has a long way to go to even be in the same class as the Mac OS for usability - and I don't want legacy layers preventing that forward progression.
 
albusseverus said:
I'm pretty tired of this 'Apple suddenly dropped 64bit Carbon support' nonsense. Developers have had 10 years (that's 100 years in computer time) to move to Cocoa !!

My indignation at such inability to actually move to OS X (basically) is somewhat tempered by Apple taking 10 years to move Finder (arguably the most basic OS X app) to Cocoa !!

10 years of legacy OS 9 code? It's a wonder OS X works at all !!

Can somebody please explain to me why it's taken so long ? I understand it's possible to convert parts of the code to Cocoa and it works seamlessly, so why haven't developers slowly been converting to Cocoa since Day 1 ??
Click to expand...

Politics. We had a working Cocoa (YellowBox) Pure Objective-C Finder back in 1998. During the Rhapsody fiasco, the political infighting, the BlueBox/RedBox/YellowBox debacle of everyone wanting the OS to embrace all possible user pools Steve and Avie Tevanian bit the bullet for transition and the Engineering Team offered Carbon in 1997 WWDC. I had to explain it to developers when they walked the halls and wanted answers. I also emphatically conveyed that it was a Transitional API designed to be removed within 2 years.

Adobe, Macromedia and Microsoft were the three biggest barriers during a time when Apple was basically broke. In fact, when NeXT[us] merged with Apple[them] they had roughly 3 months of working capital on-hand.

When Fred Anderson convinced Steve to come back and be the interim-CEO (iCEO) Steve negotiated a settlement regarding QuickTime and other patent infringements out-of-court with Microsoft that closed a multi-billion dollar lawsuit for a $150 Million cash infusion and a 4 major revision release of Microsoft Office for the upcoming OS X.

With all the legacy code by third parties who tied into Finder and other Carbon APIs it became clear that just swapping it out was DOA.

The effort to play nice and duplicate a lot of work ensued and slowly evolved OS X. Just as PPC was being publicly produced, an Intel (x86 compliant) continued to be developed and finally released during the Intel transition.

This same transition with Cocoa and Finder has been evolved over the past decade.

This isn't a recent project, but a well-defined timeline to finally move away from the Mac OS legacy to the future that takes from Openstep and paradigms from Mac OS legacy that are plausible, while drawing upon other industry UI ideas amongst other, internal ideas.

To make a long story short, business trumps technology once again, but only for a decade.

OS X 10.6 will be the first OS X release this former NeXT/Apple Engineer is looking forward to embracing, from the system level up to the Cocoa APIs. Leaving that company was a painful decision and one I often regret. Now it appears it's finally moving in the direction that makes the excitement of the Industry I was experienced at NeXT coming back again.
 
dizastor said:
Hopefully they'll manage to throw something new and flashy on top of all of these stability improvements.

Maybe they'll just create features out of the improvements... like "Exposé 2.0 or Finder X"
Click to expand...
God, I hope not. The whole beauty of Snow Leopard is that they're fixing the plumbing. I'm tired of OS vendors loading the OS up with stuff that just gets in the way because they feel they can only sell "features".
Catfish_Man said:
Personally I've found that rewriting code is a good way to break things.
Click to expand...
:D Depends on the code, how old it is, how many modifications have been grafted on, etc... Given the changes to 64bit, multi processor and GPGPU processing, it may make sense to shore up the foundation.
albusseverus said:
I'm pretty tired of this 'Apple suddenly dropped 64bit Carbon support' nonsense. Developers have had 10 years (that's 100 years in computer time) to move to Cocoa !!

Can somebody please explain to me why it's taken so long ? I understand it's possible to convert parts of the code to Cocoa and it works seamlessly, so why haven't developers slowly been converting to Cocoa since Day 1 ??
Click to expand...
In part, reference the post I quoted above yours-- changing code often breaks things. Second, any application that was built to be cross platform, in whole or in part, probably has a whole mess of abstraction libraries targeted at Carbon that they just don't want to rewrite. Third, reference two quotes up-- companies want to spend their time adding features they can sell, not rewriting the existing ones to a new API in a new language...
 
albusseverus said:
And I totally agree that Apple should have dropped it. What I don't understand is why developers didn't want to change to Cocoa earlier anyway. It's like users saying - no I don't want to go to Leopard, Tiger works just fine for me, I refuse!

Every line of Carbon code slows down my computer (supporting legacy code etc) and prevents OS X from progressing.
Click to expand...

Developers are not there to support Apple, their job is to support their own customers. I don't suppose you have taken count of how many technologies Apple has introduced over the years and then thrown away, and how many man years have been wasted chasing the latest Apple fad. Burnt too often, they waited until Cocoa was firmly there.

And I can't see how you think that Carbon code slows down your computer. Lots of Cocoa is still absolutely badly documented, with no guidance on how to get good performance, with stuff mysteriously working or not working depending on how you write your code (NSImage anyone? ), moving stuff to CoreImage making operations four times slower, and so on. Idiotic things like removing FSRefs and support for AliasHandles which kills one of the biggest advantages of MacOS X compared to Windows.

My customers have much better software in their hands because I didn't move to Cocoa.
 
Rocketman said:
Here's what I don't understand. Apple has been on this path for more than 2 years, four really, and only now they are tendering Cocoa Finder?

One thing that gets me a bit is how hypocritical Apple is about some things. Crippling USB to push FW, insisting developers focus on Cocoa for forward compatibility but not doing so internally even incrementally with core-n and Finder and kexts.

One wonders when Apple does the NEXT transition, and I can assure you it is already in process, will they put us all through that again?

Yep!

I have a suggestion. Make various generations of Macs compatible via INTERFACES not CODE BASES. Wires and OLD CPU's (networks and virtual instances) are cheaper than programmers!

Rocketman

"Apple's top-level strategy god."
Click to expand...

Cocoa Finder - Probably as it's an incremental effort to move to Cocoa. It hasn't really been mentioned much explicitly, but Apple may well be doing both a code rewrite to get it Cocoa'fied, but also make many of it's apps concurrent ready - i.e. modify the code to make it more parallel computing compatible at the same time. Two birds with one stone. This might not be the case, but it is potentially possible to a lesser or greater degree - after all they have the resources in house.

As for Crippling USB - FW at the time was much faster if we're talking early iPod days? USB is faster now, and FW has been given a back seat in the MacBooks, but this article http://brockerhoff.net/bb/viewtopic.php?p=2555#2555 does make some valid points as to why.
Apart from all the politics and positions regarding the choices made for Snow Leopard - the potential for improvement of the OS is larger with Snow Leopard, due to the features it will hopefully bring to the table (primarily for 2009 machines and beyond i'd imagine).
 
Apple should embrace the CELL processor

As IBM and co-workers have a solid roadmap concerning the miniaturisation of circuits, Apple could look afresh at the Cell approach with its recently acquired PASEMI team.


Otherwise, Microsoft with Windows 7, also running on the same standard Intel hardware, will be a real alternative.

An overhauled CELL, with a geometry which is less than 40nm, and with integrated graphics sub-elements, ARM core for instant up, etc., is the ideal platform, for personal computing and consumer electronics features, like e.g. movies, games etc.

Apple should talk again with IBM, thereby keeping Intel for their mainstream products.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back