TweetFollow Us on Twitter




[IMAGE p06-22_Gough_text_html1.GIF]

Threads are a great way to improve the performance and simplify the design of programs. Apple's Advanced Technology Group developed a Threads Package to implement this programming technique on the Macintosh. This article explains how you can use this package to incorporate threads in your own code.

The idea for the Threads Package arose during the design phase of some scientific visualization software, when we discovered that some of the applications we were working on needed a way to juggle several simultaneous activities. It quickly became clear that the Macintosh run-time environment posed some serious obstacles to anyone wanting to implement threads on the Macintosh. With some effort, we were able to come up with workarounds that made the use of threads with the Macintosh OS relatively painless.

These workarounds are the main subject of this article. After briefly introducing the purpose and mechanics of threads in general, the article presents some specific details of the Macintosh threads implementation as it currently stands. A summary of the functions in the Threads Package appears at the end of the article. The Threads Package itself and several simple example programs can be found on the Developer Essentials disc for this issue.

The Threads Package was developed as a means to an end, and it's by no means the last word on threads for the Macintosh. We welcome any suggestions you may have for improvements.


Suppose you want to write an AppleLink ®-like communications program. You'd like to write the program so that while it's downloading a file, it can also print an existing file and allow the user to write a new message. A typical program can perform only one of these functions at a time, displaying the watch cursor until the task is completed. What's needed is some technique for allowing the program to perform these tasks concurrently.

Programmers have often tried to achieve concurrency through the use of idle procs. For your communications program, for instance, you could write the downloading, printing, and text entry tasks as idle procs. While the download procedure is executing, it could regularly call a printing idle proc to send a few lines of a message to the printer. The download procedure could also periodically call an editing procedure to allow the user to enter text for a new message in a window.

But think of the tremendous effort involved in writing the program so that it can switch among these tasks. Every task would have to save variables each time it returns so that it could resume where itleft off. Most complex functions would not be able to contain deep levels of nesting because that would make it impossible to freely return to the caller at any time. In fact, you'd have to divide most functions into inconveniently small chunks so that you could juggle between them. The net result is that the modularity of your program would be destroyed, and you'd have a tremendous programming headache on your hands.

Threads are a much better technique for achieving concurrency than idle procs. When your program uses threads, it's like a mind that can have several trains of thought simultaneously. A program using idle procs, in contrast, is like a mind with a single train of thought that must constantly interrupt itself to attend to side issues.

Note that there's a difference between multithreaded programs and multitasking systems. Multitasking is the ability to run more than one application at once, but each application can still only do one thing at a time. In other words, concurrency is happening at the system level. A multithreaded application performs concurrent tasks within the same program; concurrency happens at the program level. Of course, it's possible to have a multitasking environment in which threaded programs run.


When writing multithreaded code, you must let go of old ideas about how the machine executes your program. Instead of a single program counter marching through your code, in a sense you now have many. While the idea of multiple program counters may sound complex, you don't have to relearn programming. You just need to be aware that the main train of execution in a program is itself a thread and that all threads must relinquish control to each other. You also have to remember to share globals and heap objects that you used to access exclusively.

Here's a sample program that shows how simple it is to use threads. The program is a modified version of the ever-popular SillyBalls. Unmodified, the program opens a window and draws colored balls into it until the main event loop detects that the mouse button is down. This new version forks a thread that beeps while the balls are being drawn.

    ThreadHandle beepThread;


/* The InitThreads call initializes the Threads Package, converting
   the original thread of execution into a swappable thread. */

    InitThreads(nil, false);

/* This code forks a thread that beeps 30 times, and then quits. */

    if (InNewThread(&beepThread, kDefaultStackSize))
        long i;
        for (i=0; i<30; i++)

/* Here's the main event loop. The only change is the new call to
   Yield. */

        } while (!Button());

/* This call to ExitThreads waits for all threads to die before allowing
   the program to terminate. */


The InitThreads call is made at the beginning of the program. It initializes threads and converts the original thread into something that can be swapped by the Threads Package. Once this call is made, you can fork other threads.

