Related Info: Notification Mgr Resource Manager Segment Loader
Event Manager

Forth News

By Jörg Langowski, MacTutor Editorial Board

Now that we haven’t had much news about Mach2 Forth from Palo Alto Shipping for a long time, MacForth Plus from Creative Solutions seems to be the only commercially available Forth for the Macintosh. Makers of other Forths, please correct me if I’m wrong.

You haven’t heard much about MacForth Plus in my column, even when it was still a Forth column. The reasons were different: the subroutine-threaded native code implementation of Mach2 which was faster than the token-threading used by MacForth, the fact that Mac Toolbox calls in Mach2 resembled much more those of other languages, the Mach2 assembler’s syntax which was close to the standard Motorola syntax, the possibility of writing stand-alone code resources in Mach2. MacForth, true, would make for more compact source code, and had a much more elaborate development environment, lots of tools, a better editor and much easier Forth-level debugging. But all in all, Mach2 seemed a much more ‘Mac-like’ way to program in Forth, so we stuck to that with our examples. One of the things I didn’t like in MacForth was the way they redefined most of the Mac Toolbox interface, of course that was to make things easier for the beginning programmer, but kind of irritating when you were used to a different way of using the Mac system calls, or just to their different names.

Anyway, those discussions are becoming pointless, because there really has been no support for Mach2 from Palo Alto Shipping for more than a year. The last version is 2.14, and crashes royally with System 7. You can easily patch it, however, so that it still works, and we’ll see into that later; first, for those of you who are thinking of starting on a Forth project, let’s take a look at the most recent version of MacForth Plus, the first and (at this time) the only commercially supported Forth for the Macintosh.

The first good news is that this Forth seems to be a very stable product; although none of the files on the three disks have creation dates later than March 1990, the whole system runs flawless under System 7 with or without virtual memory.

MacForth Plus now supports stand-alone code. You can write XCMDs, drivers, FKEYs, and so on. A very simple example, creating an FKEY that beeps, is given in the manual:

: beeper30 sysbeep ;

defines a word that beeps on execution. When you then write

sa beeper

you create stand-alone code that has the same behavior as the word under the Forth system. That means, since MacForth uses token-threading, it has to add a ‘mini-kernel’ to the Forth code which executes the tokens, and code to set up the registers for the Forth world and restore them after execution to their old values. A handle to the stand-alone code segment is contained in the global variable sa.handle, so to test your FKEY you write

sa.handle ascii FKEY 5 “ Beeper” add.bag.resource

and cmd-shift-5 will beep at you. The ‘resource bag’ to which the FKEY is added by add.bag.resource, is a resource file that MacForth opens on startup and which contains your custom resources that your program might need. Resources can be added and deleted from that file during a development session.

Stand-alone code is just one example of the multitude of features of MacForth. A way of object-oriented programming is supported through the use of ‘Actels’ (for ‘active elements’), and MacForth vocabularies themselves are such actels.

Another very interesting and useful concept used in MacForth are ‘relative chains’. This is some kind of linked list, and it is used in the MacForth kernel in a number of places. For instance, there are the so-called Restorer and Exodus chains. These are lists of words to be executed at startup and exit of the MacForth system, so you can easily add setup and cleanup routines. The Eventer chain can be used to add special-purpose event handlers. It is executed in the main event loop: the first word in the chain receives an event code, decides what to do with the event, processes it or not, and then passes on a flag (true if processed and false if not) and a new event code to the next word in the chain, and so on until the end of the chain is reached.

This Eventer chain could be one way of implementing Apple events into MacForth, because the standard system that was sent to me for review does not support them. But it should be easy: first write Forth words that process the four required Apple events and a word that installs these handlers. (The handlers would have to be filter procedures that can be called from the toolbox; but there is a utility in MacForth that allows you to define such procedures). The word that installs the handlers would be linked into the Restorer chain, and the high level event processing into the Eventer chain. I’ll show you an example in my next column.

So in fact, MacForth is System 7-compatible, but not yet System 7-aware. But I have no doubts that the - very active - MacForth scene will come up with the necessary extensions very soon (maybe they are already on Compuserve, to which I have no access).

Mach2 - System 7 compatible

