Related Info: Script Manager

It’s Finally Here: SmalltalkAgents

A power-house development environment, terrific turnaround time, and a great language

By Thornton Gale, Mercer Island, Washington

About the author

Thornton Gale is an Apple Developer who has been programming the Macintosh for five years in C and Smalltalk. With over 30 years experience in all phases of software engineering, he is the co-author of a forth coming book on object-oriented technology to be published by SIGS Books in 1994. He lives and consults from his home on Mercer Island, Washington, with his wife Marty and their cat Gracie. He can be reached on AppleLink at D5854.

Announcing SmalltalkAgents

There’s a new object-oriented development environment on the market for Macintosh developers: SmalltalkAgents, a new version of Smalltalk, a product of Quasar Knowledge Systems (abbreviated QKS) of Bethesda, Maryland. SmalltalkAgents is a complete implementation of the de facto-standard Smalltalk-80, but as we’ll see in this review, SmalltalkAgents includes a number of very nice extensions to the Smalltalk-80 standard. Also, SmalltalkAgents is a new-generation development environment and raises the bar on what a development environment should be like.

Just what is Smalltalk?

Let’s begin with the history of Smalltalk and a brief description of the various other Smalltalk development environments that are currently offered on the market. Smalltalk is the second most popular object-oriented development environment, second only to C++, and is the granddaddy of all object-oriented languages. Well, not exactly. Simula which was developed in Norway in 1967 is considered the first object-oriented language. Smalltalk originated at Xerox PARC (Palo Alto Research Center) in the early 1970’s and went through several major releases before finally arriving at a state of relative perfection in Smalltalk-80. Smalltalk is mature and has been around since its release in 1981.

Objectworks/Smalltalk

Several PARC veterans, including Adele Goldberg, started ParcPlace systems and put out a Objectworks/Smalltalk. It is available on several platforms including Open Look, Windows, OS/2 and OSF/Motif as well as the Macintosh. Objectworks/Smalltalk, being the direct descendent of Smalltalk-80, is considered the de facto standard in the Smalltalk world today. While expensive, it does something most development environments only dream abou - the developer can port complete Smalltalk applications from one platform to another in just minutes.

Digitalk Smalltalk/V

Digitalk, another major provider of Smalltalk, was founded in 1983 to bring Smalltalk to the IBM/PC with their original DOS Smalltalk product called Methods released in 1985. In 1986 Digitalk released the more powerful Smalltalk/V DOS product, a Smalltalk for the masses. Later, versions of Smalltalk/V were released for Windows, OS/2 and the Macintosh. Smalltalk/V applications are not as interoperable on the various platforms as with Objectworks/Smalltalk but with some recoding, an application could be ported from one platform to the other. Also, Digitalk has announced plans for achieving interoperability by using a “common code base” for their product on the various platforms.

Heritage with the Macintosh

Smalltalk has a strong heritage in the Macintosh world. Apple Fellow, Alan Kay, envisioned an object-oriented environment and was a member of the team at Xerox PARC in the 1970’s that designed Smalltalk-80. That talented team at Xerox PARC has a lot of names familiar to Macintosh developers: Dan Ingalls (later of Apple, now retired from the computer industry) and Larry Tesler (now Apple’s Chief Scientist), both of Xerox PARC at the time, gave Steve Jobs the initial infamous 1979 demo of Smalltalk. This demo of Smalltalk, according to Macintosh folk-lore, was a major influence on Steve to develop the Lisa. The initial technology influence of Smalltalk on the Lisa was strong, with many of its concepts working their way into Lisa, and then into Macintosh.

A Serious Macintosh Development Environment

With so many implementations of Smalltalk out there, why would there be an all out effort to develop another one? I talked to the QKS folks about this. I asked “Why does the world need another Smalltalk?” Their answer was simple and direct: The QKS designers of SmalltalkAgents spent a lot of time analyzing the needs of applications development in the future. This analysis went far beyond the Macintosh environment and included examining current CPU architectures (CISC, RISC, multiprocessors), current GUI architectures, and existing development systems and environments in the computer industry. The result of their analysis is SmalltalkAgents.

Some of us Macintosh developers have used the other Smalltalk products but we always knew deep-down that our Macintosh version of Smalltalk began life on another platform. In effect, our Macintosh version was just an afterthought and we knew that all the resources and mindshare of the vendor were devoted first to that original target platform. The difference with SmalltalkAgents is that the Macintosh is its original target platform!