In this example, execution from the original thread enters the InNewThread procedure. Two threads leave the procedure, but at different times. The original thread goes in and is cloned before coming out. A new thread now exists, but it hasn't started execution yet. InNewThread tests whether the current thread's ID is that of the new thread, beepThread, and returns a Boolean indicating the result of this test. It's essentially supplying an answer to the question "Am I running the new thread?" Since the original thread is still the current thread, it returns from InNewThread with a value of false, thus skipping over the code contained in the IF block. It continues execution by entering the main event loop, drawing balls, and calling the Yield function. Each time it calls Yield, it politely gives control to other threads that may want time to execute.

On the first call to Yield, the newly cloned thread returns from the call to InNewThread with a value of true, indicating that this is the new thread and not the original. The new thread enters the block of code associated with the IF statement and begins executing the loop, which beeps and yields 30 times. Each call to Yield exchanges control with the main event loop. The new thread lives out its life within the confines of the IF block. After completing its task, it calls EndThread and dies.

The conditions for terminating these two threads are different: the beeping thread ends after 30 iterations; the original thread ends when the user presses the mouse button. The call to ExitThreads at the end of the program ensures that all threads have completed before the program terminates.


With multiple threads running around in your program, it's possible for them to get in each other's way. The Threads Package provides a semaphore mechanism to help you manage this problem. The problem occurs when two threads compete for a resource. Two threads that are executing at the same time may each want exclusive use of the same device, file, or memory location.

To deal with this situation, you assign a semaphore to control access to this resource. Then, when you write the thread that uses the resource, you always make sure that the thread "grabs" the semaphore. After you're done with the resource, you "release" the semaphore.

What happens if a thread tries to grab a semaphore that has already been grabbed? The thread goes to sleep, waiting in a queue associated with the semaphore. When the semaphore does become available, the sleeping thread wakes up with control of the semaphore, completely unaware that it had to wait in the queue. It continues executing code as usual, and releases the semaphore when it's done, thus giving other threads an opportunity to use the resource.

Below is a small example program that demonstrates the behavior of semaphores. It's very similar to the first example, except that the beeping thread grabs a semaphore before beeping 4 times and then releases it. A call to Yield was inserted within this inner loop just to demonstrate that even though there is a call to Yield in the loop, no balls are drawn during this time. This is because the code that draws the balls grabs the semaphore too. When it gets control of the semaphore, it draws 20 balls before letting go. After you release a semaphore, you still have to call Yield before other threads will get control.

    ThreadHandle    beepThread;
    SemaphoreHandle aSemaphore;


/* The InitThreads call initializes the Threads Package, converting
   the original thread of execution into a swappable thread. */

    InitThreads(nil, false);
    aSemaphore = NewSemaphore();

/* Fork the beeping thread. */

    if (InNewThread(&beepThread, kDefaultStackSize))
        long i,j;
        for (i=0; i<10; i++)

/* Grab the semaphore, beep 4 times, and release the semaphore. */

            for (j=0; j<4; j++)

/* Here's the main event loop. */

        long j;

/* Grab the semaphore, draw 20 balls, and release the semaphore. */

        for (j=0; j<20; j++)
        } while (!Button());

/* This call to ExitThreads waits for all threads to die before
   allowing the program to terminate. */



After examining the ramifications of implementing threads in the Macintosh run-time environment, we identified three serious problems:
  • non-reentrant Toolbox and application code
  • Toolbox use of memory between the stack and the heap
  • segment unloading

Although the Threads Package minimizes the impact of these problems, you must still deal with some special coding issues when writing programs that use threads.

When you develop code that uses threads, it's important to write reentrant code. This is a fancy way of saying that your threads must not interfere with each other. A common way in which threads do interfere with each other is in the use--or misuse--of global variables.

The basic problem can be described as follows: Your thread is merrily running along, and it politely yields control to the other threads. When it gets control again, the other threads may have unexpectedly changed some global variables, causing your thread to crash and burn, or behave in an unexpected manner.

Let's illustrate this problem with a realistic example. Suppose you want two windows in your application, and you want to have some drawing going on in each of them simultaneously. Naturally, you would start two threads that draw in the two respective windows. Unfortunately, when you run the program, you find that both of the threads end up drawing in the same window.

What happened? The first thread sets its grafPort to the grafPort of the first window. When the first thread yields control to the second thread, the second thread changes the grafPort to point to its window. Finally, when the first thread gets control again, the grafPort is still pointing to the second window.

