In the history of the Macintosh, only a few programs have developed a strong, cult-like following. The last program to do this was HyperCard; I think the next program with cult potential is UserLand Software’s commercial Frontier program and its loyal sidekick, Frontier Runtime, a $25 shareware program. Frontier lets wireheads create scripts that can do neat and extremely practical stuff. Frontier Runtime – which requires no head-mounted wires, less checkbook input, and half the RAM – executes those scripts.
Frontier scripting offers functionality previously only available via extensions or not at all, but without the expense and potential conflicts brought about by extensions. Right now, the Frontier family is trying to cross the road of a chicken and egg situation, and to get to the other side, it needs more Runtime users and more script writers creating Frontier scripts.
Frontier has gained some early popularity in large organizations where a network administrator can write scripts to provide extra functions to users, thus avoiding the cost and hassle of buying and installing commercial extensions and utilities. The next place I anticipate Frontier scripts catching on is on the Internet, where scripts can easily be stored and passed around, just like freeware and shareware utilities.
But back to HyperCard for a moment, because there are some analogies. Imaginative authors have used HyperCard to create gigabytes of stacks ranging from the useful to the trivial, from the insightful to the inane. Yet many stack developers long for more power than HyperCard provides internally; hence the popularity of the XCMD and XFCN collections from developers like Frederic Rinaldi. Frontier and Runtime provide much of that power internally with hooks into the Macintosh operating system and what they lack can be made up with Apple event-aware programs like the StuffIt family.
Unlike HyperCard, which can both read and create stacks, Runtime is a read-only tool, working with scripts created in Frontier. (However, we should remember that Apple is now shipping the read-only HyperCard Player with new Macs, at least in the US – they’re not doing even that in Sweden.) Keep in mind that many people use HyperCard in a read-only mode much of the time, using stacks others create and distribute. Runtime could – with the proper set of circumstances – be even more useful (though perhaps not so occasionally silly) than HyperCard to the average Macintosh user. We’ll look at Frontier and its power in more depth next week, but for the moment, I’m willing to venture that Runtime is more important.
So what exactly is it? — Frontier Runtime is a moderately sized application, (it likes 512K of RAM, half of Frontier’s 1,024K memory partition) and includes an Object Database that stores a number of types of information for use by scripts. Runtime runs most Frontier scripts, and can thus control most parts of the Macintosh operating system, including such tasks as copying, moving, deleting, and creating files, making aliases, checking file and folder sizes and contents, and so on. Special scripts, called agents, run at specific times, and other special scripts, called droplets, work on the file dropped on them in the Finder. Scripts can be made into stand-alone documents, or desktop scripts, for the ones that you only want to use occasionally with Runtime.
FinderMenu — The product that makes Frontier Runtime compelling comes from Steve Zellers, who by day works for Berkeley Systems (the After Dark folks). In his obviously copious spare time, Steve created an ingenious hack called FinderMenu. It’s a free utility composed of an extension and an application (probably destined to become a single faceless application) that places a Scripts menu in the Finder when Frontier or Runtime is active, no mean feat since Finder 7.0 is not particularly Apple event-aware. FinderMenu comes with a number of useful scripts immediately available, including one that allows you to click on a folder in the Finder and select a menu item or hit a command key to back it up to another folder. This is useful not just as a safety backup, but also as a logical backup that protects you from any deleterious changes you might make when playing. FinderMenu also has a synchronization script that is especially useful for PowerBook users, and includes scripts that can find text within files, set creators and types, create aliases in specific places (such as the Apple Menu Items folder, Startup Items folder, etc.), and create a list of applications to launch and folders to open from that single Finder menu.
Those functions may not sound tremendously innovative, but consider what other utilities you would need to duplicate them. I’d probably back up individual folders only manually (and thus not at all), find text with Super Boomerang, set creators and types with DiskTop, create aliases with Alias Director, launch applications from a menu with Now Menus, and open folders from the Apple menu. You may or may not already rely on those utilities, but you must admit that it’s an impressive feature set from a single extension and two applications. Most programmers I know shy away from running tons of extensions because of the uncertainty it brings to the Macintosh environment, and FinderMenu and Frontier Runtime can take over for a number of popular trap-patchers. I know that I’m ready to swear off some of them after suffering through a series of unexplained crashes.
Of course, there’s nothing stopping you from adding other scripts to your Scripts menu except the availability of those scripts. Here are some ideas for Frontier script writers to consider donating to the Macintosh community. I download files in a number of formats, BinHex, StuffIt, Compact Pro, and so on, into a single folder, and it would be nice to have a script go through and, communicating with StuffIt Deluxe or StuffIt Lite, defunk those files no matter what format they are in. I’ve written the rudiments of such a script, and such a script could work as an item in the Scripts menu or as a desktop script, one that you double-click from the desktop to activate.
Another idea is to create a script, probably a desktop script since it wouldn’t be used all that often, that would clean out a System Folder after an Easy Install. Wouldn’t it be nice to quickly and automatically eliminate DAL, the AppleTalk LQ ImageWriter driver, and similar junk?. For safety, this script would move those items to a Junk Folder on the desktop rather than deleting them; that would give you a chance to double-check.
Speaking of deleting files, a well-written script could do clever things like make it easy to delete files of certain names, types, or creators (like Word Temp files, perhaps, or maybe aliases without originals), again moving the files to a Junk Folder for manual checking. With a little work, a Frontier agent script might even be able to perform the same functions as TrashMan, which deletes files after they have been in the Trash for a specified amount of time.
The possibilities are literally limited only by your imagination (and someone’s ability to script in Frontier). In addition, if you’re a network manager type, think of the utility of providing a core set of functions to everyone in your organization without continually purchasing, installing, and troubleshooting additional software. And of course, keep in mind that Apple events can travel a network, which further increases the possibilities, including scripts that ensure public hard disks contain only a specific set of files. More on that next week.
If you wish to check out Frontier Runtime and FinderMenu (and I strongly recommend that you do), they (along with other Frontier scripts and related files) are available for anonymous FTP from <syrinx.kgs.ukans.edu> or <dartcms1.dartmouth.edu>. You can also get a list of files available from the Dartmouth machine (home of the Frontier LISTSERV, which we’ll discuss next week) by sending email to:
with this line in the body of the mailfile:
CompuServe users can check out UserLand’s GO USERLAND forum for all the latest and greatest, plus continuous discussion with Dave Winer and Doug Baron, co-developers of Frontier.