Steve Wiley, a MacTutor reader in Utah, has done Palo Alto Shipping’s work and figured out a set of patches to Mach2 (2.14) which make it compatible with System 7, although not System 7-aware; high-level event processing has still to be added. Steve turns out to be a colleague of mine, he is a molecular biologist at the University of Utah. Besides his science work, he likes hacking the Mac with Mach2, and has written a beautiful application for operating a densitometer from the Macintosh that is part of a commercial package. Here are some of his comments on Mach2, and the code that makes it System7-compatible.

“Jörg, I would be glad to document the changes and how to make Mach2 System 7 compatible. Mach2 is still not 100% compatible. The debugger will not work, I think because they changed some of the interrupt vectors in System 7. This is not a problem to me since I use TMON professional for debugging. This works very well with MACH. I am currently modifying the event loop so that MACH2 will accept and send AppleEvent messages as well as writing a small program that will automatically compile a multisegment MACH program. My current program have 8 segments and compiling each individually is a real pain.

The archive contains a copy of a modified MACH2, the modified IOTask (multifinder fixings) and a Microsoft Word document describing the modifications. You can use this information in any way you would like. [We have enclosed only Steve’s code on the source code disk, because obviously we cannot distribute a copy of the modified Mach2 - JL]. I have also enclosed a folder containing my densitometer program written in MACH2. [not included on the source code disk, either, but some of Steve’s comments follow - JL]. Version 1.0 of this program has been shipping for over a year and is sold all over the world by Bio-Rad. We have just released version 1.1 of the program (the one enclosed). There is on-line help available. This on-line help facility has an interesting history. The design came from a MacTutor article. The help facility described in MacTutor was written in C and was a code segment that theoretically could be added to any program through ResEdit. I tried this and found that the original program was buggy and would crash every now and then. After several days of frustration, I decided to completely rewrite the program from scratch as a task in MACH2 and to include some improvements (such as displaying a custom SFGetFile dialog if the Help file cannot be found). Total time to completely write this task was about 4 hrs. I was really surprised at how easy it was. The ease of MACH2 programming should be evident in all of the fancy stuff I put in the program. I am particularly proud of several features. Look at the Molecular Weight ruler for calibrating a scan. On color Macs, the routine uses color icons. On B&W Macs, custom bitmaps are used. The program automatically configures itself for either. The smooth animation is from using offscreen bitmaps and CopyBits. The code to do this is really quite small (most of the code in the program watches user interactions). A second feature to look at is the Import file dialog. Any given file can contain any number of separate scans (densitometric tracings). The Import File dialog allows you to look inside of the different files without opening them and select different scans for loading. You can select any number of scans from different files from different folders and volumes. When you click on “finished”, all of the information is imported from the different sources and consolidated. The list module is a modification of your design for a reminder (remember the article on the notification manager?) I used popup menus to display a number of different lists in the same window. This turned out to be a lot more difficult that I could have imagined! I ended up writing a custom LDEF to allow tabs to be set for the different lists. Finally, I am very pleased at the speed of the program. If you want to see the number of data points in each of these scans, plot a scan and choose “Link to Editor...” from the File menu. This will show all of the data. Some of these scans have thousands of data points, but only take seconds to draw. You should also note that all of the modules work simultaneously. Change a ruler mark and the list module is updated and the marker moves in the Calibration marker. The interactive nature of the program has made it a great favorite around here. I hope you realize that this program would never have been written if wasn’t for your articles in MacTutor that showed me how to do these things. [Thank you for the feedback - JL]

Well, I have to get back to my experiments. In reality, I am a Cancer Biologist who analyzes the dynamics of growth factor receptors modified by site-directed mutagenesis. The programming is just an “on occasion” hobby that lets me think that I have some power over nature. Certainly the complexity of the computer pales in comparison to living cells. However, by managing to figure out the computer, it gives me hope that I can figure out growth control mechanisms in cells.”

After these general remarks, part of a network conversation that we had over the last few months, here’s Steve’s description of his modifications to Mach2:

