As the Mac began to acquire more RAM, the engineers at Apple gave us the Switcher. The Switcher permitted more than one program or application to be active in memory at any one time. To put this into perspective, it allowed the user have more than one program open at a time, and to switch between them, an approach called context switching. It is important here to point out that with context switching, these programs were not running simultaneously, they were operating one at a time. The Switcher simply stored the state of one program while restoring the other, as well as switching the users context.
Later, the context-switching concept evolved into a service called MultiFinder. Initially MultiFinder performed the pretty much the same functions. As MultiFinder became more developed, and more OS support was provided, an ideal was born, supporting cooperative multitasking. With cooperative multitasking, the OS was altered in such a way that each time the GetNextEvent was ordered, instead of simply updating the internal events and happenings, the OS also allows other programs and applications to update as well. In order for this to work, every program running had to cooperate with the operating system, and allow it to perform the required updates. If any application stopped ordering GetNextEvent, the processor would just continue with that programs codes until the next GetNextEvent called, or until the program quit. In cooperative multitasking, there was no way for the OS to interrupt a program. This was not a great way to work, since the only control the user had was over the mouse, as nothing else will work when an application is behaving this way. No mouse clicks or keyboard actions will work when the program has locked up the processor this way, since the operating system itself is powerless.
There are also behaviors very common to cooperative multitasking seen in other operating systems in use today. For example, in Microsoft Windows 95, as with Mac OS 9, when a program controls the main event loop, it can control the entire system, so that no other program, not even the OS, can process any event if the controlling application does not release the event loop. We see this in Win95 when we get popup dialog boxes that must be dismissed by clicking OK or Cancel. In the case where a program controlling the main event loop will not release, the box will remain on the screen, preventing all other background applications and activities from functioning until it is dismissed.
Throughout the years, the GetNextEvent was refashioned and even later supplanted with several replacements. These replacements allowed applications to assign their own significance in the operating order within the operating system, and allow these programs to determine then exactly what their level of importance was in relation to each other. For example, the game you are playing may want top priority, while the word processing software you are ignoring may set itself lower on the totem pole of programs at that moment in time.
Home - Table Of Contents - Contact Us
CertiGuide to A+ (A+ 4 Real) (http://www.CertiGuide.com/apfr/) on CertiGuide.com
Version 1.0 - Version Date: March 29, 2005
Adapted with permission from a work created by Tcat Houser et al.
CertiGuide.com Version © Copyright 2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.