You might attempt to solve this problem by placing code that saves and restores your grafPort before and after your call to Yield. This approach may appear to work, but watch out! There may be other calls to the Yield function in routines that your thread is calling. You would have to make sure your save-and-restore code surrounds every one of these calls as well. This would be cumbersome, to say the least.

A safer solution to the reentrancy problem is simply to write reentrant code from the beginning. In other words, just don't misuse global variables. But alas, millions of lines of code have already been written for the Macintosh with globals galore. The Macintosh Toolbox itself is on the whole non- reentrant. For instance, in the above example, the grafPort global is referenced not just in the application but in the Toolbox itself. It would be unrealistic to expect reentrancy problems in Toolbox and application code to vanish overnight.

To get around all this, the Threads Package provides an innovation called customizable swapping behavior. To understand how this behavior works, you must first know a little bit about the thread structure.

The thread structure contains additional fields for the custom procedures that the Threads Package uses to control a thread. Figure 1 illustrates these fields.

You implement the customizable swapping behavior by writing custom routines that carefully set up a thread's globals when the thread swaps in and save these values before the thread swaps out. You assign these routines to the fields in the thread structure, so that the Threads Package can automatically call these routines for you when it does the actual swapping. This enables you to getcontrol at the critical times.

Here's how the customizable swapping feature works. Normally when you create a thread, the Threads Package assigns default swapping and context-preserving functions to the thread. If you want to use all these defaults, just call the InNewThread routine to launch a thread. To use customizable swapping, you create the thread object yourself, customize it, and then launch it. Note that you must always be sure to call the corresponding default routine from within your custom routine.

[IMAGE p06-22_Gough_text_html2.GIF]

* Don't alter this pointer. In practice we've found that you don't need to override fSwapOut.

Figure 1 Customizable Routines in the Thread Structure

Remember, you don't necessarily have to use this customizable swapping technique to juggle all of your global variables. Some globals are really fixed values and don't change when your program switches threads. You only have to worry about the globals that other threads are going to change.

The following sample program demonstrates how to customize the swapping behavior of threads. Notice that there are now two ball-drawing threads. They manage to use the same global variable, gBallSize, to draw balls of different sizes. If we assume that this global is used by the NewBall procedure to determine the size of the ball, and that you don't have control over the implementation of NewBall, then you must have a way to juggle the global's value. This example shows you how to do just that:

pascal void MyCopyContext(ThreadHandle theThread)
    (**theThread).fUserBytes[0] = gBallSize ;

pascal void MySwapIn(ThreadHandle theThread)
    gBallSize = (**theThread).fUserBytes[0] ;

    ThreadHandle ballThread;
    ThreadHandle mainThread;


/* Create and customize the main thread. InitThreads will start
   it. */

    mainThread = NewThread(kDefaultStackSize);
    (**mainThread).fCopyContext = &MyCopyContext;
    (**mainThread).fSwapIn = &MySwapIn;
    InitThreads(mainThread, false);

/* Create, customize, and start the ball thread. */

    ballThread = NewThread(kDefaultStackSize);
    (**ballThread).fCopyContext = &MyCopyContext;
    (**ballThread).fSwapIn = &MySwapIn;
    if (InThread(ballThread))
        long i;
        gBallSize = 100;
        for (i=0; i<100; i++)
/* Here's the main event loop. */

    gBallSize = 20;
        } while (!Button());

/* This call to ExitThreads waits for all threads to die before
   allowing the program to terminate. */


Note that this example uses procedure pointers. As always with procedure pointers, make sure that they're A5 relative so that they can be dereferenced from another segment. In this case, the Threads Package will be calling your procedures at the critical moments before swapping in and swapping out. My preferred technique for ensuring that procedure pointers are A5 relative is to put the procedure in its own segment, separate from the routine that's generating the reference to it.

Figure 2 illustrates how we've customized the thread for the sample program above. [IMAGE p06-22_Gough_text_html3.GIF]

Figure 2 Customizing a Thread

Most threads implementations involve keeping a separate stack in the heap for each thread. They do their context swapping by altering the stack pointer and the stack base; the data on the stack never moves. Unfortunately, there are some routines in the Macintosh Toolbox that assume the stack remains in the same place, not in the heap.

