By Prince McLean
Published: 08:00 AM EST
Smooth Transitions for Users, Rocky for Developers
In 1989, Apple began touting the release of System 7, encouraging developers to produce "System 7 Savvy" applications without providing them the tools to actually do this. System 7 introduced a full color interface and support for lots of end user features, including multiple concurrent applications.
However, while Apple repeated its admonitions to get ready for System 7 at three WorldWide Developer Conferences from 1989 through 1991, Apple itself didn't have a compatible version of MPW to run on the new system when it finally arrived. This forced developers to use MPW under System 6, then boot into System 7 to see if their apps worked, as Will Flor notes in Development under System 6.
In 1991, Apple announced plans for another transition to PowerPC. While it eventually provided PowerPC development tools in MPW, by then Apple's own development tools had long been considered overpriced and underwhelming. Symantec's Think C had taken the lead as the standard environment among most 68K Mac developers.
However, Symantec didn't offer PowerPC support, leaving Mac developers trapped between dead tools and Apple's expensive MPW. Metrowerks, an independent Canadian developer, began work on its own PowerPC development tools and was ready to release them under the name CodeWarrior in 1994, just as PowerPC Macs were about to go on sale.
Without Metrowerks, Apple's transition to PowerPC may have failed completely, just as the company itself was getting hammered by the growth of Windows and its own work on a System 7 replacement was beginning to fall apart. Apple continued to support MPW through 2001, but most developers rapidly transitioned to Metrowork's CodeWarrior (below).
Jean-Marie Hullot had visited Apple in the late 80s to show off his ideas for Interface Builder, a new development tool for creating a palette of interface elements which could be graphically arranged, then attached to functions. Interface Builder promised to make the development of graphical applications far faster than the existing tools offered by Apple or third parties.
After deciding he didn't want to work at the corporate environment of Apple, Hullot shopped his idea around and ended up demonstrating Interface Builder (below, running on NeXTSTEP) at NeXT, where Jobs hired him immediately. Hullot became NeXT's Chief Technology Officer and worked on both Workspace Manager and the underlying Application Kit development frameworks that shipped as part of NeXTSTEP in 1988.
NeXT supplied Project Builder as its development coding tool, and centered development around Objective-C, a language developed by Dr. Brad Cox. Objective-C enhanced C in subtle ways to deliver an easy to use, component-based approach to development. Rather than writing everything from scratch, object-oriented development seeks to reuse existing components by adding or changing features and behaviors as needed. Objective-C also strongly influenced the development of Oak at Sun, which was later branded as Java.
NeXT organized dynamically loadable library into frameworks called kits. The Application Kit presented everything in the graphical interface with an objective interface; the Foundation Kit provided a similar abstraction to lower level tasks such as memory allocation, file access, and thread management.
NeXT's development tools and the frameworks they used were the main value NeXT added; they attracted attention from a wide variety of serious developers, including the CIA, investment firms, academic researchers (including Tim-Berners Lee in the development of the Web) and high performance developers like id, which chose NeXTSTEP as the development tool for its DOOM World Builder. When NeXT gave up on selling its own hardware in 1993, it delivered a port of NeXTSTEP running on standard PCs, and later on HP's PA-RISC and Sun's SPARC workstations.
NeXT later delivered its development and deployment tools separate from its underlying operating system, allowing "OpenStep" to run on top of Sun Solaris and Windows NT (below, running Project Builder). This portability and sophistication caught the attention of Apple in 1996, when it was clear the company's own in house development efforts were in shambles and needed outright replacement.
Apple's NeXT Tools
Apple quickly ported NeXTSTEP to PowerPC, thanks to preliminary work at NeXT to deliver a new generation of PowerPC-based NeXT computers shortly before it pulled out the hardware business entirely. After outfitting it with an appearance derived for the ill-fated Mac OS 8 Copland project, Apple shipped the results as the Rhapsody developer preview.
Rhapsody's Project Builder (below) supported the development of Yellow Box (OpenStep) applications that could be deployed on both Rhapsody for Mac, Rhapsody running on PCs, and Windows NT PCs running the Yellow Box runtime. Apple also planned to investigate reviving the ports for Solaris, and would not have have much trouble delivering a commercial Yellow Box on Linux. GNUStep had already begun development of an OpenStep implementation for Linux.
Interface Builder for Rhapsody (below) showed off the drag and drop simplicity in rapidly creating graphical interfaces for new applications using Yellow Box.
Back to My Mac
Mac developers didn't want to rewrite their applications to run on Rhapsody using the Yellow Box, however. Instead, they insisted Apple add support for existing Mac code written to the classic System 7 application programming interfaces.
This required a complete re-architecture of how development would work, and the result was a new strategy designed to sell Mac hardware rather than to solve the world's incompatibility problems between platforms. NeXT had already tried to push OpenStep as a open specification for delivering cross-platform compatibility on any operating system, but enthusiastic support from partners came and went as they became distracted by other subjects and strategies.
After realizing that it wouldn't be able to convince the world to adopt OpenStep under the new name Yellow Box, Apple developed Carbon as a way to port existing Mac code to run on the new system with minimal effort, leveraging work already done to make QuickTime (and the underlying QuickDraw) run on Unix. In order to call Foundation from both Carbon and the new Cocoa (a subset of Yellow Box), the system had to change from an object-oriented Kit to a procedural C library, called Core Foundation. Along with the removal of Display PostScript, this destroyed compatibility with the former OpenStep specification, and rendered Yellow Box an obsolete technology, as described in
Cocoa and the Death of Yellow Box and Rhapsody.
Core Foundation and the CFLite Skirmish
As Apple worked to release the core OS of its new system as an open source project, it found that portions of the new Core Foundation would need to be opened up as well. The IOKit needed the ability to handle plist files and CFRunLoop functionality, but the IOKit was also part of Darwin. That forced Apple choose between opening up its Foundation technologies, or implementing a separate way to perform these tasks.
The Foundation and Application Kit developers at Apple are not interested in giving away the company's core technology frameworks as open source code. Mac OS X software engineering lead Bertrand Serlet initially insisted that the IOKit developers would have to roll their own Core Foundation-like functionality. Apple's Core OS team had been pushing the concept of open source as fair play upon the rest of the company, but nothing in Apple's XNU kernel--including portions of BSD--had any obligation to be released.
After some convincing, Bertrand agreed that the IO team's case made sense and allowed the team to split Core Foundation into two libraries, Core Foundation proper and CFLite. The split also solved another serious internal build problem for Apple: when a new image of Mac OS X was built, 1500 projects had to be built with it. They are all built in ordered layers, but IOKit is a bit odd in that it relies on BSD, Kernel, and Core Foundation. That means it must be built after Core Foundation, but Core Foundation itself also depends on the IOKit. This circular dependency was unacceptable to Apple's Build and Integration group and would make it impossible to build a complete image.
CFLite was the part of Core Foundation that IOKit depended upon and did not in turn depend on IOKit. Thus the build order became: XNU kernel, LibSystem (BSD user), CFLite, IOKit User, then Core Foundation and the rest of the system. CFLite was included as open source in Darwin, and serves as a way to share some low level Mac OS X conventions on software designed to run cross-platform.
return to previous page