“Below I have described how MACH2 can be modified to run properly under System 7, and still remain compatible with older systems. There are three major incompatibilities with the current version (2.14) of MACH. The first is that MACH 2 is not MultiFinder aware. The second is that MACH expects Monaco 9pt font to be a standard system resource (not true under System 7). The third involves changes in the System 7 interrupt vectors that cause MACH’s resident debugger to crash. [The fourth problem, as you will see below, is that Mach2 does NOT run with virtual memory under any circumstances at the moment. This is a serious drawback, e.g. compared to MacForth, and cannot be fixed by simple patches, but needs major rewriting of the Forth system - JL].

The first two problems are easy to fix. The third cannot be easily patched, but is really not a problem since “real” debuggers (such as the excellent TMON Professional) are far superior to the limited built-in facility. My programming environment currently consists of QUED/M 2.09, MACH 2 and TMON together with a few utilities written with MACH 2 itself. Under System 7, this is a great combination and works quite smoothly (especially with a Mac IIfx!)

A commercial application that I wrote with this system under System 7 (a densitometric analysis package) is compiled from 40 separate files into 8 segments and comprises 335K of code including resources. Total recompilation of this program from scratch takes about 2.5 minutes! The program has every Macintosh interface element available, including tool palettes, custom lists, popup menus, color displays, custom file dialogs, offscreen drawing, on-line help and so forth. I am currently including balloon help and Apple Events in the system and will be glad to describe how these features can be included in MACH. The point is that MACH is fully capable of accessing all features of the new generation of Macs.

The changes made in MACH 2 have two aims. The first is to allow the programming system to run and compile under System 7. The second is to allow programs written and compiled in MACH 2 to run properly. Since “MultiFinder” is always running under System 7, the most important change is to make MACH 2 fully MultiFinder aware and compatible. This means implementation of WaitNextEvent instead of GetNextEvent as well as Suspend/Resume events. You published a nice article on the implementation of WaitNextEvent in MacTutor, but as pointed out by Murray Anderegg, this implementation assumed that the compile-time environment was the same as run-time. A more ambitious effort to modify the main MACH 2 IOTask to be MultiFinder compatible was provided by Murray Anderegg in an upload to Genie, but his implementation also has limitations. Basically, Anderegg assumed that all sub-tasks in the MACH 2 event loop are launched before the first execution of the main event loop. The main loop would then install default Suspend/Resume routines into each tasks. For small programs, this may be true, but is hardly likely in a more complex program. A more general (if inconvenient) approach is to simply install a Suspend/Resume handler into each task as they are activated. This is will always work and has the advantage that each task can use its own custom handler and do as much (or as little) as necessary during suspend or resume. A second problem with Anderegg’s patch was that he wrote a Suspend/Resume handler as if it was a pseudo Activate/Deactivate event. I found that this frequently crashed my programs. In my approach, I modified the Suspend/Resume routine published in the article by David Kelly and David Smith in the Feb. 88 issue of MacTutor. This routine may perform extra (unnecessary?) work, but I have found that it works under all testing conditions.

The following are the patches made to the IOTask code necessary to make MACH 2 fully MultiFinder aware. Most of these changes were originally written by Murray Anderegg, with the exception of the DoSuspendResume code. These are the additions made to the IOTask code made available from PASC.

[Additions see listing - JL]

After these routines and patches are installed, it is necessary to use ResEdit to modify the SIZE resource. This will allow the system to pass the appropriate events to MACH. Remember, there are two resources to modify. One is within MACH 2 itself. This it the one which is used within the programming environment. The second is the MACH.RSRC file which will be included within the compiled and “TURNKEYed” application itself. Use ResEdit to open the SIZE -1 resource. Set Accept suspend events and Can background to true (1). The other settings should be set to false. Save the resource.

The next step is to install Monaco 9pt font into the MACH 2 resource fork. This is the font that MACH uses for its interactive screen. Apparently, MACH checks for the availability of this font when it is first run. Since System 7 uses True Type fonts, the absence of a true Monaco 9pt font resource in the system generates an error and prevents updating of the interaction screen. However, since the resource manager will always check the current application for the availability of a requested resource, we can circumvent this problem by directly installing this font into MACH itself.

Use Font/DA mover on a pre-System 7 Mac to create the Monaco 9pt file. Select “Monaco 9” from the current system in the left scrolling window and click “Open” under the right window. When the standard SFGetFile dialog appears, click on the “New” button to create a file and copy the font into it. Close Font/DA mover and use ResEdit to copy the FOND and FONT resources from this file into the MACH resource fork. There is no need to copy this into the MACH.RSRC file.