One of the primary design goals of the Threads Package was Toolbox compatibility, so here's the solution we chose. It's a given that there is only one stack and all threads must share the use of this stack. However, since a thread needs to maintain its unique stack data and protect it from being clobbered by other threads, each thread needs to keep this data safe when it doesn't have control of the stack. The way a thread does this is by creating its own unique storage area in the heap. The Threads Package's context-swapping strategy moves data between the stack and the heap with the BlockMove instruction. As a thread swaps out, its context is moved to the heap. As a thread swaps in, its context is moved from the heap into the application's stack area.

The context-swapping code is written in such a way that interrupts can function as usual, and of course you can call Toolbox routines as usual. The heap storage associated with a thread's stack can and will grow dynamically as necessary, since it's free to move around in memory while it's not running.

Swap time using this strategy is 500 microseconds for a stack size of 256 bytes running on an SE/30. Your mileage may vary.

You must be careful not to pass pointers to stack objects between threads, since such pointers are not valid unless the associated thread is swapped in. One subtle way that this problem occurs is in the use of parameter blocks associated with asynchronous I/O. Such parameter blocks should not be allocated on the stack because the I/O operation may complete when the wrong thread is swapped in.

When you write threaded programs for the Macintosh, you must never unload a code segment unless you're certain that there is no thread that has entered that code segment and has not yet left. In some cases, you can be sure that there's no way for a thread to yield control while it's in a specific code segment. For example, if you have some code that does some computation that stands on its own, you can be reasonably certain that there's no way for it to call other code that could result in a Yield. In cases like this, it's safe to unload the segment as usual.

We looked at several mechanisms for overcoming this problem and found that the most promising design involves unloading segments at GrowZone time. Here's how this could work: The system could call the GrowZone routine when you need more memory in the current heap zone. Since the whole idea behind unloading code segments is to free up memory, we thought that this would be a good place to

unload segments. The trick is to make sure that your GrowZone routine only unloads segments that are not needed by any thread. To ensure this, you could augment the thread structure to include linked-list pointers that would allow your custom GrowZone procedure to traverse a list of all threads (even sleeping threads) in one pass. During the traversal, GrowZone would scan the stack of each thread, looking for anything resembling a return address. If it found a return address, the associated code segment would be "needed." When all the stacks were scanned, GrowZone would simply unload all of the unneeded code segments.


Here's a description of all the routine and data structures provided by the Threads Package.

The API functions all access a thread through its handle. The thread structure as it's defined in the Threads.h file is as follows:

struct Thread 
    struct Thing    fThing;       // Linked-list stuff.
    ThreadType      fType;        // Obsolete. 
    ThreadState     fState;       
                         // Running,pending,blocked,sleeping,ended.
    Boolean         fLocked;      // Obsolete.
    Handle          fStack;       // The storage for the stack data.
    ThreadProc      fCopyContext; 
                         // Copy current context and store in fStack.
    ThreadProc      fSwapIn;      
                         // Called to context-swap a thread in.
    ThreadProc      fSwapOut;    
                  // Calls fSchedule, then fSwapIn on the nextThread.
    ThreadProc      fFree;        // Called to dispose of the thread.
    ScheduleProc    fSchedule;    
            // Queue this thread (if necessary), return the next one.
    long    fUserBytes[8];        // For user use.


pascal void InitThreads(ThreadHandle mainThread, Boolean usesFPU);

This routine initializes the Threads Package. The first parameter is the handle of the main thread, which has been customized with specific swapping behavior. If you don't need customized swapping behavior for the main thread, pass nil. The second parameter indicates whether you want to swap floating-point registers. If you pass a value of true, they'll be swapped. Of course, the Threads Package is smart enough to know that some machines don't support FPUs, in which case it ignores a value of true.


pascal ThreadHandle NewThread(long stackSize);
Each thread structure has a number of fields that are procedure pointers. The Threads Package assigns default procedures to these fields when it creates a thread. You can create a custom thread by calling NewThread and changing the values of the procedure pointers before giving the thread a chance to run.

Here's a list of the procedure pointers that you can change in the thread structure:

ThreadProc fCopyContext;ThreadProc fSwapIn;
ThreadProc fSwapOut;
ThreadProc fFree;
ScheduleProc fSchedule;

When you change one of these procedure pointers in the thread structure, you're overriding the default behavior of a given thread. You will usually customize fCopyContext and fSwapIn to save and restore globals at the appropriate moments. If you need to deallocate data structures associated with the thread, you should override fFree, which is called when the thread dies.