That’s not to say that portability is not a major objective of SmalltalkAgents. After having talked with QKS about this issue, I can say that they are deeply committed to portability. Their porting schedule calls for Macintosh first, followed by Power Macintosh in the second quarter of 1994, Windows in the 3rd quarter of 1994, and Sun SPARC in the fourth quarter of 1994. Other platforms will be added after that depending on market demand.

Who Should Use it?
What about the Third-Party Developer?

Another question I asked was, “Just who are the target SmalltalkAgents developers? What is the profile for developers using SmalltalkAgents?” QKS answered that they are targeting SmalltalkAgents for a broad range of developers from individual programmers to corporate developers. They see the developer who would use SmalltalkAgents as anyone who wants to develop a double-clickable application.

One of the questions you may be having right now is what about the third-party developer? While SmalltalkAgents can be used for so-called vertical applications, can it be used for commercial applications sold to the general market? The answer: Yes! Absolutely! Definitely! In fact, many sophisticated, commercial apps have been written in the various dialects of Smalltalk, especially GUI intensive applications such as business process re-engineering, complex business analysis applications, and CASE tools. The power and flexibility of the environment offset the somewhat large 1.5MB minimum disk footprint and 2.5MBminimum RAM footprint of a standalone application. The SmalltalkAgents package includes a runtime environment (the SmalltalkAgents standalone kernel) on which commercial products can be run. The SmalltalkAgents license agreement provides for royalty-free use of the standalone runtime environment.

An important and often overlooked subset of the developer community is the non-English language developer. SmalltalkAgents has been designed for the non-English language developer as well. SmalltalkAgents uses the Macintosh Script Manager. When using System 7.1, the developer can take full advantage of Apple’s WorldScript II as well as the emerging Unicode standards. The WorldScript capabilities are transparent and applications developed in SmalltalkAgents will automatically be WorldScript capable.

It’s an Environment - It’s a Language - It’s Objects

All of the Smalltalk environments mentioned above, including SmalltalkAgents, have a very important structure: each is both a language and a development environment. In fact, the concept of the high-speed, integrated development environment many of us have come to love with products like ThinkC or TurboPascal, originated with Smalltalk. Two aspects distinguish Smalltalk from conventional development environments: first, Smalltalk is a pure object environment; and second, it uses a layered structure featuring a mechanism called the virtual machine. We'll consider each in turn:

Pure Objects

Smalltalk is known in the object-oriented community as a pure object language. In Smalltalk, everything is an object and work is done by sending objects messages. This is contrasted to the hybrid approach taken by C++ which adds object-oriented constructs to the traditional language C. In C++ some data are represented by objects and other data by C language constructs (e.g., int, char, struct) which can be manipulated directly outside the discipline of object encapsulation. With SmalltalkAgents, you’re getting the real thing, true object-orientation.

The Virtual Machine

At the core of all the dialects of Smalltalk mentioned above is the virtual machine (usually abbreviated as VCPU). The VCPU is a software layer which sits at the logical level between the application and the hardware. It provides a level of abstraction so that the programmer doesn’t need to worry about the host machine architecture. This is how the interoperability of Smalltalk is achieved. To port a Smalltalk product to another platform, the vendor must (among other things) implement the VCPU on that platform.

In many ways, the VCPU is like an operating system in that it controls all activity in the Smalltalk environment including execution threads, storage management and generally functioning as the traffic cop between Smalltalk and the outside world. In another way the VCPU can be thought of as an abstract computer implemented in software. The programmer writes source code which is compiled into the “machine-code” for the VCPU. The compile process actually creates a new object called a CompiledMethod. This CompiledMethod object contains sequences of eight-bit instructions called byte-codes as the executable form of the source code. The byte-codes are analogous to the “machine-code” of a hypothetical stack-based machine implemented by the VCPU. The byte codes are “executed” by the VCPU byte-code interpreter.

Smalltalk has historically been plagued with the reputation for slow execution. Actually, this hasn't been true for years but the bad reputation still persists. I can say that speed of execution is not at all a problem for SmalltalkAgent’s applications especially on a modern Macintosh computer. On other platforms, industry experience shows that applications ported from Smalltalk to C++ are only about 10% - 20% faster on the same platform.

Many of the differences between Smalltalk-80 and SmalltalkAgents are implemented in the VCPU. For example, the VCPU of SmalltalkAgents provides the preemptive-multitasking capability that separates SmalltalkAgents from the herd. We’ll return to this later. For now, we want to understand the VCPU as the provider of what we call dynamic programming which we will discuss at length in the next section.