While you have the MACH resource file open, you should use this opportunity to inactivate MACH’s debugger since using this will crash the system. Simply open the DEBG resource (ID=1) and replace the number there (probably a 1) with zero. This will inactivate the debugger menu item and prevent accidental crashes.

These are all of the changes necessary to make MACH run nicely under System 7. I have used this configuration extensively for the last several months without any crashes or significant problems. There are still a few, mostly cosmetic problems that I have been unable to fix. These deal with the screen display and listing of loaded text. MACH issues a PAUSE command after the printing of every character to the interactive screen. Since the main event loop calls the WaitNextEvent every time a PAUSE is encountered, all open programs as well as the system under MultiFinder are given multitasking time for every character printed! This makes for extremely slow screen listings even when using a Mac IIfx! I haven’t figured out how to patch the character printing (EMIT) routines to PAUSE only every line or so. Perhaps PASC can be encouraged to fix this problem as well as some of the other minor bugs left in the system.

Despite what may seem the trouble involved in this modification, I am still extremely pleased with the MACH 2 and use it extensively for very complex and high-level Mach programming. I have used Waymen Askey’s Trap Compiler to extend the MACH 2 environment to use the new traps documented in Inside Macintosh Volume VI and to fix the infrequent bugs found in the old trap calls. The fact that a part-time computer hobbyist like myself can modify a programming environment to keep up with new system changes says a lot about the power and flexibility of that environment. I am sorry that PASC is so negative about the commercial possibilities of improving MACH. This is certainly not because of the quality of the product, but is more likely because of the ignorance of the general programming/hacker community of its power and flexibility. As a university Professor, I know many examples where the truth of an idea had little bearing on its acceptance. I also know that those who ignore useful and powerful concepts for more popular ones are making things more complicated for themselves. However, the reality is that any programming environment requires a large investment in time and energy before one becomes proficient in its use. People are often afraid of wasting their time on a programming language/environment that may become obsolete. If more commercial applications were released using MACH, then people would be more confident about investing time in its use. Perhaps this demonstration of its extensibility will show that it will not become obsolete soon.”

When I tested the modified Mach2, it still crashed my system, non-recoverable by ExitToShell, very bad. After a while I figured out that the virtual memory was the problem. Neither Mach2, nor the demo application that Steve sent me, would work with VM. Steve’s comments:

“ I was quite surprised at your comment about virtual memory and MACH2. I must admit that I never even thought about trying it under VM. When I have VM running, *everything* on the Mac starts crashing. It is a very ill-behaved system. For example, QUED/M 2.09 and TMON Pro will sporadically crash under VM even though both are claimed to be compatible. [I have quite good experiences with VM, used it for several months now, and rarely get any unexpected crashes, even though some of the programs on my Mac are rather old versions. But then, I never seem to have major problems with my Mac - JL]

My answer was to buy 8 MB of memory and shut VM off. Now all my programs are happy and so am I. But there is still a problem with MACH2. I traced execution of the program to find out why it crashed and discovered that the problem is due the patch to _LoadSeg that MACH2 uses. You may have heard about this a few years ago in conjunction with swapping A7 registers. Every time that _LoadSeg is called, it uses a large amount of stack space. Since the multitasking scheme in MACH2 uses multiple stacks (a separate one for each task), this necessitated the declaration of a large (>16K) stack for each task. Very wasteful. The solution to this was to create a common stack and switch to this before calling _LoadSeg and switch back to the original stack after trap completion. The end of the _LoadSeg routine was intercepted (so the stacks could be switched back) by using the exception vector triggered by the _debugger trap found at the end of _LoadSeg. This scheme worked extremely well up until now. The problem is that System 7 implements virtual memory (at least in part) through patching _LoadSeg itself. By using TMON to follow program execution, I found that turning on virtual memory causes _LoadSeg to be accessed at an extremely high frequency. In addition, the location of _LoadSeg in memory keeps jumping. Apparently, System 7 uses multiple _LoadSeg routines and switches these in and out on-the-fly depending on whether the segment is being loaded into “real” versus virtual memory. [Actually, if you think about it, it’s amazing that with tricks like these System 7 behaves so well - JL] Well, as you might imagine, this completely invalidates the MACH2 patches, resulting in invalid stack pointers and the crashes you have described. I thought that the simplest solution to this problem was to remove these patches and let MACH2 run with the normal _LoadSeg trap. Alas, the main I/O task appears to assume that it needs a small stack and can no longer run with the original _LoadSeg trap installed. I tried everything, but all attempts to use the original _LoadSeg trap crashed MACH2 under *all* systems. My only recourse is to write to PASC and plead with them to fix this problem. It should be a simple fix, but requires access to the original source code. [Yes, PLEASE, PASC: if you have no intentions to support Mach2 anymore, and don’t think one can make money on Forth for the Mac, do release the Mach2 sources so that others can continue your work! - JL]