If you're using the default behavior, don't forget to call the corresponding default procedure appropriately within your procedure. Here's a list of the default procedures:

pascal void TCopyContext(ThreadHandle);
pascal void TSwapIn(ThreadHandle);
pascal void TSwapOut(ThreadHandle);
pascal void TFree(ThreadHandle);
pascal ThreadHandle TSchedule(ThreadHandle); 

There is a handy place to store information in the thread structure, called fUserBytes. If you store handles there, be sure to deallocate them in your override of fFree.

pascal void StartThread(ThreadHandle theThread);
pascal Boolean InThread(ThreadHandle theThread);

Once you've created the thread with the call to NewThread and have customized it, you call StartThread, which clones the current stack and saves it in the newly created thread structure. The call to StartThread is typically followed by a call to InThread, which returns true if the specified thread is currently running. This call is embedded in an IF statement that you use to route the respective threads. The original thread jumps over the code in the IF statement, while the new thread enters this body of code.


pascal Boolean InNewThread(ThreadHandle* theThread, 
    long stackSize);

The InNewThread function combines the features of NewThread, StartThread, and InThread. What's different about InNewThread is that it automatically launches a thread with the default swapping behavior and doesn't give you the opportunity to customize the thread. InNewThread returns a Boolean as does InThread, and returns a thread handle in the theThread parameter. You must supply a value for stackSize, which is the number of bytes initially allocated for this thread's stack. If the number you supply is too small, the Threads Package will automatically grow the block of memory that contains the stack. Nice, huh? So if you don't know or care what stack size you need, just pass in 0.

pascal ThreadHandle Spawn(ThreadHandle theThread,
pascal void (*threadProc)(ThreadHandle, long),
    long stackSize, long refCon);

The Spawn routine is for mutants who don't like fork semantics. You supply a thread handle, or nil if you want an uncustomized thread. You also supply a procedure pointer that points to a procedure containing code for the new thread to run. The new thread dies when it returns from your procedure. You also specify a stackSize and a refCon, which allows you to pass some context information to the new thread. The refCon field is usually a pointer or a handle to a memory block that contains parameters you want to pass in.

The distinguishing characteristic of spawn semantics is that the code for the new thread is separated from the code for the original thread. Some people are more comfortable when these things are separated, but passing parameters to initialize the new thread is more work. With fork semantics, all of your local variables are right there on the stack. You don't need to package them up in a record as you do with spawn semantics.


pascal ThreadHandle GetCurrentThread();

The GetCurrentThread function returns the handle to the currently executing thread.

pascal void Yield();

The Yield function is called to explicitly give control to other threads. Yield is called implicitly through other routines like Sleep. (If the current thread is going to sleep, it had better yield control to a waking thread.)


pascal void Sleep(ThreadHandle theThread);
pascal void Wake(ThreadHandle theThread);
pascal void EndThread(ThreadHandle theThread);

These routines allow you to alter a thread's state of consciousness. To put a thread to sleep, you simply call Sleep and pass it a thread handle. Usually, a thread will call Sleep to put itself to sleep, although there are some cases where this will be done by another thread. To wake a thread up, call Wake. To kill the thread, use EndThread.


The Threads Package provides a nearly painless way for you to implement multiple threads of execution in your programs. All you need to learn is a handful of routines and a slightly new way of thinking about program execution. And you can gain a lot: easier, more intuitive program design; vastly simpler code; possible performance boosts; and, of course, that holy grail of Macintosh programmers, increased user satisfaction. It's a deal that's hard to refuse.


I would like to thank Joe MacDougald for his Herculean contributions to the design and implementation of the Threads Package. Without his devoted effort, the Threads Package would not exist in its current form. Thanks to Tom Dowdy for the FPU register-swapping feature, and numerous other improvements. Thanks also to ATG researcher Jed Harris, who originally suggested threads as a solution to our problems. Jed helped a great deal with design issues, and some gnarly assembly code debugging. The swapping strategy that allows the Threads Package to be Macintosh Toolbox-compatible was suggested by Donn Denman. Thanks to P. Nagarajan, the first threads user. He dropped threads into his code virtually overnight, giving us valuable input that made it possible to steer the design and implementation.