Where does SmalltalkAgents fit in the Developers Toolkit?

SmalltalkAgents (as well as any other Smalltalk environment) has an ideal target domain in which it can be applied extremely effectively, some say much more effectively than any other development environment. This ideal target domain is characterized by the need for developing an application quickly for a client. Much of this definition of the ideal target domain for SmalltalkAgents is concerned with quickness of development.

It’s a Matter of Prototyping

SmalltalkAgents is perfect for supporting a prototyping-based development style, that is, constructing the application as it is being designed. The alternative is to serialize the analysis, design, and construction processes into separate phases of development. The problem with a serial approach is that analysis, design and construction tend to be both intellectually-tangled and communication-intensive processes. The real world of the client is characterized by flashes of brilliance, false starts, and generally changing one’s mind. The client and the programmer use SmalltalkAgents to communicate by building and continuously evolving a model of the solution. At each iteration, new ideas emerge and are quickly put into the evolving model. The radical part is that as the work proceeds, this model becomes the real thing, the implemented application.

Small is Beautiful

A very small team of a programmer (or two) and a client (or two) is important for the prototyping-based development style to work right. Larger applications requiring more people are divided into smaller chunks to allow these very small teams. Using SmalltalkAgents, the actual work of building and evolving the application occurs in an intense environment with the client and the programmer continually banging away at the budding application. A war room with a lot of white boards is ideal for this. At first the client will be a subject matter expert sitting at the SmalltalkAgents Macintosh with the programmer who manipulates the development environment to evolve the application. Later, the client may occasionally take over to build the user interface or actually tweak the evolving application as it is being tested.

Dynamic Programming vs. Static Programming

The capability that allows SmalltalkAgents to be used in prototyping-based development is that it is a dynamic environment as opposed to a static environment. In static programming, the programmer work flow consists of editing, compiling/linking, and executing (testing). The compiling/linking step is usually time consuming because of the physical integration and lack of modularization of the resulting single binary file representing the executable application. For an average-sized application (i.e., a serious application as opposed to a toy-demo), the compile/link step will take several minutes in most static environments. Static programming is what most of us have been doing as we write our programs in static environments such as C, C++ or Pascal. We static programmers often have an interactive environment such as ThinkC and feel productive. But static programming is done at snail’s pace compared to dynamic programming.

Modularization is the Key

A dynamic environment like SmalltalkAgents is completely different. In SmalltalkAgents, the application is subdivided into many small pieces. We call this modularization and the object-oriented paradigm provides the perfect structural modularization mechanism. The total lines of source code of a SmalltalkAgents application may be large but it is divided into the hundreds of short methods of the classes used in the application. Since the virtual machine will bind a method to a message at execution-time, a method can be changed and recompiled anytime. A method is recompiled when saving changes to its source code. The compile process is virtually instantaneous in SmalltalkAgents. Thus, the programmer work flow in a dynamic environment like SmalltalkAgents consists of building the application in tiny increments by continuously editing and executing perhaps thousands of very limited changes to the methods of the application.

Using the Bean in a Different Way

The interesting thing is that dynamic programming shifts the intellectual process of programming to a different compartment of the brain. With dynamic programming, the application is built in very quick intellectual bursts using our short term memory as changes are conceived, programmed, and executed as light-weight mental scenarios. This is opposed to the sense of protracted work of the static environment in which any change is necessarily regarded as heavy-weight and must be value-analyzed and filtered before being given the nod. The filtering process may be unconscious but it’s there. We are always asking ourselves in a static environment, “Should I really make this change?” as we subconsciously worry about the time penalty. With dynamic programming you don’t have any sense of making these little yes-no decisions. Thus, SmalltalkAgents fits very well with the prototyping-based development style in which the programmer and the client evolve the application by continuously and freely tweaking it.

Throwing Down Code

Another facet of SmalltalkAgents that supports the prototyping-based development style is the utter simplicity of writing programs in this environment. We all know of the many advantages of object-oriented environments for enhancing productivity. The reusability of a class library is one facet of this productivity that has been well documented by others and does not need to be restated here. Suffice it to say that prototyping-based development and reusable classes go together like peanut-butter and strawberry jam.

Also an important productivity facet is just how fast programs can be written. With SmalltalkAgents, the programmer is truly empowered to throw down code very fast. The SmalltalkAgents programmer uses a high level language that is very forgiving, simple in syntax and easy to remember. SmalltalkAgents implements the original Smalltalk-80 syntax but makes several very useful extensions to the language including dynamic lists, C-like structured storage in objects, and many, many more.

