O'Reilly Network    
 Published on O'Reilly Network (http://www.oreillynet.com/)
 See this if you're having trouble printing code examples


OS X Brings Unix Stability to the Mac

by Michael J. Norton
07/13/2000

Related Articles

Writing a Speech Recognition App. in Carbon

Connecting PCs to Apple's Wireless Airport

Mac OS X Terms and Definitions

I've always been intrigued by Macintosh hardware, ever since I owned my first Mac 512K. I fondly remember popping open the case and making mods for the 4MHz beast to run with a Motorola 68010 at a whopping 10MHz. For some reason my most creative coding has always been on the Macintosh platform. There is something about this little machine that inspires me to create. I can sum up my relationship with my Macintosh as a love-hate relationship. There are times when I truly love my Macintosh, and there are times when I truly hate it.

I abandoned my 512K, which is still lying around my house, and went over to the Intel side of the world, only to later make friends with a Centris 640 Mac on which I created more interesting code.

After another flirtation with an Intel machine, I picked up a 7500 PowerPC when Linux became available and fell in love with the Mac once again. As I look back, what drove me away from the Macintosh were the inadequacies of the operating system.

These OS inadequacies dampened my desire to purchase new hardware that I did find appealing. For example, rather than buying a Blue and White G3, I opted to upgrade my PowerPC. Why not? For a few hundred dollars I got my old 7500 to operate at 400 MHz with a G3 chip. It ran Linux perfectly fine, so there was no real reason to buy a new box -- even if it was an attractive aqua and ice gem with a drop-down motherboard. Besides, there were rumors surfacing that Apple was looking at a Unix kernel.

Horse of a different color

Superficially, when you migrated from Mac OS 7.1 to Mac OS 8.5 and then to Mac OS 9, there were no significant differences among the revisions. The user interface looked and felt the same. Sure, new advances came along, such as a Java runtime environment and better disk utilities, but there were no milestone improvements to speak of. The migration from Mac OS 9 to Mac OS X, however, will change all of that. OS X will be a major and long-overdue stepping-stone in Macintosh operating system architecture.

Mac operating systems prior to OS X used a "time-slice architecture," where every application is allotted time to the processor.

The details of the Mac OS X kernel are a little tricky to find but there's a great PDF document at Apple's web site, Inside Mac OS X: Kernel Environment, which reveals the internal workings of the new operating system. The information in this paper defines the significant differences between Mac OS 9 and Mac OS X. From a high level looking down, Macintosh operating systems prior to Mac OS X used a "time-slice architecture," where every application is allotted time to the processor. The applications in this environment are required to cooperatively share processor time. Furthermore, the memory is unprotected. That is, an application could write into critical memory space that may be in use by the operating system kernel. The result is the infamous bomb alert on the desktop with the button highlighted for restart.

Mac OS X brings to the table a preemptive multitasking system. This means the kernel schedules time to each (process) application and governs how much time it is allotted. The kernel will also assign address space to the application. The application will not be allowed to write outside of this without the kernel taking action. This protected memory environment will change everything for Mac users.

Enter Darwin

During the past three years, rumors were circulating about what the next generation Macintosh operating system would look like. There was no doubt that the underlying OS would have to be some flavor of Unix. Much of this speculation began in 1995 when Apple was perceived to be sinking, and it appeared that Sun Microsystems would purchase the floundering company and build the Sparcintosh.

Meanwhile, Steve Jobs was enlisted to help save the listing ship, and people began to speculate that his NextStep architecture would be used for the new operating system. And if those possibilities weren't interesting enough, off on the side was yet another group inside Apple looking at the microkernel of Linux, MkLinux to buoy their fate. Apple even went as far as providing developer releases of MkLinux on their web site up until early 1999.

Then an operating system called Darwin emerged from Apple. This OS is based on FreeBSD, 4.2BSDLite, and Mach 3.0, with much of the early work taken from NetBSD. A Mach microkernel is an abstract layer for porting operating systems. Darwin is Apple's kernel environment, which handles inter-process communication (IPC), I/O, memory management, and scheduling. So what does Darwin have to do with Mac OS X?

The microkernel, recall, is an abstract layer -- it's handling messaging and scheduling. It's not interested in user windows and mouse clicks. We have another layer higher up for this. Darwin does, however, include the command line interface of BSD, as does Mac OS X. On top of Darwin are more abstract layers, core services, applications, and a large portion of FreeBSD services, plus the Carbon window environment. This entire bundle of software abstractions is what Apple calls Mac OS X.

Seeing Aqua

Apple has made it perfectly clear that they are moving away from their classic Apple window architecture. The Apple menu bar has

Mac OS X pulldown menus display more of a Motif or X-window feel, but with Apple designer flair.

been replaced with application-specific menu bars. These pull-down menus give the environment more of a Motif or X-window feel, but with an Apple designer flair. The appearance of the new operating system definitely has Apple's graphic-designer market in mind. Icons are now 32-bit color and use alpha channels to allow for transparency. Window-specific dialog boxes are now sheets that appear from the title bar of the application window. These changes are covered in the document, Adopting the Aqua Interface.

Carbon development

The classic Apple event handler was based on applications cooperatively using the processor time. The new event-handling scheme, Carbon, is the adopted method for handling preemptive multitasking applications. To develop applications for Mac OS X, we'll require a few tools. Apple has provided an SDK that's capable of running on both Mac OS 9 and developer release Mac OS X platforms.

