One of the persistent problems for newbies taking a look at Smalltalk has been the "where's my application?" problem. We haven't got a runtime system defined yet, but there's been progress in the 7.3 release of VisualWorks. New in this release is Subsystems work done by Alan. Here's an excerpt from the documentation:

It is frequently necessary to take special actions when certain system events occur, notably when the system starts up, shuts down, and immediately before and after an image save. The order in which such actions occur, relative to other parts of the system, can be critical. For example, a GUI application probably needs to perform and window startup routines only after the windowing system itself has been initialized.

Traditionally, startup events have been handled by registering dependencies on ObjectMemory. More recently, SystemEventInterest instances have been supported by the system. Both of these mechanisms left it difficult to manage the order in which actions were taken.

Class Subsystem provides VisualWorks a simple way to specify dependencies on system events as well as a modular approach to controling their order of execution. Several subsystems are defined for handling VisualWorks startup procedures.

Two subclasses in particular are of interest to the application developer:

• UserApplication
• ImageConfigurationSystem.

If an application has actions to perform upon one of the four system events, a subclass of UserApplication is a convenient place to specify those actions. ImageConfigurationSystem is useful for applications that process command line options.

Defining System Event Actions
Subsystem defines four system event messages to which subsystems can respond: activate, deactivate, pause, and resume. By default, these general events are invoked as follows:

• activate is invoked by #returnFromSnapshot, which occurs when an image is launched.
• deactive is invoked by #aboutToQuit, which occurs just before the image exits
• pause is invoked by #aboutToSnapshot, which occurs just prior to writing an image file
• resume is invoked by #finishedSnapshot, which occurs just after the image file has been written

Responding to System Events
Some subsystems invoke activate upon #earlySystemInstallation, but these are usually system level subsystems. For applications, #returnFromSnapshot is the appropriate system event. A subsystem does not respond to these system event messages directly. Instead, these messages invoke further messages in which a subsystem configures its response to the system events. The corresponding messages that a subsystem will implement as needed are:

• setUp
• Defines actions to perform upon the activate event message, and activates the subsystem.
• tearDown
• Defines actions to perform upon the deactivate event message, and deactivates the subsystem.
• pauseAction
• Defines actions to perform upon the pause event message.
• resumeAction
• Defines actions to perform upon the resume event message.

An application seldom needs to perform actions before or after a snapshot, which is generally a development time activity, so do not generally have to provide implementations for pauseAction or resumeAction. An action does, however, frequently have actions to perform upon launching the image, such as setting up its runtime environment, and these are specified by an implementation of setUp. Less frequently, but not uncommonly, an application will also need to perform actions prior to shutdown, which can be implemented in the tearDown method. The UserApplication subsystem, which is intended to be the superclass for application subsystems, implements one additional stub method:

main
This method can be implemented by a subsystem to launch the application, as well as to perform other application set up tasks. This method simplifies starting an application upon image launch, eliminating the need to either save the image with the application open, or of using Runtime Packager to specify the application to run, or any of the other methods that have been used. As an example of using setUp and tearDown methods, consider the task of saving a random number seed upon shutdown and then reading that seed to restart a random number generator upon startup.

This is something I'll be migrating BottomFeeder to after the 3.8 release - which means that post 3.8, we'll be moving to a VW 7.3 runtime. I'll be posting comments on how I'm migrating to the new code - it should be useful information in general.

To see the full documentation on this stuff, open the Application Developer's Guide, and look at the Application Frameworks chapter.