MPW, C
Volume Number: 4
Issue Number: 1
Column Tag: MPW Workshop
Using Consulair C & TML in MPW 
By William Powell, Salt Lake City, UT
William Powell is a candidate for a doctorate degree in Geophysics from the
University of Utah, and is responsible for the design, documentation and delivery of
software used to operate the Voyager spacecraft while a technical assistant at the Jet
Propulsion Laboratory in Pasadena. He is presently doing research in the thermal
physics of the Colorado Plateau
I am highly resistant to changing development systems, but after after all the
fuss over MPW and reading J. West’s MacTutor article [vol. 3, no. 2] on the resource
tools in the Macintosh Programmer’s Workshop (MPW), I decided that I couldn’t live
without this product. Along with everyone else, I have frequently experienced
frustration from the limitations of earlier resource-building programs. I have also
wished for a programmable shell on my Mac for certain data processing operations
which I used to perform very conveniently on Unix systems. So I broke down and
purchased the APDA release of MPW, and a hard disk to hold it. I have subsequently
made some efforts toward integrating the MPW shell with older applications. I hope
that some of my discoveries and command scripts may be generally useful to others
who are using applications with MPW.
The programmable shell and tools of Apple’s Programmer’s Workshop (MPW)
give a new dimension of flexibility to Macintosh development. The MPW brings the
Macintosh a long step closer to the capabilities of more established development
systems such as those available in the Bourne shell or C shell of Unix systems. This
necessarily means that MPW has made a long step awayfrom earlier Macintosh
application-type development systems. MPW introduces a new class of compiled
program, the MPW Tool, which interacts with its shell more intimately than earlier
applications interact with the Finder and similar shells.
Bridging the gulf between the MPW shell and earlier Finder application
development systems is the topic for this article. I will present examples for my
development systems of choice, Consulair MacC and TML Pascal. There are three core
issues in joining the MPW shell and application-type development systems. First is
the problem of conveniently running applications in concert with programmable shell
scripts and the automatic make utility. Second is the problem of writing a new class of
program, called a MPW tool, using a development system which does not contain
provision for such a thing. Third is object file compatibility with the MPW standard.
This article will concentrate on the first item.
Many of the techniques discussed here are relevant to almost any programming of
the MPW shell and will be of interest even if the reader does not need the sample
command scripts for running development applications. This article includes
examples of advanced MPW editor commands, examples of complicated shell quoting
problems, and examples showing the use of shell variables. Information here about
launching applications from the shell and about the distinction between windows and
files is not found in the MPW Reference document. I also use the Make tool three times
in this article -- only one time involving building a program! I will assume that the
reader is slightly familiar with the shell and has access to the MPW Reference
document for more detailed background.
Motivation
Why did I make the effort to mix older development systems into MPW when an
assembler and C and Pascal compilers are already being distributed? One
consideration is budget; it is hard to justify the cost of anotherC or Pascal compiler
when the ones I have actually work just fine. Source portability is never perfect
across Macintosh compilers and I haven’t felt too anxious about converting yet another
program to yet another compiler. Also, as noted by F. Alviani [MacTutor vol.3, no.4]
the MPW system contains its own quirks, such as segmentation established in
compilation rather than in linking.
There may be hardware considerations as well. The MPW documentation suggests
that the MPW C compiler needs every byte of a 1M machine. This should be a serious
consideration for those of us who develop in C on the pre-1987 Macs. It is good that
the MPW system is forward looking in terms of newer machines, but many of us can’t
(or won’t) upgrade our hardware and software as frequently as it is offered to the
market.
On the other hand, the MPW shell offers the most flexible programmable shell
and scripting abilities available for the Mac. The text editing features of the MPW
shell are quite convenient, and more significantly, programmable. The first complete
and extendable set of resource tools resides in the MPW. The programmable shell
allows you to do things “your way” instead of locking you into someone else’s concept
of good development tools. It also provides a suitable environment for many less
human-interactive data processing needs.
So there are excellent reasons to add the MPW shell to the set of tools available to
most Mac programmers and there are good reasons for some of us to keep our older
development systems. The puzzle now is to find convenient ways to use the power and
flexibility of the MPW shell in conjunction with older Finder-based development
applications which have no facility to interact with the shell.
Applications and the MPW shell
The MPW shell is primarily a command interpreter, which parses lines typed by
the user and interprets them as some sort of instructions to be performed by the
computer. A simple command normally appears as a line of text. The first word on a
command line is the name of the command to be performed -- conventionally a verb
describing the action performed (e.g. Count, Make, Delete, Open, etc.). Subsequent
words on the command line are arguments which either indicate objects of the action
(e.g. files to be read or written) or specify modes or options for the action (choices
which would be selected with menus or modal dialogs in Macintosh applications). As
with most programming languages, syntax is available to produce compound command
statements from several simple commands as described here. The shell also allows the
setting and testing of values of variables. When I refer to variables in the following
discussion, I will use the notation {variableName}.
Commands are implemented in four different ways. Some are built into the code
of the MPW shell application itself. Some are separately compiled programs called
“MPW Tools” which run from within the shell, much as desk accessories run from
within other applications. The name of a ‘TEXT’ file containing one or more lines
which the shell can interpret as commands may itself be used as a command. Finally,
for compatibility, the authors of the MPW shell allowed the names of Finder
applications to be used as commands which cause the applications to start.
Applications and the Finder environment
Normally when an application runs, it starts off with a nearly clean slate. It
initializes most of the ROM toolbox managers. The only high-level data in the
application areas of memory which are normally available to an application are any
resources which were stored on the clipboard before the application was launched and
the “Finder Information”. The Finder Information structure is essentially a list of
files to be opened or printed by the application. For example, when a user uses
shift-clicking to select several documents and an application in the Finder, the names
of those documents selected by the user are passed to the application in the Finder Info
structure.
There are no standards for passing any other type of information from the launch
environment to the application. Some development systems and other systems of
several applications use “chaining” instead of “launching” [Inside Macintosh v. II, ch.
2], which allows resources and other data to be passed in the application heap.
Unfortunately this requires knowledge of coding details of the applications, and will not
be suitable for integrating an arbitrary application with the MPW shell. Applications
have been designed under an implicit assumption that all information about operational
modes was to be provided interactively by a human user. This leads to the most
common impediment in using applications as MPW commands -- it is very rare that
applications can complete their job without some human intervention (at the very
minimum it is usually necessary for the user to select “Quit” from the application
menu to return to the shell). This is unfortunate, because the function and mode of
applications such as compilers may be fully defined at the time they are invoked, and
the user intervention becomes an unnecessary redundancy.
Figure 2. The ins and outs of MPW shell variable scope.
In spite of the inconsistency between the highly interactive user interface of
applications and the more mechanized programmable MPW shell, it is possible to
develop procedures to integrate shell commands and applications (particularly
development systems) with reasonable success. While it is not possible to eliminate
human intervention in the applications, we can minimize the actions which the user
must perform. Some of the tips in this article might be viewed as an ad hoc system of
“MPW interface guidelines” to this end.
Applications and MPW
As mentioned above, the MPW shell allows us to launch an application by
invoking its name as a command. MPW maintains a shell variable called {Commands}
with a list of directories ( folders) to search for commands. If the application resides
somewhere in this command search path list, merely the filename of the application is
sufficient as a command. Otherwise the full pathname, with the volume and all
subdirectories leading to the application’s resource file must be used as the command
name.
The MPW shell provides the standard mechanisms for putting resources on the
clipboard or retrieving them from the clipboard. So passing data to or from an
application on the clipboard can be performed without any special considerations. The
only other information an application might expect from its launch environment is a
list of files in the Finder Information structure. The MPW shell has provided a
standard method to pass this information. Filenames which are to be passed in the
Finder Information to the application are simply listed as arguments on the command
line following the application name. Thus, we can fully configure the standard
application launch environment using mechanisms explicitly provided by the shell.
Example 1. Launching application with Finder Info.
There may be a number of applications which are commonly launched by the user
from within the shell; this will be e specially true if the user has completely replaced
the Finder with the MPW shell. I have found it convenient to add a “Run” menu to the
MPW shell, using the shell command “AddMenu”. This allows selection of my most
commonly used applications via menu choices. Such a menu is illustrated in Figure 1.
Most of the items in this menu are straightforward; selecting the menu item
simply launches the application because the command field of the “AddMenu” command
consisted only of the filename of the application. The last item on the menu,
“Word-Paint” is more interesting because it launches a Switcher set of MS Word and
SuperPaint. This menu selection launches the application Switcher and passes a
Switcher document in the Finder Information. The command line to perform this
appears as an argument in the “AddMenu” command which created the menu item:
AddMenu Run Word-Paint ∂
‘XP40:Word:Switcher XP40:Word:Word∂+SuperPaint’
The word AddMenu is the command which will add this item to a menu in the MPW
shell. Three arguments follow the command name. The first argument is the word
“Run” which is the name of the menu we wish to affect. The second argument
“Word-Paint” is the text of the item being added to the menu. The curly-d (∂) is
followed immediately by a return and signifies that the command continues on the
following line. The third argument is the text appearing between single quote marks.