That concludes my column for this month. Language Systems have just sent their Fortran 3.0 in beta release, I’ll take a look at it and report on it next month. Looks very promising. Some more Forth news next month, too. Till then.

Listing 1:

// Constants, resource definitions, etc.
$60 CONSTANT WNETrap#
 \ This is the trap number for WaitNextEvent.
$9F CONSTANT UnkTrap#
 \ This is the trap number for Unimplemented.
308CONSTANT gInBackgroundOffset    
 \ offset in user area for notification
304CONSTANT SuspendResumeOffset  
 \ offset to task-specific routines
-1 CONSTANT TRUE
0CONSTANT FALSE

Header MFThere 1 ,

\ This resume notifies each task 
\ of a Suspend/Resume event

: gInBackground! { truthValue | homeTask nextTask -- }
 STATUS -> homeTask\ point to each user area
 homeTask -> nextTask
 BEGIN
 truthValue nextTask 2+ gInBackgroundOffset + !                
  \ notify task
 nextTask 2+ @ -> nextTask
 nextTask homeTask = \ loop through all tasks
 UNTIL
;

: DoSuspendResume{ | wptr taskptr -- }
 EVENT-RECORD Message + @ activateMask AND
 IF
 FALSE gInBackground!\ signal tasks to resume 
 CALL FrontWindow -> wptr \ get front window
 wptr 0= NOT
 IF ( you have a front window )
 wptr windowKind + W@ L_EXT 0<
 IF ( this is a desk accessory )
 EVENT-RECORD Modifiers + W@\ post an activate event
 activateMask OR 
 EVENT-RECORD Modifiers + W!
 EVENT-RECORD 
 CALL SystemEvent DROP
 ELSE
 wptr CALL GetWRefCon ?DUP
 IF
 wptr CALL SetPort
 SuspendResumeOffset + @ EXECUTE \ execute task’s routine
 THEN
 THEN
 THEN
 ELSE
 TRUE gInBackground!  \ signal tasks to suspend
 CALL FrontWindow -> wptr
 wptr 0= NOT
 IF ( you have a front window )
 wptr windowKind + W@ L_EXT 0<
 IF ( this is a desk accessory )
 EVENT-RECORD Modifiers + W@\ post a deactivate event
 $FFFE AND 
 EVENT-RECORD Modifiers + W!
 EVENT-RECORD 
 CALL SystemEvent DROP
 ELSE
 wptr CALL GetWRefCon ?DUP
 IF
 wptr CALL SetPort
 SuspendResumeOffset + @ EXECUTE
 THEN
 THEN
 THEN
 THEN
;
 