Memory Management - No longer your problem

The feature of SmalltalkAgents (as well as other Smalltalk implementations) that really empowers prototyping-based development and throwing down code fast is the utter simplicity of memory management. Memory management bugs are the most common and difficult errors on the Macintosh in static programming languages like Pascal, C or C++. Smalltalk environments such as SmalltalkAgents provide automatic memory management by a sophisticated process known as garbage collection. Garbage collection is the process of periodically scanning the current set of interlocking objects and freeing the memory of unattached objects. An object becomes unattached when it is no longer pointed to by any other object, in effect it is no longer used.

This is a huge productivity boost! The programmer doesn’t worry at all about memory management: no more locking; illegal dereferencing; dangling pointers; worrying about compaction; or any other memory management duties that suck time and cause debugging woes. From 10% to 40% of code is devoted to managing objects in C++, functionality which is not needed at all in SmalltalkAgents. In general, the source code of a SmalltalkAgents method doesn’t contain memory management statements of any kind. This makes it so easy to throw down a lot of source statements in a hurry, source statements which are entirely focused on solving the problem rather than keeping books for the operating system.

There are many development environments for the Macintosh which can be used for application prototyping, HyperCard being a well-known example. However, with HyperCard once the prototyping is completed, translation to a robust environment must be done. A related problem is that as the prototype gets larger and more complex, confusion and lack of source-code control creeps into the HyperCard prototyping project to detract significantly from productivity. We will discuss this point in more detail in the next section when we discuss the excellent SmalltalkAgents programming environment.

The Programming Environment

SmalltalkAgents has a completely integrated development environment called the Workbench. The Workbench is implemented as an integrated set of classes. The Workbench is very complete and consists of a code editor, source code management tools, debugger, inspectors, and GUI Builder. We'll discuss each briefly in this section.

Code Editor

The entire Workbench of SmalltalkAgents is implemented as a bundle of collaborating objects instantiated from the class library. In an object environment, everything is done with objects. The primary programmer tool is the code editor implemented by the class CodeEditor. This means the developer has complete access to the source code of the CodeEditor class and can modify it as desired. Want to implement some features from the UNIX vi editor? Go ahead! You can customize your development environment by modifying the source code of the various methods which implement the Workbench.

The code editor has a Tool menu containing many commands related to the Workbench and software development. In addition, the Tool menu is readily available to developers for inserting their own commands. The developer can modify the Tool menu to include menu entries which invoke methods coded by the developer to perform their own useful functions to customize their development environment.

The SmalltalkAgents code editor has many productivity features. and numerous keyboard commands are available. The regular expression matcher provides full grep searching and replacement on 8/16/24 bit characters. Double-click “kissing” for selection of “[ ]” pairs, “( )” pairs, and “{ }” pairs is also provided.

The follow figure shows the code editor in action. The operations menu has been pulled down revealing the extensive repertoire of operations available.

figure 1: Code Editor

Source Code Management

One of the productivity advantages of programming in SmalltalkAgents are the source code management tools. Even a modest SmalltalkAgents (like any Smalltalk) application consists of adding numerous classes and methods as the environment is extended to encompass the application functionality. The SmalltalkAgents product is distributed with close to 400 classes and over 7000 methods. For a typical mid-sized application, the programmer will add to this a few dozen application-unique classes which on average will have around 10 to 20 methods per class. This is a lot of source code and it could all get pretty complicated. There is a big need for source code management tools.

The Workbench has many powerful tools for the management of code. The process of navigating through source code using various cross-references is a breeze with the Workbench. For example, the programmer can quickly find all occurrences of class references, method references, or variable references. Got a problem with an instance variable? Select a target instance variable from a list of the class’ instance variables and display the methods which modify it.

SmalltalkAgents provides many different ways to access and find entries in the class library. One important view of the class library is the Category View The figure below shows the Category View in action. In SmalltalkAgents, classes may be assigned to a category and methods may be assigned to a protocol designation to aid in functionally grouping them. The class categories and method protocol designations are used by the Category View to access the class library. Once a category is selected the set of classes of that category is displayed. Once one of the classes is selected, a list of method protocols is displayed. Selecting a method protocol causes the specific methods of that protocol designation to be displayed. Selecting one of the methods causes its source code to be displayed in the editing pane of the CodeEditor.

figure 2: Category View