Tom Saulpaugh made significant contributions to the current design of semaphores. Thanks, Tom. Thanks to Dave Harrison for reviewing an early version of the source code for threads. Thanks to Mitchell Gass for documenting an earlier version of the Threads Package. And thanks to my mentor Larry Tesler for supporting the development of the first version of threads, and suggesting the convenience functions.

Thanks x 106 to my editor Geta Carlson. We had a blast working together on this article, although we've never met in person. Thanks to Paul Snively for polishing the article and championing threads in DTS. Greg Anderson, C. K. Haun, Dave Johnson, and Dave Williams all contributed valuable suggestions that were incorporated. Thanks to Monica Meffert, Louella Pizzuti, and Caroline Rose for making the article happen. Finally, thanks to my managers Dave Leffler and Ron Metzker for putting up with me while I worked on this, and for supporting what this is leading up to.


Interprocess communication (IPC) is one of the most compelling reasons why threads are going to become increasingly important in the future. This became clear to a group of us working in Apple's Advanced Technology Group when we observed that a client and a server application communicating via IPC could easily get into a deadly embrace. A client would ask the server application a question and would wait for an answer before continuing. Unfortunately, sometimes the client would wait forever for the answer. What happened was that the server needed to ask its own question of the client before answering the client. However, the client was monitoring exclusively for a response to its question and would ignore the server's question. The client needed to answer the server's incoming question before it could get an answer to its own question. Both client and server would be stopped dead waiting for the other to respond. In a sense, the Threads Package exists because the problem described here was intractable without threads. The application must be both a client and a server. It must be able to simultaneously handle incoming questions and wait for incoming answers. Other approaches to doing this, such as idle procs, skirted the core of the problem and led to code complexity that was unmanageable. Idle procs push too much of the problem onto the application programmer, who already has enough to worry about.

The threads solution is even more important now that IPC has been integrated into the Macintosh OS in System 7.0. As more programmers will have access to IPC because of System 7.0, they will need this elegant method of achieving concurrency.


Idle procs have traditionally been used to approach thread-like functionality. This involves writing a piece of code to handle a particular task and installing it in a queue of things that get called periodically. Thereafter, the flow of control pulses through the routine, which can do some finite amount of work and then return, so that other idle procs can get pulsed.

This approach results in several gnarly coding problems. The most serious is that the pulsed routine, which is attempting to execute some algorithm, must return to its caller at inopportune moments. Imagine that you're marching through a deeply nested piece of code and you want to relinquish control when you reach a certain point. With the pulsing approach, you must return to the caller from deep within the nested code. You could put in a return statement, but the problem would be that when it's time to pick up where you left off, you would have to magically jump back into the code after the return statement on the next pulse. Obviously, this is not a simple thing to do when you have to bypass several layers of conditionals and loops.

The magic of the Threads Package is that it allows you to avoid these problems: you can leave a complex function and resume execution of it precisely where you left off. With idle procs, on the other hand, you're forced to completely redesign the algorithm. You must give the algorithm an "inside out" appearance: code that was in the most deeply nested part of the algorithm now appears near either the top or the bottom of the routine. You may even have to break your routine into several smaller functions that are run in sequence. But doing these things will negate the natural top-down structure of a routine. It's a mess.