Legacy PowerPC owners should be aware that only true G3 systems and newer are capable of running Mac OS X.

Legacy PowerPC owners should be aware that only true G3 systems and newer are capable of running Mac OS X. If you're using a PowerPC, this shouldn't hinder you from developing applications with Carbon. I used a Macintosh PowerPC 7500 with a G3 ZIF XLR8 carrier card for playing around with the Carbon SDK. That being said, I eventually migrated over to a G4 so I could load a Mac OS X developer release image.

The latest version of the Carbon SDK is available for free from Apple Developer Connection. You are required to become a member to download the kit, but membership is free. Since Mac OS X utilizes FreeBSD, you can be assured too that a GNU development system will surface either from Apple or from an open-source developer.

In addition to the Carbon SDK, you'll need a supported development environment as well. Apple supports the Metrowerks Code Warrior Release 4 development system. The libraries in the Carbon SDK were built using this compiler. If Code Warrior is out of your price range, Apple still has its MPW environment available for free. MPW requires some work to get up and running, but it is usable.

Classic events vs. Carbon events

I'm probably dating myself here, but I needed to refer to a heavily dog-eared book by Scott Knaster, Macintosh Programming Secrets, Second Edition. This has been my long-standing reference on Macintosh programming. To quote from my Holy doctrine on Mac programming, page 83: "You probably know that almost every Macintosh application has a routine called MainEventLoop, and it's usually the heart of the program." A classic Apple event loop looks like this:

void main (void)
{
OSErr err;
InitGraf(&qd.thePort);
InitWindows();
TEInit();
InitCursor();
InitMenus();
InitFonts();
MyEventLoop();
}
void MyEventLoop(void)
{
Boolean gotEvent;
EventRecord event;
while(!bQuitApp)
{
gotEvent = WaitNextEvent(everyEvent,&event,0,nil);
if (gotEvent)
HandleEvent(&event);
}
}

Basically, the event loop executes WaitNextEvent continuously and retrieves events as they occur. The Boolean variable bQuitApp is set when the user selects to quit the application from a pull-down menu or uses the Apple-Q command. This is the classic way of handling events. This will run under the Carbon environment, but remember, it's not optimized for Carbon event handling. A Carbon application looks like this:

#define TARGET_API_MAC_CARBON 1
#include <CarbonEvents.h>
void main(void)
{
WindowRef window;
OSStatus err;
EventHandlerRef ref;
EventTypeSpec list[] =
{ {kEventClassWindow, kEventWindowClose },
{ kEventClassWindow, kEventWindowDrawContent }
};
InitCursor();
RunApplicationEventLoop();
}

The function RunApplicationEventLoop is part of the Carbon API. We don't write our own event loop as we did with the classic event handling. The header file CarbonEvents.h defines several event classes, such as kEventClassWindow, along with event types for each class. KEventWindowClose is an event type for class kEventClassWindow. The events we are going to handle will be called out in an EventTypeSpec list. The list contains only Carbon events defined in the header file. The classic Apple events are handled in a different manner.

The following code snippet demonstrates how to handle an Apple event, such as waiting for an event from the Sound Manager:

EventTypeSpec eventList[] = { { kEventClassCommand,
kEventProcessCommand } };

InstallEventHandler( GetApplicationEventTarget(),
NewEventHandlerUPP( MySndEventHandler ),
1,
eventList,
0,
NULL );

We need to instruct Carbon to pass a high-level event such as an Apple event to our own event handler routine. If you're familiar with classic toolbox coding, you'll notice that I used the call NewEventHandlerUPP instead of NewRoutineDescriptor. A UPP is a Universal Procedure Pointer, and these do behave differently under Mac OS 9 than they do with Mac OS X. You should consult the Carbon Porting Guide for further details. An excellent and simple example of Carbon event handling is provided in the Sample Code folder of the SDK, BasicCarbEvents. This example demonstrates how to open a simple window using the Carbon event handlers.

Better late than never

For years I put off purchasing a new Mac as I waited for a better operating system. Had Sun Microsystems purchased Apple a few years back, I might have bought a new Macintosh then, anticipating some flavor of Unix running on that wonderful hardware.

Personally, I think the outdated OS has overshadowed Apple's otherwise sterling achievements. For example, when the G4 was introduced, I was salivating at the opportunity to own a 450 MHz RISC system with a 128-bit processor instruction bus. Apple's propaganda was enticing, too -- own your own supercomputer.

But the issue of an outdated OS once again reared its ugly head. Watching Apple's highly sophisticated architecture getting burned by CISC-based Pentiums in 3D rendering seemed shameful. The G4, hardware-wise, is more than capable of besting an Intel PC for tasks like these. Once again, the hindrance is the current "classic" operating system.

With a FreeBSD architecture native to Mac OS X, it's likely that the tables will turn in these 3D computation benchmarks, as well as with other tasks. Just imagine the new hot software you can write for OS X. But what's even more mind-boggling is that an operating system developed back in 1976 (Unix) is probably what's going to restore the reign of Apple Computer. Had Apple started with Unix when it shipped the original Macs, it's possible the software icon, Microsoft, may have never become a household name.

Michael J. Norton is a software engineer at Cisco Systems.


Related Articles

Writing a Speech Recognition App. in Carbon

Connecting PCs to Apple's Wireless Airport

Mac OS X Terms and Definitions


Discuss this article in the O'Reilly Network Forum.

Return to the O'Reilly Network Hub.

Copyright © 2009 O'Reilly Media, Inc.