SmalltalkAgents provides several ways of viewing the inheritance hierarchy of the class library. The two principle methods of viewing the inheritance hierarchy are the Tree View and the Hierarchy View. These views can be used to navigate the class library by following the superclasses or subclasses of a class. The figure below shows the Hierarchy View (left) and Tree View (right) in action on the List class. All of these views of the Workbench are interrelated. For example, selecting a class in the Tree View will cause the Hierarchy View (if it is opened) to be updated with the selected class or selecting a method in the Hierarchy View will cause the method to be displayed in the editing pane of the CodeEditor.

figure 3: Viewing the Inheritance Hierarchy

Debugging

In SmalltalkAgents all debugging information is presented at an object-oriented level. The application is shown as a set of objects which can be inspected and navigated. The programmer walks memory looking at the results of the recent execution which is represented as state changes on familiar objects. The programmer can single cycle the execution or step in or out of method calls similar to the ThinkC debugger. The following figure shows the debugger in action:

figure 4: Debugger

Inspectors

Inspectors are used to view and change the runtime environment. Since objects consist of composites of other objects, it is important to be able to walk through the object tree of various objects which are chained together. The SmalltalkAgents inspector provides easy access to the object tree beginning with the target object. The programmer can double click on any of the various component objects of the target objects to chain to that object. The following figure shows the inspector in action:

figure 5: Inspecting the Desktop GrafPort

GUI Builder

The GUI Builder is an integrated package that builds complete user interfaces which conform to the Macintosh user interface guidelines. The GUI Builder presents an easel to paint the user interface by dragging and sizing the various widgets from a tool palette. The GUI Builder generates the Smalltalk code for the budding application. At anytime, the programmer can revise the user interface using the GUI Builder then regenerate the code. The following figure shows the GUI Builder being used to design a user interface. The figure shows the GUI Builder Tool Palette (left) and Info Palette (bottom) opened with the emerging user interface in the background.

figure 6: GUI Builder

Complete Access to the Macintosh

SmalltalkAgents offers complete access to the Macintosh operating system and its internal data. This permits the merging of two worlds: the high-level programming world of SmalltalkAgents and the technical low-level Macintosh world. In effect, the programmer can blast along in the highly productive development environment then make occasional forays into the low-level Macintosh internals as required. This means that SmalltalkAgents is a completely open environment and doesn’t have any of those brick walls that we encounter usually at the tail-end of a project when we discover that we need some additional technical or operating system functionality not provided by our environment. With SmalltalkAgents if you need to go into the bowels of the beast, you do so with a well-documented API!

Inline calls

The SmalltalkAgents programmer can place inline calls to the Macintosh toolbox procedures in methods. For example, to use the toolbox procedure “GetMouse” to return the current mouse location in a new Point object called myMousePoint:

«GetMouse((myMousePoint:=Point basicNew):Ptr)»

The inline calls are defined in a special SmalltalkAgents dictionary called ExternalMethods. The ExternalMethods dictionary contains all of the published toolbox procedure calls through Inside Macintosh VI and allows new ones to be added easily.

Callbacks

SmalltalkAgents comes with several ready-to-go Callback classes which support toolbox and foreign function callbacks including MDEF’s, WDEF’s, LDEF’s, and controls callbacks. Basically, Callback objects contain relocatable, executable code which may be called outside of SmalltalkAgents to execute SmalltalkAgents code.

XCMD/XFCN’s

The inline call feature (above) can be used to call HyperCard XCMD/XFCNs. SmalltalkAgents also provides an easy implementation of the complementary capability of callbacks from the XCMD/XFCNs. The XCMD/XFCN callback environment is constructed using subclasses of the SmalltalkAgents hierarchy of Callback classes (above). The programmer must provide a proper callback environment using Callback objects on the SmalltalkAgents side. This means that most of the current crop of XCMDs and XFCNs could be made to work in a straight-forward manner under SmalltalkAgents depending on how well the XCMD or XFCN follows standards. But notice that actually making them work by providing the proper callback environment is the responsibility of the programmer.

External Methods

The inline call feature (above) can be used to integrate your own custom C/C++ code resources into the SmalltalkAgents environment. In general, all the external methods including Macintosh toolbox calls, XCMD/XFCNs, as well as any custom C/C++ external methods are defined in the ExternalMethods dictionary. The compiler uses the definition to generate code with the correct calling format. This mechanism provides automatic loading and fixup of the external methods.

Structured Storage

