|
In 1984, when Apple showed that 1984 won't be like 1984, the Macintosh shipped with a set of APIs, or advanced programming interfaces. These APIs gave the developers the ability to create applications using a set of functions and widgets (graphical elements) that enabled them to more effectively focus on programming and not on messing around with re-inventing the wheel.
Now, every platform has a set of APIs. Without them, it would be veritably impossible to get any developer to jump on your OS's bandwagon and create software for the platform when it knew it would have to invent the wheel just to be productive. And the Mac's Toolbox was a great piece of engineering for the mid-80's.
The only problem was…well, in 15 years or so since the Mac's toolbox was initially written, not much has been added to it from a plumbing standpoint. Sure, plenty has been added, such as color and multiple screen resolution settings, and laptop support, and tons of other stuff, but the basic one foot in front of the other programming techniques are still in effect. In short, the world passed the toolbox by, and Apple's developers were very frustrated.
Every time a big problem came up, such as a need for multi-threading, or running multiple applications at once, Apple gave developers roughly but not completely what they wanted. For instance, in these two cases, Apple have developers a Thread Manager API for multi-threading, and the Multi-Finder (or these days, the plain ol Finder) for multiple applications open at one time.
But after time, adding features without addressing some of the reasons the platform was starting to fall behind others started to catch up with Apple. Their core industries of education and design were still relatively strong, but were weakening by the day.
Now, in 1995, Apple purchased NeXT and promised Rhapsody, the next-generation Macintosh operating system which would revolutionize the platform and bring modern features to the aging platform. It would be comprised of the YellowBox, which would be the next-generation development toolset, and the BlueBox, which would allow Mac users to run their old Mac apps in a MacOS 8 "virtual machine" of sorts.
The backlash against this new plan, which effectively meant that all new application development should be in the unfamiliar Cocoa made large developers very unhappy and to some degree imperiled Apple's immediate future in the eyes of developers uncertain as to whether they should join the Mac developer community. Which do I program? Yellow or Blue?
In time, the Rhapsody strategy (which was very popular for the most part with YellowBox developers) was identified as a failure and was replaced by a much more ambitious MacOS X operating system.
While MacOS X would feature a number of new technologies, the most important for this discussion is a very important announcement for long-time Macintosh developers: they would get their wish. They too would enjoy the wonders and splendors of a modern, multi-threaded, multi-tasking, memory protected development environment.
The annoucement of this new set of APIs came at MWNY 97, where Apple iCEO Steve Jobs announced a new technology which was as important a technology as the original Macintosh itself. The name of this "new" technology was Carbon, and Jobs explained Carbon as "the building block of life."
Now, don't get too antsy there. Carbon has nothing to do with biotechnical relays or any of that fun stuff you would have been getting used to on ST: Voyager. Simply, Carbon is a modernization of the old Mac toolbox for the 21st
century.
When Apple took a step back from Rhapsody and thought about the way developers create applications, they found that developers were only using a fraction (a large fraction, but still only a fraction) of the Mac APIs. Some sets of programming interfaces were simply outdated, others replaced by other technologies but never removed, and some were just plain ol' ugly and needed to be taken out back and dealt with with Uncle Jimbo's shotgun.
So, Apple looked at the 8000 Mac API functions, cut a bunch of them, added some more, and decided that the whole thing needed to be made 21st
century ready. To do this, Apple needed to capitalize on the new operating system it was crafting and its specific advantages, namely memory protection and multi-threading.
Carbon is the end result of all of this work. According to Apple, Carbon will be for the most part fully-reentrant (a must for multi-threading and to a degree, multi-processing), and will be able to capitalize on nearly every new technology there is in MacOS X.
And one of the best parts of all about Carbon is that it isn't MacOS X exclusive. Yes, it runs on MacOS X, but it also will run on any Macintosh computer running MacOS 8.1 or higher. The only downside to running Carbon apps on pre-OSX computers is that you will lose most all of the modern functionality in Carbon, which is delivered by MacOS X's UNIX underpinnings and other related technologies.
So, what does that mean for the everyman developer? Great things, of course. Those applications that in the Rhapsody scheme would be relegated to second or third class status will now be equal partners with Cocoa, and you won't have to rewrite them in Cocoa.
Apple estimated that about 85% of all well-programmed Mac apps are Carbon ready, which means that they have ensured a great deal of backwards code compatibility. Apple estimates that it should take a good team of developers between 2 weeks and 2 months to Carbonize their apps, depending on the size of the project and the different Carbon workarounds developers must use to abandon non-Carbon calls. Of course, this time will vary greatly dependent on the speed and skill of the programmer(s) involved, and the complexity of the project at hand.
For the most part, the important APIs have stayed almost completely intact and unchanged (from the programmer's POV anyway). QuickDraw, OpenTransport, OpenGL, Navigation Services, and QuickTime, to name a few, are almost completely the same, yet offer a huge upside on MacOS X when used effectively. This level of backward code compatibility is a huge asset for Apple in its push to keep the users it has, and bring more into the community.
However, there are a number of technologies that have met their deaths in Carbon, such as OpenDoc and OpenTransport.
Wait, you say. OpenTransport is mentioned in both places…what gives? Well, the short answer is, Apple has decided to go with BSD UNIX sockets instead of Mentat streams (OT) for the networking for MacOS X. However, since all pre-OSX systems use OT, and many of the popular applications for the Mac use OT already, Apple felt that it would be prudent to include an Open Transport compatibility layer for Carbonized applications. This way, years of development wouldn't be abandoned.
The positive effect of this is two fold: one, Apple can get quality Carbonized apps to market as soon as possible, and they can also keep years of development from going down the drain which would in turn alienate the developer base.
While this layer exists in the now, Apple wants developers to use BSD sockets in the future. |