\ This is the patched event table
CREATE (EVENT-TABLE)
 DC.L NextEvent-”(EVENT-TABLE)”-4 
 \ (0)  Null event.
 DC.L “DoMouseDown”-”(EVENT-TABLE)”-4
 \ (1)  Mouse down event.
 DC.L NextEvent-”(EVENT-TABLE)”-4  
 \ (2)  Mouse up event.
 DC.L “DoKeyDown”-”(EVENT-TABLE)”-4
 \ (3)  Key down event.
 DC.L NextEvent-”(EVENT-TABLE)”-4  
 \ (4)  Key up event.
 DC.L “DoKeyDown”-”(EVENT-TABLE)”-4
 \ (5)  Auto key event.
 DC.L “DoUpdate”-”(EVENT-TABLE)”-4 
 \ (6)  Update event.
 DC.L “DoDisk”-”(EVENT-TABLE)”-4 
 \ (7)  Disk event.
 DC.L “DoActivate”-”(EVENT-TABLE)”-4
 \ (8)  Activate event.
 DC.L NextEvent-”(EVENT-TABLE)”-4
 \ (9)  Not used ?
 DC.L NextEvent-”(EVENT-TABLE)”-4
 \ (10) Network event.
 DC.L NextEvent-”(EVENT-TABLE)”-4
 \ (11) Driver event.
 DC.L NextEvent-”(EVENT-TABLE)”-4
 \ (12) Appl-defined event #1.
 DC.L NextEvent-”(EVENT-TABLE)”-4
 \ (13) Appl-defined event #2.
 DC.L NextEvent-”(EVENT-TABLE)”-4
 \ (14) Appl-defined event #3.
 DC.L “DoSuspendResume”-”(EVENT-TABLE)”-4
 \ (15) osEvent.

: GetNextEvent (  - f )
 \ If an event occurs which should be handled, 
 \ GetNextEvent will return a true flag. The event 
 \ code and any other event information will be 
 \ returned in the EVENT-RECORD.
 \ Changed for MF support using Jorg’s code 22 XI 88     \     - M. Anderegg
 [‘] MFThere @
 CASE
 TRUE OF\ Yes, we have WaitNextEvent.
 everyEvent EVENT-RECORD 1 0 
 WaitNextEvent
 ENDOF
 FALSE  OF\ No, we don’t have WNE
 CALL SystemTask
 everyEvent EVENT-RECORD 
 CALL GetNextEvent
 ENDOF
 ENDCASE
;

: WNECheck( - )
 \ This routine is executed the first time through the 
 \ I/O Task main loop. It leaves the truth value for the
 \ presence of the WaitNextEvent Trap at MFThere. 
 \ This modification is necessary, since Jorg’s 
 \ modification worked at compile time instead of run 
 \ time.  - M. Anderegg - 6\89.

 WNETrap# CALL GetTrapAddress
 UnkTrap# CALL GetTrapAddress
 =
 IF \ WaitNextEvent is absent 
 FALSE
 ELSE
 TRUE
 THEN
 [‘] MFThere !   \ store result as flag
;

\ Main event loop

: (IOTask) {  | dialogflag eventflag --  }
 WNECheck
 0 gInBackground!
 BEGIN
 BEGIN
 GetNextEvent  -> eventflag
 DialogEvent?  -> dialogflag

 dialogflag
 IF
 HandleDialog
 ELSE
 eventflag
 IF
 HandleEvent
 THEN
 THEN
 eventflag 0=
 UNTIL
 PAUSE
 AGAIN ;

(  Each task written by the programmer must include an Resume/Suspend 
handler to be run by this code. This handler is installed in the same 
fashion as overriding the default event-handling. After each task is 
ACTIVATEd, but before the main task loop is encountered, the routine 
address is obtained by ‘ticking’ and stored in the appropriate USER offset 
location where it can be found by the IOTask. )

\ User variables used to communicate between 
\ program tasks and the IOTask
308 USER gInBackground
304 USER SuspendResume


\ these routines are ‘Global’ and can be used 
\ by all the tasks in a program
GLOBAL
: DoResume { | wptr - } \ generic resume code 
 CALL FrontWindow -> wptr
 wptr CALL SetPort
;

GLOBAL
: DoSuspend { | wptr - }
 CALL FrontWindow -> wptr
 wptr CALL SetPort
 wptr $10 + CALL InvalRect\ invalidate window
;

\ Example of a task-specific Suspend/Resume handler
: DoMyS&R
 gInBackground @
 IF ( a suspend event )
 DoSuspend\ execute global routine
 \ task-specific code goes here, 
 \ such as converting a clipboard or fixing a menu
 ELSE ( a resume event )
 DoResume
 \ task-specific resume code goes here
 THEN
;

\ The following shows how the task-specific Suspend/Resume handler should 
be installed.
: Start-Task
 ACTIVATE
 ( other code etc )
 [‘] DoMyS&R SuspendResume !
 \ store the suspend/resume handler
 ( other code, event loop, etc )
;