SmalltalkAgents provides a structured storage mechanism which is similar to that used in C to access the elements of a struct, or in Pascal to access the elements of a Record. This mechanism is provided through structured storage templates that are contained in a special dictionary called StructureDictionary. Structured storage constructs allow the programmer to use and access the Macintosh’s external storage definitions such as CGrafPort’s, TERec’s or PixMap’s. Virtually all of the Macintosh data structures have been defined and new ones can be added easily. The StructureDictionary can be easily accessed from the Workbench to view or define structured storage. The figure below shows the structure storage definition for the Macintosh PixMap. Also, not shown, the environment offers a structured storage inspector in which you can view by offset or by name.

figure 7: PixMap Structured Storage

Extending the Environment

With SmalltalkAgents, like any other Smalltalk, the programmer doesn’t write a program. Rather, the programmer extends the SmalltalkAgents object environment. The SmalltalkAgents environment consists of a large set of interacting objects. A SmalltalkAgents application is simply a subset of objects of the general environment which interact by sending each other messages. The application objects are just mixed in with all the other objects in the SmalltalkAgents environment.

Reusing classes in the class library

SmalltalkAgents provides a wonderful set of reusable classes in the class library distributed with the product. Almost any structure, process, or mechanism the programmer would every want to use is provided in the class library. An example is the SmalltalkAgents collection classes which are the quintessential example of reusable programming mechanisms. The SmalltalkAgents collection classes are a hierarchy of classes which provide various ways of storing collections of objects, and as we all know, much programming is spent messing with this very natural construct. The List class is an example. The List class provides an ordered, indexable, resizable collection of objects which the programmer uses to store and retrieve a series of objects. Without a class library, the programmer must construct and debug the routines that manage a List (although realistically, the programmer would build the routines to manage an array by pasting in source code from previous programming efforts). With SmalltalkAgents, the programmer has the use of collection classes which are robust, efficient, and well-used. Many are implemented with sophisticated techniques such as B-Trees and hashing, and have had someone else work out the kinks.

Plagiarism: The key to good OOP

Knowledge of the class library is the SmalltalkAgent programmer’s salable expertise. The programmer produces an application by navigating through the existing classes in the class library studying their function. A typical coding scenario is to create a subclass of an existing class then override some of the methods of the new subclass as well as add some new methods and instance variables. In SmalltalkAgents, there is a lot of re-use as the programmer grabs bits and pieces of code here and there for these methods of the new subclass. The class library provides extensive coding examples especially for the difficult stuff. As we saw above, the SmalltalkAgents Workbench provides the programmer with a variety of powerful tools to accomplish this plagiarism.

Applications, Projects and Libraries

The typical SmalltalkAgents application is a set of objects and classes grouped into a project and contained in a library. There can be many project libraries and they provide a way to partition and modularize the environment. Libraries can be used to hold any set of objects and classes. Between libraries, name spaces do not overlap, insuring that objects and classes created by different developers can be integrated. This will enhance collaborative programming. Libraries work like hierarchical file systems such as Macintosh folders in that libraries can be nested to any level. Names are scoped downward or overridden within the hierarchy.

Structures and External Methods

Structures and external methods are defined in their respective dictionaries which are, in turn, defined in a library (recall that structures and external methods provide access to external software such as the Macintosh data and toolbox routines). In this way, the name space for structures and external methods are scoped and made private to the library to prevent naming conflicts.

Object Integration and Application Distribution

Once the application is ready to be distributed, a process of extracting the application classes from the development environment is run. This minimizes the size of the application to be distributed. However, to run the application, there is the need for a minimal set of objects representing the run-time environment. This set of run-time objects is called the SmalltalkAgents standalone kernel and as explained above is available royalty free to run the application on the customer’s Macintosh.

SmalltalkAgents has an extensive capability to load and unload clusters of objects known as platform independent portable objects (PIPO). A PIPO is stored in a platform independent binary format and can be used to store any set of objects. The PIPO facility is perfectly general and is used for any kind of object storing, interchange or archiving. A PIPO can be loaded/unloaded in real time so it could be used to save objects in a file, a database or send them over the network to another SmalltalkAgents environment.

One use of the PIPO capability is to distribute applications. The programmer uses a PIPO to store complete application projects which include the application’s compiled code objects, classes, sounds, pictures or any other object an application might have. Once created, a PIPO may be integrated into a target SmalltalkAgents kernel environment in real time using a dynamic linking process. Thus, applications can be distributed as a small file of application-unique binary objects. The process of extracting the objects of the application is performed by the Application Delivery Toolkit (more later). PIPOs permit programs, and code/class libraries to be distributed without source code, providing inherent anti-piracy protection.

