Apple moving Finder to Cocoa
At long last, Apple has rewritten Finder using its Cocoa development environment for Snow Leopard, according to a report.
(Credit: Apple)Apple has finally rewritten one of the most important applications in Mac OS X in its preferred programming environment, according to a report.
AppleInsider reports that Finder, the ubiquitous file management application in Mac OS X, has been rewritten using Apple's Cocoa development environment in advance of the release of Mac OS X 10.6, otherwise known as Snow Leopard. Finder remained a stubborn holdout tied to the Carbon programming environment as Apple encouraged internal and external developers to switch to Cocoa over the last several years.
Finder, as shown in Mac OS X Leopard.
(Credit: Apple)Apple hasn't released a ton of formal information about Snow Leopard, but it has emphasized that the operating system will mark the completion of Apple's march toward a 64-bit release. The company has also said that application developers won't be able to write 64-bit applications in Carbon, which seems like Apple's way of pushing Carbon holdouts onto Cocoa.
It's not that easy, however, to switch large applications from one development environment to another: Adobe Systems thought it would be able to write a Carbon-based 64-bit version of Photoshop, but had to delay its plans for a 64-bit version of Photoshop for Mac OS after learning it would have to switch Photoshop to Cocoa.
Snow Leopard is expected to arrive "about a year" after it was announced last June at the Worldwide Developers Conference, which gives Apple a lot of wiggle room to work out the kinks. The new version will also support the ability to create separate Mac OS X images on disk partitions or external drives, according to AppleInsider.
Tom Krazit writes about the ever-expanding world of Internet search, including Google, Yahoo, online advertising, and portals, as well as the evolution of mobile computing. He has written about traditional PC companies, chip manufacturers, and mobile computers, spending the last three years covering Apple. E-mail Tom. 
Good lord, isn't there enough of this whining on the political blogs?
Pfft.
Cheers!
- Sean
I have come up with several theories around Snow Leopard. Could it be the release that Apple finally makes available on generic Tier One OEM PCs?
It's not in their best interests to turn over OSX to the tender mercies of OEMs who more often than not cut corners and specs just to get a margin.
No.
There's a lot going on, and speculating at this point if you don't know anything - and you don't - is just acting the fool.
Sit back and wait.
In addition, things like ZFS read/write could have a huge impact on what Time Machine 2 offers. And let's not forget the main point of this thread which is a rewritten Finder. Surely you don't think they're simply going to make it look and work pixel-for-pixel like the current Finder, do you?
For developers, Apple's doing something rare: cleaning up the loose ends. And there's a lot of benefit for users when developers are cared-for. Also, I imagine that the Snow Leopard feature set will really help Apple in not only the "Enterprise" market -- where it may be more of a first or second step on a long march -- but it could give it a huge push in recapturing universities and other infrastructures where it's very popular at the user level and so already has leverage in the infrastructure.
John Siracusa at Ars Technica covered the implications of this pretty well last year: http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6
As for whether or not OS X is 64-bit, I think it runs in 32-bit on Core 2 Duo machines and only runs in 64 bit on the Xeon machines like the Mac Pro. I could be wrong about that though.
2) The Ars Technica article only touches on the subject, and mainly from a development framework standpoint. (Even one of the more technical articles at AppleInsider tries to stick to the Address space of 64bit and jumps over a lot of the technical issues facing Apple, and getting some of them flat out wrong when they reference how easy it will be or how it would compare to Vista x64.)
3) Snow Leopard is 'supposed' to be a full 64bit OS and 64bit kernel, but that is not set in stone, as moving OS X to a full 64bit kernel will require a lot of new drivers and kernel level changes that may be outside of what Apple will want users to go through. (Even Vista, MS had to force everyone to support 64bit drivers to get the Approved logo, or Vista x64 would have been left behind like XP 64 was.
If Snow Leopard does go full 64bit, look for issues and migration problems, like people saw from System 9 to OS X and users also see moving from XP/Vista x32 to Vista x64 - Although MS forcing Vista x64 support for logo requirements has made Vista x64 pretty painless and a good stepping stone so that Windows 7 will by default sell the x64 version more than the 32bit version.
It is kind of ironic that Apple claimed to have the first 'desktop 64bit computer', and to this day, OS X still isn't 64bit.
BTW...
64bit brings more to a computer than just a larger memory address space. There are 64bit registers and other internal optimzations that 'DO' make a difference when running at the kernel level of an OS. Vista x64 has less table tracking because of the 64bit space and also can speed up 32bit applications by shoving two memory read/writes into one and use the full 64bit chunk of RAM the OS allocated. (On average - especially gaming - Vista x64 runs 15-20% faster than Vista x32 if the computer has 1.5 or 2gb of RAM to make up for the extra RAM allocation overhead. - And yes this is even with 32bit applications running on the 64bit OS.)
So for Apple, shoving Snow Leopard to a full 64bit kernel is a gamble, as it could go well for users, like the Vista x64 crowd is seeing with better performance, or it could be a nightmare with driver issues and software migration problems. Apple has more control of the hardware and drivers, so in theory it should be significantly easier than what MS went through with XP 64 and literally forcing software and hardware companies to support Vista x64 if they want the logo or any certification.
Summary: 64bit is better, and Apple could be giving you something really good if they iron out the kernel level driver and other core migration issues needed for a full 64bit OS.
Why in the hell would Apple want to do that!
Think of the nightmare of having to write a GUI abstraction library that does the same thing in C++ and Win32 API, as well as in Objective-C and Cocoa. Not only that but imagine the task of having to port Photoshop from using Carbon to Cocoa. Not fun.
I think the next release of photoshop will mark a big moment for Apple, where for the first time Photoshop will be better on Windows than on a Mac. And it's all because Apple has decided to deprecate Carbon.
I think we're seeing Apple move more and more away from their core and more towards consumer electronics.
I just bought Adobe CS3 via upgrade in late August = $606.00USD.
In less than 30 days they sell CS4.
All it will cost me is another $606.00USD.
I called in to Adobe to check = NO MERCY.
At least Apple knows better than to pull a stunt like this.
Adobe: Dance with the one that brung you.
Apple is a much better dance partner.
-MS took hell for pulling support/features from Vista before it was even released, imagine if they did what Apple is doing and canceling promised features of a shipping OS and key OS development frameworks.
On a side note, Adobe doesn't like to play nice either and still tries to strangle the market with over the top pricing and degrading software quality. (Flash's performance is scary bad in recent releases, let alone their Acrobat reader.)
Adobe doing 64bit versions on Windows was a pretty easy decision for them, as the API migration Microsoft designed is barely more than just recompiling for 64bit, no framework changes, no dead end API sets. Even 16bit Win3.1 applications from 1990 can fairly easily be moved all the way to 64bit because of the agnostic nature of the Windows API set. (Vista's new APIs with .NET 3.x will be the 'major' move for developers in the next 5 years, and even it can be mixed and matched with Win32/64 APIs as developers are already doing. Microsoft's own Expression Design is a Win32/64 core with a new Vista WPF interface, which is pretty cool considering the massive difference between the two API frameworks and how easily this is for developers.)
(Sorry got off on a developer ramble.)
I'm a little doubtful of that. Adobe still has to contend with both Microsoft and Apple coming out with (somewhat) competitive products. Also, who knows what rewrites will be in the works for Windows 7 compatibility?
I'm not saying a port would be painless, just that Obj-C is far more flexible for cross platform dev then some people think.
No. It's not much different from Jimmy Page raising his Gibson guitar in the air during a rockin' moment. Why didn't he give equal time to Fender or Rickenbacker or [whoever]? He's simply celebrating a choice he prefers, which flamboyantly gay people could understand. Not that Apple is flamboyantly gay, or that being gay is wrong, but...
Jimmy Page totally rocks!! And Apple makes a hell of an OS. The End.
Apple wrote Finder in Carbon specifically to showcase Carbon. Writing a major system in Carbon also allowed Apple to "shake out the bugs" in Carbon. It was an "eat your own dogfood" exercise.
Today we of course see it differently; Carbon became the API for "ported apps" (both older MacOS apps but also Windows apps) while Cocoa has become the preferred API. But that wasn't the messaging when Carbon first came out.
Apple quickly realized that maintaining four separate "first-class" APIs was a really dumb idea. Lots of wasted duplicate efforts, interoperability problems, etc. For awhile they tried to "fix" this by layering parts of Cocoa on top of Carbon. The positioning became nuanced with Cocoa becoming more of the "GUI-layer" API, while Carbon more the "low-level" C++ API. This half-assed layering just created a bigger mess.
So eventually Carbon became deprecated, Java (as a first-class API) was thrown out in the cold, and the BSD layer was left for whatever can't be done elsewhere (e.g., Cocoa couldn't do 64-bits, so you had to write your 64-bit code in BSD.)
But again initially Carbon was a "first-class" API and hence Apple had no qualms writing Finder in Carbon.
The big problem for Apple in the future is that everyone is moving away from C-based APIs (be it C++ or Objective-C), while Apple is going to be "stuck" with Objective-C MacOS's primary API. We see this with the proliferation of managed, virtual-machine based environments -- especially Java and .NET but also dynamic languages in general.
That's why you see Apple kludging with things like the Python-Cocoa bridge (PyObjC). Microsoft doesn't have this problem because they were able to concentrate on the CLR. You can run managed C++, C#, VB, Python, Ruby, etc., as first-class CLR languages without the need for bridging.
The Python/Cocoa bridge was Apple's efforts to accommodate Python bridging to Cocoa... Microsoft has _no_ such native analog or bridge for Python, Ruby, or Perl - any bridges out there for Windows/VS are written by volunteers and are swaged-in, with little-to-no efforts or help at all from MSFT. Also, remember that MSFT's efforts at J# was more an attempt to destroy Java than to accommodate it (which in turn was an attempt that failed miserably).
You too easily confuse ancillary languages (e.g. Python) with core languages. That trick may work with the typical user types, but you're not fooling anyone in the programming world. You also forget that Apple has easy gcc integration within Xtools - gcc can accommodate pretty much any language in existence.
Funny you should bring up VB - MSFT is desperately trying to kill it, pushing world+dog to .NET instead. 'splain that one, big guy.
Finally, your statement that "everyone is moving away from C-based APIs" is laughable at best, and a subjective opinion that lacks any factual basis.
/P
Your ignorance is stunningly amazing.
1) Apple would not write Finder in Carbon if at that time Carbon was simply a bridging library set. That would just be plain stupid. Or maybe that's what you're saying, Apple is stupid? Besides, by 2005, OSX was already four years old.
2) Python and other languages do not have "bridges" to Microsoft APIs, *because they are not required*. They can run as first-class CLR languages, unlike on MacOS.
3) Python analog for Microsoft written by "volunteers" with no help from MSFT? You should be ashamed by your ignorance. Any pythonista can tell you that of the most popular Python environments -- IronPython -- was written by Microsoft. http://msdn.microsoft.com/en-us/magazine/cc300810.aspx
4) MSFT trying to "kill" VB in a push to .NET?? What idiotic comment is that? VB *is* one of the MAJOR .NET languages. Not only VB.NET 2008 just came out but the upcoming VBx (aka VB10) will be a large feature of Silverlight 2.0.
I know you're an Apple apologist, but really, this is shocking even for you.
I'm a little confused by your #2. I think you are confused by the term "bridge". Most other folks would call it a framework. You know like ironPython is a framework for .Net, Jython is a framework for the Java platform, PyGtk is for Gtk, PyKDE is for KDE, ad nauseam. So you are completely wrong about Python not needing a bridge to the Microsoft API, it's called ironPython and you mentioned it in your comment.
As for #4, I've been a windows developer for longer than I care to admit and I can say with conviction that Microsoft always gave me the impression that they would like to phase Visual Basic out in favor of C#. I'm glad that Microsoft has decided to continue to support VB, but I see it as a sign that they underestimated how embedded VB has become within their enterprise market share. I've always questioned Microsoft's logic behind the initial phase out, since some people where moving to Java (and its lack of vendor lock in) instead of sticking with Microsoft and its C#.
You seem happy with working in a Microsoft environment and more power to you. Maybe one day you'll venture out and try better technologies...
will keep leopard!
@mbenedict: "everyone is moving away from C-based APIs"? That's one of the most laughable things I've ever heard. The rest of the paragraph also highlights how little you know about Objective-C and Cocoa. I mean: "We see this with the proliferation of managed, virtual-machine based environments -- especially Java and .NET but also dynamic languages in general. "
The fact that you would consider Java dynamic is ridiculous. Java is incredibly rigid compared to a language like Obj-C. Obj-C is a runtime based language, Java is a compiler based language. There are things you can do in one or two lines of Obj-C code that the Java compiler would complain about and so you have to write new classes in order to work around it leading to many more lines of code which adds complexity to your system.
I suggest picking up a book on Cocoa and learning to code in it. Then you can come back and make some informed statements about Mac development.
The language grammar, the language's runtime environment, the language's libraries, OS libraries available to the language and most importantly what problem is being solved - all need to be considered when discussing this problem.
Java was dumped. Its runtime is heavy. It has poor system integration. And Steve has no control over it. If Apple did a MS like solution, poeple could write to Cocoa (not Java Cross-platform Runtime) using the Java grammar. But the language features of Java is smaller than Obj-C++.
C/C++, despite what Benedict says, are still huge. Strousup is focusing C++ for systems programming. I would never want to write another UI or dynamic system in C++ (given its runtime)! But the language features and upcoming library (Boost) are extremely powerful. I love that I can take advantage of C++ within Obj-C++.
Obj-C++. There is Cocoa. It is by-far the best application framework out there. To really take advantage of it you need the language features of Obj-C. That is one reason why Apple does not want to support the other languages that are not smalltalk-like.
Carbon is a C-based Facade for accessing MacOSX libraries while looking like MacOS9. MS does not abandon old APIs. Apple always has. There is nothing cross-platform (besides chunks of the Quicktime library) about Carbon. If Adobe was smart they already have clean a Mac/Windows/Model separation in their code. Time to update the Mac UI!
So why did Apple rewrite the Finder in Carbon? It could have been political (Please don't abandon us Adobe). It could have been a time saver - huge reusable chunks already written to the Carbon API. It could have been internally political - some manager had a personal investment in Carbon. I doubt it was because Steve wanted it in Carbon. Remember when MacOSX was introduced (and Apple was still in the Doghouse) Steve told everybody that the MacOS9 APIs were going away. He had to switch that position rather quickly. They ain't in the doghouse anymore.
Furthermore, saying that Java (the language) is compiler-based while Objective-C is runtime-based is just plain DUMB and totally misses the point. Maybe you're awkwardly trying to say that Objective-C has dynamic typing instead of Java's static typing, so I'll give you the benefit of the doubt , but that's still misses the point.
The point remains that the rest of the world has moved away from C-based APIs for application development , while Apple is going to be stuck in it.
As far as picking up "a book or two on Cocoa" -- hey get a clue I code (and audit code) on the Mac (and MS and Unix) on a daily basis as part of my job. I've written more Carbon and Cocoa apps than most readers here combined.
And while you may have written many Cocoa apps your comments here either show a lack of understanding of Cocoa or a need to over generalise and wrongly classify Cocoa and Obj-C in order to make a flawed point.
I understand Cocoa just fine thank you. Static vs. dynamic typing in this case is irrelevant. Objective-C has dynamic typing, but no matter how you slice it, Objective-C is still C-based and suffers because of it.
Some examples:
1. Memory management is largely manual and error prone. Like other Mac programmers I've spent countless hours debugging errors caused by retain / release problems, and often the culprit lies deep inside Apple's own frameworks! If even Apple can't get this right then you can understand the scope of the problem.
Yes Objective C 2.0 adds garbage collection, but this breaks compatibility. Programs using GC even in "backwards compatibility mode" will NOT run on anything but Leopard, which is bizarre and illustrates yet another weakness with a C-based API. If you're writing commercial software today, GC is not an option. If you're writing apps for the iPhone, then GC is not an option either.
2. Buffer overflows, pointer arithmetic issues, etc. All the "C" evils remain in Objective-C. Not just to cause programs to crash, but all the associated security issues as well (allowing arbitrary code execution, etc.)
3. Poor optimization. Objective-C is slooow, in many instances slower than, say, Java. Being a strict-superset of C means most modern optimization techniques can't be used. Want JIT-based runtime branch optimization? Sorry, no can do. Dynamic typing just makes this even worse because the compiler can't do many static optimizations either. Here Objective-C takes on the worse of both static and dynamic worlds.
4. Poor interoperability. The fact that we have Carbon vs. Cocoa at all shows how bad and wasteful C-based APIs are.** You have two largely-incompatible interfaces for two primary C-based OO languages (I'm oversimplifying a bit.) In a managed enviroment like .NET or Java (as in the JVM), you can code in many different languages all sharing the same types and runtime and libraries. Compiled vs interpreted, static vs dynamic binding, early vs late typing, etc., doesn't matter in a VM world.
Lastly, look at the software development world today. On the server-side the battle is .NET vs Java vs dynamic languages (Python, Ruby when not running on top of .NET or Java.) On the web (and spilling into the desktop) it's AJAX vs Adobe AIR vs Silverlight.
NONE of these are Apple technologies. Bad news for Apple. Even on mobile devices the main battle is Flash vs. Java (be it Java-ME or Google's Android platform.) Apple knows this, which is why they don't want neither Flash nor Java on the iPhone... losing proposition for them.
The vast majority of coders I know who have a Mac don't have a clue about Objective-C besides maybe doing a tutorial or two. Instead the vast majority of them are Java programmers -- they fire up Eclipse on their Mac and deploy to Tomcat or Weblogic or whatever on Sun or Linux. They might think Cocoa is "neat" but quickly get frustrated with IB and turned-off by the prospect of going back to a C-based language.
** I'm talking about application development, not systems programming.
- by Martin Pilkington October 21, 2008 3:15 AM PDT
- @mbenedict: I'd say being C based is a huge advantage for Obj-C as you get huge benefits such as access to the vast range of C APIs and the power that C provides (you list some of these as disadvantages but they are incredibly powerful if not used incorrectly). Now, to address your issues:
- Reply to this comment
-
-
- by sanjayb October 26, 2008 3:31 PM PDT
- @Martin
-
-
(39 Comments)1. Yes, memory management is manual and being manual it is error prone. But it's not like it is complicated. And if there are any problems with leaks then you just fire up Instruments and it will help you track them down. One of my apps was ballooning up to 300MB of RAM if left open for a day. Spent 30 minutes in Instruments tracking them down and fixing the leaks and now it rarely goes above 25MB.
Yes there are memory leaks in Apple's APIs, but in that case you can just file a bug and they'll fix the leak, bug generally leaks in Apple's APIs are rare due to their widespread use.
And yes, GC can only be used on Leopard, but the same goes for Core Animation, Image Kit, the rest of Obj-C 2.0 etc. Apple doesn't bother porting new technologies back to old versions of OS X because there's no technical nor financial incentive for them to do so. It complicates things for their developers and reduces the reasons for people to upgrade.
2. Yes, those problems still exist, and yes the standard practices for securing them are still valid.
3. You got some benchmarks for that? Obviously Obj-C will be slower than some languages because of the fact that it does a lot more in the runtime. Of course you are sacrificing a bit of performance for a huge gain in flexibility, clarity and brevity of code. I'd rather write less code, cleaner code and not feel like I have one hand tied behind my back than gain the few ms of performance. And if I needed that performance I'd drop down to straight C. And of course if you need to optimise Obj-C then there are plenty ways to do it: http://www.mulle-kybernetik.com/artikel/Optimization/index.html
4. Actually the reason for Carbon and Cocoa existing is because they came from two backgrounds, like Win32 and .Net. And Cocoa isn't bound just to Obj-C. There are bridges for Ruby and Python officially supported with other languages with unofficial bridges. And on top of that there is MacRuby, which is Ruby but built upon the Obj-C runtime (which acts as a VM in a way) so that it uses the Ruby syntax but native Obj-C types with no need for converting over the bridge.
Now, looking at your software development landscape, I agree that it is .NET vs Java vs Dynamic languages on the server and the web is AJAX vs AIR vs Silverlight (vs Flash). And yes Apple doesn't own any of these. I would say though that they have a large stake in them. AJAX for example, is heavily pushed by Apple. Apple doesn't feel the need to build their own system when AJAX is powerful enough. Instead they build the best rendering engine with the fastest Javascript interpreter on the web, which is used in Safari on the Mac and PC, Google Chrome, Android, Nokia Phones and the iPhone and iPod touch.
And on the mobile it has been Flash vs Java. The problem Apple has with these technologies on the iPhone is this:
Flash - Adobe seems to refuse to optimise Flash for OS X. If it runs like crap on the Mac then it won't do well on the iPhone. There's also the issue of multi touch requiring different input formats and unless flash developers are going to re-write their sites/apps for the iPhone then it's going to be a 2nd class experience
Java - Java is poor. It is an awful language with even worse APIs that weren't designed as much as they were just fired out of a shotgun with the hope that something workable would appear out of the mess. To go with APIs that push you away from making good user experiences you have the fact that Java has an absolutely huge pool of developers, being one of the main languages taught in universities and schools. This means it is where all the mediocre developers are.
Now it may sound snobbish but Apple doesn't want mediocre developers on their platform. They want the best developers making the best apps with the best UI frameworks around. If these developers don't like the power given to them by IB and prefer to write code instead, or they're incapable of using a C-based language then Apple doesn't care, as there are better developers out there who will see the huge benefits to IB and are fine working with a C-based language.
Java - Java is poor. It is an awful language with even worse APIs that weren't designed as much as they were just fired out of a shotgun with the hope that something workable would appear out of the mess. To go with APIs that push you away from making good user experiences you have the fact that Java has an absolutely huge pool of developers, being one of the main languages taught in universities and schools. This means it is where all the mediocre developers are.
You have no clue on what u are about. You obviously haven't programmed in Java. Some of the best programmers I know program in Java. If Java is a poor language why is it so widely used? I would hate to see what API's you would come up with.