AppleEvents are amazingly similar to many other sorts of event models. They are very similar to the Windows messaging passing model, but not as "firm" as Windows (Windows messaging is more standard, and does not largely encourage custom messages between applications). For instance, Windows uses the messaging functions internally to a program, or externally between programs on the same machine. This means that whether or not the window object is in your process space, you still message it the same. This seems kind of strange to point out, but it is not as common (and certainly not required) that Macintosh programs throw and catch their own messages to start these processes.

There are a few advantages to Apple's system over others:

In OS X, AppleEvents are devaluated in favor of the new event model, Carbon Events. (Pre OS X can use this model to a limited extent by using Carbon Lib). Instead of calling WaitNextEvent() to see a new message coming in (and having to behave as a good process citizen), you can set handlers for events that fire once an event is processed in the queue (otherwise the default handler is called). It makes it easier to use by only "suubscribing" to the events you really want to deal with, and letting the OS handle the rest. Carbon events are very accessible in AppleScript, and help to take advantage of the new processing model, the new waiting model, everything. They are a far superior choice for the Macintosh applications of the future.