Multitasking

SmalltalkAgents implements preemptive multitasking. Preemptive multitasking will be of great interest to Macintosh developers because it will allow a new kind of application.

Threads

The preemptive multitasking capability is implemented using Threads which are special objects that control a thread-of-control. A Thread object contains the execution state information of a thread-of-control such as its run state, private context for graphics, event status, exception status, etc. For example, to create a separately running thread-of-control, the following code fragment would be inserted in a method:

 Thread run:  [a block of code].

The block of code between the “[ ]” pair would normally be a “new” message to an application or control object which would then embark on a separate thread-of-control. Once created, the new Thread will have a life of its own completely independent of the parent Thread that created it.

Sharing the CPU

Multitasking is implemented on two levels: First, within SmalltalkAgents, timer interrupts are used to share the CPU among the Thread objects. Generally, this is transparent to the user and does not have annoying side-effects at all (i.e., there was no jerky mouse at least on my Mac IIci).

Preemptive threading

The other level of preemptive multitasking is from the external world outside of SmalltalkAgents. This capability depends on SmalltalkAgents being properly informed of external asynchronous events delivered from the host, in our case the Macintosh OS.

Within SmalltalkAgents, low-level toolbox calls take advantage of asynchronous processing opportunities wherever possible by, for example, specifying the “async: Boolean” as true on I/O calls. However, this means the extent of asynchronous operation is at the mercy of the Macintosh OS, which just isn’t up to providing asynchronous behavior across the entire toolbox and OS. While SmalltalkAgents will preemptively schedule the various running Thread objects and interrupt them when an interrupt is presented from the Macintosh OS, it can’t change context when waiting for a toolbox call to finish.

However, there are several Macintosh OS Managers that do honor the “async: true” of low level I/O calls to provide true processing overlap opportunities. The managers include AppleTalk, and the Communications Toolbox in general. One of the uses of this capability would be to implement a distributed application on multiple networked Macintoshes as simultaneous threads of execution in which the parts communicate over AppleTalk. SmalltalkAgents would be perfect for such an application.

Control of Concurrency

The programmer has complete control over the multitasking environment and can mask interrupts or enable/disable interrupts as necessary. Also, SmalltalkAgents classes distributed with the product are designed to operate in a concurrent environment. For example, when shared resources such as dictionaries are being updated, interrupts are masked off.

SmalltalkAgents Product Package

In this section, we will review what you get in the SmalltalkAgents product package. With SmalltalkAgents, you get a lot of extras:

SmalltalkAgents Kernel

The kernel is the collective term for the combination of the virtual machine and the core classes. The kernel contains the classes and their objects that are needed to implement the Smalltalk language, the Macintosh dependent interfacing features, and the base set of classes required to provide the SmalltalkAgents application framework.

SmalltalkAgents Workbench

Contains the environment (see sections above) including:

• Compiler

• Source code debugger

• Inspectors

• Language-sensitive editor

• GUI builder

Class Library

SmalltalkAgents is distributed with a very complete and powerful class library (close to 400 classes). For purposes of description, the class library can be decomposed into several general categories summarized below:

• Foundation Classes

SmalltalkAgents is distributed with a large number of foundation classes. These are the classes which implement computer science or general programming mechanisms such as the collection, magnitude, or date/time classes.

• Graphics Kernel Classes

SmalltalkAgents contains a large number of classes to implement the Smalltalk graphics kernel. These classes and the concepts behind them are the pioneers of the bitmapped graphics interfaces on modern desktop computers (e.g., Macintosh, Windows, Motif, etc.) Examples of these classes include the various geometry, color, or bitmap classes.

• General Interface Classes

These are the classes which implement any interface to SmalltalkAgents as well as support its operation. Examples of this category include the device or network classes.

• User-Interface Classes

These are the subset of interface classes devoted to the implementation and control of the user interface. These classes will be very familiar to the Macintosh developer and include the various window, menu, text, or widget classes.

• Kernel Classes

These are the classes which implement the basic operation of the SmalltalkAgents kernel and virtual machine. Examples of this category of classes includes the compiler, thread, callback, or PIPO classes.

• Macintosh Operating System Classes

SmalltalkAgents includes a large number of Macintosh Operating System classes. These classes are used to access the Macintosh OS and Toolbox. Examples of this category include the Macintosh file system, sound, device, font, or user interface classes.