Threads are currently in use in a product called Virtual User (APDA #M0987LL/A). This program uses a single machine, acting as the "user," to run software tests on many CPUs at once.

Virtual User used to wait until each test was done before starting something else on another test machine. That was slow, because all the testing machines were waiting for one of their siblings to finish something before getting anything to work on. Now, with threads, the controlling machine is happily juggling separate conversations with all of the testing machines simultaneously. The result is a dramatic boost in performance.

MICHAEL GOUGH is a designer in Apple's User Programming Group. We'd tell you what he's up to these days, but it's so secret we'd have to kill you if we did. Before coming to Apple, Michael worked at STX as a NASA contractor, designing scientific data visualization systems. He is best known as the designer and implementor of CDF, a "mini-database" that NASA uses to store data from dozens of spacecraft. Michael developed software used by NOAA's fleet of oceanographic vessels to map the ocean floor. He also worked as a contractor to the United Nations World Meteorological Organization, so if you have any problems with the weather, now you know who to blame. While he was there, he developed real-time satellite tracking and data ingest systems for the TIROS-N, GOES, and GMS spacecraft, and conducted training and installation in Beijing and Buenos Aires. In Beijing he used his knowledge of electronics, computer science, math, and Scotch tape to successfully complete the installation--just goes to show that you never quite know what the right tools for the job are going to be. (Here at Apple, we make sure he always has plenty of office supplies--just in case.) *

Thanks to Our Technical Reviewers C. K. Haun, Paul Snively, Dave Williams *


Community Search:
MacTech Search:

Software Updates via MacUpdate

MacFamilyTree 8.2.1 - Create and explore...
MacFamilyTree gives genealogy a facelift: modern, interactive, convenient and fast. Explore your family tree and your family history in a way generations of chroniclers before you would have loved.... Read more
Spotify - Stream music, crea...
Spotify is a streaming music service that gives you on-demand access to millions of songs. Whether you like driving rock, silky R&B, or grandiose classical music, Spotify's massive catalogue puts... Read more
VOX 2.8.26 - Music player that supports...
VOX just sounds better! The beauty is in its simplicity, yet behind the minimal exterior lies a powerful music player with a ton of features and support for all audio formats you should ever need.... Read more
beaTunes 5.0.1 - Organize your music col...
beaTunes is a full-featured music player and organizational tool for music collections. How well organized is your music library? Are your artists always spelled the same way? Any R.E.M. vs REM?... Read more
LibreOffice - Free, open-source...
LibreOffice is an office suite (word processor, spreadsheet, presentations, drawing tool) compatible with other major office suites. The Document Foundation is coordinating development and... Read more
Sparkle Pro 2.2 - $79.99
Sparkle Pro will change your mind if you thought building websites wasn't for you. Sparkle is the intuitive site builder that lets you create sites for your online portfolio, team or band pages, or... Read more
calibre 3.1.1 - Complete e-book library...
Calibre is a complete e-book library manager. Organize your collection, convert your books to multiple formats, and sync with all of your devices. Let Calibre be your multi-tasking digital librarian... Read more
calibre 3.1.1 - Complete e-book library...
Calibre is a complete e-book library manager. Organize your collection, convert your books to multiple formats, and sync with all of your devices. Let Calibre be your multi-tasking digital librarian... Read more
Sparkle Pro 2.2 - $79.99
Sparkle Pro will change your mind if you thought building websites wasn't for you. Sparkle is the intuitive site builder that lets you create sites for your online portfolio, team or band pages, or... Read more
Spotify - Stream music, crea...
Spotify is a streaming music service that gives you on-demand access to millions of songs. Whether you like driving rock, silky R&B, or grandiose classical music, Spotify's massive catalogue puts... Read more

Latest Forum Discussions

See All

This War of Mine gets a new ending and m...
This War of Mine just got a big new update, featuring free DLC that adds a new ending to the game, among other exciting changes. The update is celebrating the game's two-year release anniversary. Apart from the new ending, which will be quite... | Read more »
Summon eight new heroes in Fire Emblem H...
Nintendo keeps coming at us with Fire Emblem Heroes updates, and it doesn't look like that trend is stopping anytime soon. The folks behind the game have just announced the new War of the Clerics Voting Gauntlet, expected to start next Tuesday. [... | Read more »
The best deals on the App Store this wee...
iOS publishers are pulling out all the stops this week -- there's a huge number of seriously great games at discounted prices this week. Let's not waste any time and get right down to business. [Read more] | Read more »
The House of da Vinci (Games)
The House of da Vinci 1.0.0 Device: iOS Universal Category: Games Price: $4.99, Version: 1.0.0 (iTunes) Description: Enter The House of Da Vinci, a new must-try 3D puzzle adventure game. Solve mechanical puzzles, discover hidden... | Read more »
Solve the disappearance of history’s gre...
Blue Brain Games invites you to indulge in an immersive hands-on 3D puzzle adventure in similar vein to The Room series, with its debut release The House of Da Vinci. Set during the historic period of the Italian Renaissance (when Leonardo himself... | Read more »
Age of Rivals (Games)
Age of Rivals 3.3 Device: iOS Universal Category: Games Price: $.99, Version: 3.3 (iTunes) Description: Deep civilization-building strategy in a fast-paced card game! | Read more »
Panthera Frontier (Games)
Panthera Frontier 1.0 Device: iOS Universal Category: Games Price: $4.99, Version: 1.0 (iTunes) Description: | Read more »
Angry Birds Evolution beginner's gu...
Angry Birds changes things up a fair bit in its latest iteration, Angry Birds Evolution. The familiar sling-shot physics mechanics are still there, but the game now features team-based gameplay, RPG elements, and a new top-down view. With all of... | Read more »
Sega Forever is for the retro game fans
Sega is launching a new retro games service titled Sega Forever, in a move that's sure to delight games enthusiasts with a bit of nostalgia. Sega's releasing five classic games for free. The titles include Sonic the Hedgehog, Phantasy Star II,... | Read more »
The Little Acre (Games)
The Little Acre 1.0 Device: iOS Universal Category: Games Price: $2.99, Version: 1.0 (iTunes) Description: | Read more »

Price Scanner via

ABBYY TextGrabber 6 for iOS Implements Instan...
ABBYY has announced the release of TextGrabber 6.0.0, an important feature update to the company’s productivity app developed for iOS and Android devices. TextGrabber 6.0 now offers Real-Time... Read more
vPhone, First Smartphone That Can’t Be Lost,...
Austin, Texas based Hypori has introduced the vPhone, a virtual smartphone that affords every business user the benefits of separate work and personal phones, conveniently delivered on a single... Read more
Save this weekend with 2016 refurbished MacBo...
Apple has dropped prices on Certified Refurbished 2016 15″ and 13″ MacBook Pros by as much as $590 off original MSRP. An Apple one-year warranty is included with each model, and shipping is free: -... Read more
New 27-inch 3.4GHz iMac on sale for $1699, sa...
MacMall has the new 2017 27″ 3.4GHz iMac (MNE92LL/A) in stock and on sale for $1699 including free shipping. Their price is $100 off MSRP. Read more
Clearance 2016 MacBook Pros available for up...
B&H Photo has clearance 2016 13″ and 15″ MacBook Pros in stock today and on sale for up to $400 off original MSRP. Shipping is free, and B&H charges NY & NJ sales tax only: - 15″ 2.7GHz... Read more
Apple Ranks 9th In comScore Top 50 U.S. Digit...
comScore, Inc. has released its monthly ranking of U.S. online activity at the top digital media properties for May 2017 based on data from comScore Media Metrix Multi-Platform. * Entity has... Read more
10.5-inch iPad Pros available for up to $20 o...
B&H Photo has the new 2017 10.5″ iPad Pros available for up to $20 off MSRP including free shipping plus NY & NJ sales tax only: - 64GB iPad Pro WiFi: $649 - 256GB iPad Pro WiFi: $749 - 512GB... Read more
Three Off-The-Beaten-Track iOS Apps That Dese...
One of the great things about using iPads and iPhones is the vast selection of apps available for most anything you want or need to do. The three outlined in this article have been in my core app... Read more
Apple No. 1 Spot In Gartner Top 100 Vendors i...
Gartner, Inc. has unveiled the top global 100 vendors in IT in 2016 based on their revenue across IT (excluding communication services) and component market segments. In the Gartner Global Top 100:... Read more
Clearance iMacs available for up to $300 off...
B&H Photo has clearance 21″ and 27″ Apple iMacs available starting at $949, each including free shipping plus NY & NJ sales tax only: - 27″ 3.3GHz iMac 5K: $1999 $300 off original MSRP - 27″... Read more

Jobs Board

*Apple* News Product Marketing Mgr., Publish...
…organizational consensus on strategy and vision for publisher tools, authoring, and Apple News Format.Carries this strategy and vision across the organization to Read more
*Apple* Retail - Multiple Positions - Apple,...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Security Data Analyst - *Apple* Information...
…data sources need to be collected to allow Information Security to better protect Apple employees and customers from a wide range of threats.Act as the subject matter Read more
Lead *Apple* Solutions Consultant - Apple I...
…integrity, and trust.Success Metrics/Key Performance Indicators:Quantitative* Year over Year growth in Apple Product and Beyond the Box sales in the assigned Point of Read more
*Apple* Solutions Consultant till v%u00E5r...
…ethics, integrity, and trust.Success Metrics/Key Performance Indicators:QuantitativeYear over Year growth in Apple Product and Beyond the Box sales in the assigned Point Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.