Reusable Components

SmalltalkAgents comes with several complete components (sets of collaborating classes) which implement significant Macintosh functionality or serve as examples for building complex applications:

• Data Access Manager - classes for accessing Apple's DAL and creating DAM sessions as well as support for the Butler database and for interactive SQL queries.

• Network Support - classes for implementing AppleTalk and TCP/IP protocols.

• TCP/IP Sample Server - a working example application which implements a TCP/IP finger protocol server and a TCP/IP telnet server.

• AOCE - classes to support AOCE and AppleEvents. A sample application demonstrates sending AppleEvents between two SmalltalkAgents environments over AppleTalk.

• BENTO - the classes and external method definitions for BENTO; includes sample classes for experimenting with the BENTO facilities.

• QuickTime Player - QuickTime classes and a simple example QuickTime player application

• Bench Marking Tools - implementations of Bruce Samuelson's Smopstone and Slopstone benchmarking tools.

• Sample Applications - several sample applications which demonstrate complex or sophisticated functionality.

Application Delivery Toolkit (ADT)

This is a integrated set of tools to extract an application from the development environment as a PIPO and to distribute the application royalty free. The extracted application is distributed with the runtime SmalltalkAgents kernel described above.

Requirements

To use SmalltalkAgents, you need:

• A Macintosh with a 68020, 68030, or 68040

• 3.7 MB of RAM for the application to run in (5 MB is recommended for best performance)

• 7 MB of disk space

• Macintosh system software 6.0.7 or later (System 7 is recommended for best performance)

• Both monochrome or color monitors are supported

• SmalltalkAgents is virtual memory compatible

• SmalltalkAgents is 32-bit clean

SmalltalkAgents Support

QKS intends to support the product using a comprehensive developer program divided into four categories (i.e., price levels) depending on the professional needs of the developer. These include new developer, corporate/in-house, commercial application, and consultant. As a new developer, one would receive the following for free except as noted:

• Technical Support - Registered users have access to the QKS Internet automated E-mail server and FTP site to download Frequently-Asked Questions, bug fixes as well as participate in the SmalltalkAgents forum. Includes 24-hour (or less) telephone, E-mail, or fax support of non-code questions regarding use of the SmalltalkAgents product.

• Services - Quarterly Newsletter available for $32/year

Quarterly Goodies (tutorial and sample code, new feature PIPOs) and Tech Note subscription available for $295/year.

• Training - QKS plans on offering a 3-day training course as well as a 40-hour self-paced tutorial. Contact QKS directly for prices and schedules.

Conclusions

When I received my review copy of SmalltalkAgents from the vendor, QKS, I approached the review project like a critical programmer from Missouri (not only “show me” but “show me in code.”) I was purposely skeptical and questioned all the claims made in the SmalltalkAgents sales literature.

Here’s what happened to me: I liked the product from the start! This is an important point since it is common for me to dislike a product at first then grow to tolerate it or even like it later. As I used the product, I started noticing a lot of little things that make the product excellent. These are those little delights we programmers like to discover in our products. It's like opening presents at your birthday party. Even now, as I sit at my Macintosh trying out various features, I must appear like I’m watching Pavoratti in an opera, as I throw air kisses at the screen. I often disturb Gracie, the cat (who sleeps on the monitor) as I shout “YES!, YES!” while discovering yet another carefully integrated feature. So complete, so carefully implemented, so usable is SmalltalkAgents that I have not been able to do it justice in these few pages. This is not only a very high quality product but also a very powerful tool which makes fundamental improvements on the original Smalltalk-80 standard. It is perfect for developing in-house applications for corporations. It is perfect as a tool for prototyping applications and then extending the prototype into the finished application all under the same roof.

On the other hand, SmalltalkAgents definitely requires machine resources to run efficiently. I’m willing to stick my neck out on this one. I think a better way of saying this is that SmalltalkAgents takes advantage of machine resources. The fact is that virtually all serious developers today have a big machine: extremely fast CPU, a lot of disk space, a big monitor. The age of the lone developer working on a Mac Plus is over. Since the average developer has a big machine, the development environment ought to take advantage of it and definitely shouldn’t be designed for a humble machine for the sake of smallness. SmalltalkAgents harnesses the big machine to provide an ideal development environment for the modern Macintosh developer.

For More Information

Quasar Knowledge Systems, 9818 Parkwood Drive, Bethesda, Maryland, 20814-4028. Voice: 800/296-1339, 301/530-4853; Fax: 301/530-5712.