Tom Pittman is no stranger to these pages.
In the first year of this publication's existence, back when it was called Dr. Dobb's Journal of Computer Calisthenics and Orthodontia and the personal computer industry was a handful of crazy hackers trying build computers in their garages, the founders of this venerable journal published a rough spec for a programming language that could be implemented on almost any machine, requiring practically no memory. It was a clever design, and it required some cleverness to see how to implement it. The language was Tiny Basic, and one of the few people who took Dennis and Bob seriously enough to actually implement Tiny Basic was Tom Pittman.
Tom has never lost his interest in programming challenges. This interest has led him down strange paths. When Apple released HyperCard in 1987, Tom got intrigued with this user-programming tool, and wound up writing CompileIt!, a tool that compiles HyperTalk code into HyperCard external commands and functions.
Now, HyperCard externals are a nice idea. By building into HyperCard the means of extending HyperTalk, hence HyperCard. XCMD developers could replace commands and functions of the language with more powerful or specialized versions; access the ROM Toolbox to do things otherwise completely beyond HyperCard's capabilities; and, with the release of a better XCMD interface in HyperCard Version 2, control external windows that didn't have to look or act like HyperCard stacks. The external interface, like the loophole in DOS that allowed developers to create TSRs, was a hacker's dream.
But it wasn't a stack developer's dream, because stack developers couldn't, generally speaking, write the things. These XCMDs formerly had to be written in another language like C or Pascal, by someone who understood a lot more about programming than the average HyperTalk coder. CompileIt! broke down this barrier. With CompileIt!, anyone who could write HyperTalk code could write XCMDs.
That was the goal, and for Tom it was more a programming challenge than a product idea.
This brings us to this year, when Tom's efforts began to get more generally interesting.
As I said, Tom approached CompileIt! initially as a programming challenge. Only when it became successful did he begin to think of it as a real product, which today it is. CompileIt! is a must-have for any serious HyperCard stack developer.
The problem with CompileIt!, though, is that that's all it is. It's interesting only to HyperCard stack developers or to those using Macromedia Director or some other XCMD-supporting application/tool. All right, you can create other kinds of code resources, other than XCMDs, using CompileIt!, but why bother? There are existing tools, like ResEdit, specifically designed for building resources, and there is no dearth of tools for writing and compiling code. For an experienced Mac programmer, CompileIt! fills an unfelt need.
That wasn't good enough for Tom, and he set out to make it more generally useful. One approach would have been to turn it into a general code-development tool that could be used to develop full applications. But again, why? Why go into competition with compiler vendors?
The approach Tom took instead was to create a separate, complementary product that allows XCMDs to become stand-alone, double-clickable applications. This was made possible by the improved XCMD interface that HyperCard Version 2 brought; in particular by the possibility of creating external windows, owned and controlled by individual XCMDs.
The thing to do, Tom decided, was to create an application shell that the XCMDs could live in, and that's what his new product, Double-XX (available from Heizer Software, Pleasant Hill, California), is.
This alone is sort of technically interesting. It makes my rough analogy with creating TSRs in DOS a little more germane: You can now use the capabilities supplied by the operating system vendor to do things it never intended. Using Double-XX to create little stand-alone apps feels like hacking the system. But Double-XX has some features that make it more interesting and useful than this.
There are a lot of reasons to take a look at Double-XX. Some of these are Tom's or Heizer's reasons, some mine, and some, perhaps, are yours. Since I know mine best, I'll state them, clearly labeled as such.
The bad news first: The interface to Double-XX is a HyperCard stack. I can't pretend otherwise. But don't let that fool you; this is a powerful tool for its intended purposes. Also, the apps you develop using Double-XX don't look anything like HyperCard stacks, because they aren't. They are external windows controlled by XCMDs which are in turn controlled by an event loop that Double-XX supplies. The apps don't typically include any of the usual HyperCard elements: cards, fields, and the like. (It is, however, possible to put these HyperCard user-interface elements into your apps, and it can be done easily. This can be very handy, as discussed below.)
When you first begin to use Double-XX, here's what you encounter:
Since Double-XX appears as a stack, you'll see a card. Buttons on this card help you in assembling the pieces of your app: the XCMD, of course, but also menus and other resources.
The Resources button brings up a list of resources associated with your project (it's a project until you compile it into an application). The list can incude XCMDs, XFCNs, and resources for cursors, menus, icons, text, and so forth. You can add resources from other stacks, including the resources supplied with Double-XX, but for the most part you'll have to step outside Double-XX to create new resources (using CompileIt! or some other tool).
Menus are handled by a separate button. When you click on it, you see a scrolling list that contains all menus, menu items, and messages associated with the menu items. A message can be a HyperTalk command, a series of HyperTalk commands, or, more likely, an XCMD call.
Any Mac application that is to appear on the Finder desktop as an icon must have ICN#, BNDL, and FREF resources for the Finder to use. It also needs a unique creator type and a vers (version) resource containing version number, copyright information, and country code. Buttons and fields on the card walk you through creating these things, but you have to call Apple yourself to register your creator code if you plan to distribute your app.
Two other elements on the card are of special interest if you want your app to communicate with other apps. These are the AppleEvents check box and the aete Resource button. If you check the former, the system will send your app AppleEvents, and it had better be ready to handle them. Double-XX will automatically include code to handle the oapp, quit, dosc, and eval messages, but all others will fail unless you supply code to handle them.
The aete Resource list is the starting point for supplying this code. It lists all (or any) AppleEvents your app handles. The syntax is complex, but Double-XX gives some help in building the aete resource. Reading the AppleScript manual and various Apple documents on AppleEvents and the Object Model is also helpful.
So to build an application, you collect or write the XCMDs that do all the things you want your app to do, then package them into an app using Double-XX. Double-XX provides the parts that the Finder wants to find and plugs the XCMDs into its event loop.
What's missing here is the user interface. Since Double-XX itself doesn't give you much help in building the user interface, you need to look to other sources for that. WindowScript (also marketed by Heizer) is a good UI tool and works well with Double-XX and CompileIt!. But if you're willing to use a HyperCard-like interface, with HyperCard-like buttons, fields, and cards, you can do the job just using the (nonsupported) stack compiler that comes with Double-XX. You just create the HyperCard-like UI elements as though you were authoring a HyperCard stack, and the stack compiler turns them into resources that become part of your stand-alone application.
(The stack compiler is not complete enough for compiling existing stacks into stand-alone apps. That would be nice, but it's not what it's for. Its purpose is simply to give you a convenient way to slap a HyperCard-like UI onto your stand-alone app. For some apps, this can radically reduce the time you'd spend making the things usable.)
Double-XX is a nifty little tool, in my experience. It comes with decent debugging aids. You can use it in combination with C or Pascal. And you can replace elements of its interface and debugging support with tools you like better.
What's nice about Double-XX, apart from the facts that it makes it easy to develop stand-alone apps and that these apps are small, is the power you can put into your apps. Since the target user for a small, rapidly written app is likely to be the developer him or herself, that's particularly interesting.
Tom has built into Double-XX a HyperTalk interpreter (or actually a HyperTalk-subset interpreter). It supports the bulk of HyperCard's language, although some language elements not meaningful in Double-XX are not supported. That's reasonable; Double-XX creates standalone applications, not HyperCard stacks, so references to stack elements like fields and cards are not relevant.
This interpreter can be made available to the user of your app. What this means is that you can, with virtually no extra effort, make your app scriptable. With slightly more effort, you can decide what elements of the language you don't want to support and trap commands that involve those elements.
There are several ways you can make this scripting capability usable. You can include in your app the MessageBox XCMD, which is supplied with Double-XX. It implements a message box similar to HyperCard's into which the user can type and execute single-line commands. Or you can create a window in which the user can type multiline blocks of code that can be executed using the Do command.
The interpreter also makes it possible to leave parts of the functionality of your app uncompiled, either for the user or for you to tweak. For example, you have a special operation, specialOp. Rather than supply a specialOp XCMD, you put the HyperTalk code for the operation into a TEXT resource. Then in the menu card you associate a menu selection with the command Do getTEXTresource (nnnn). getTEXTresource is a supplied XCMD; nnnn would be the number of the TEXT resource.
You could even, with a little more effort, track user actions and turn them into code, saving the code as executable TEXT resources as above. In other words, you can create a watch-me mode in your app.
If you check the AppleEvents check box in the Double-XX stack, your app will inform System 7 that it is AppleEvents-aware, and the system will send it AppleEvents. As mentioned, Double-XX will handle four AppleEvents messages--oapp, quit, dosc, and eval--and you're on your own for the rest. You make your app handle other messages by supplying aete resource information and XCMDs for them. But you can also override Double-XX's handling of the four messages in the same way.
The interpreter is also able to catch AppleEvents and send them to other AppleEvent-aware programs, but only if they are running on the same machine. The next version may support cross-network AppleEvents.
You can code your app in such a way that it does everything via sending AppleEvents to itself. This might seem like overkill for the small, ad hoc applications likely to be generated with Double-XX, but there are some reasons to consider doing this. An app that can be driven from the outside, say via AppleScript, is more than an app. It's a packaged chunk of functionality, and you or some user may find an entirely unexpected use for it.
It's also intriguing to reflect that any application that responds to AppleEvents will automatically become voice controllable when speech input really takes off on the Mac. I'm sure there are people who enjoy typing, but as someone who has never really befriended the keyboard, I find this possibility very appealing.
This has been a pretty enthusiastic report, and I feel compelled to find something to complain about. I guess I'll pick on the name. The name Double-XX is supposed to mean "Double-click your XCMDs." I dunno about that; I look at it and immediately parse it into "XXXX." My guess is that it was named by Prince's press agent.
Copyright © 1993, Dr. Dobb's JournalGeneration X
Generation XX
Seeing Double
If any of that appeals to you, maybe you should look at Double-XX. I'll tell you a little more about it to help you resolve that maybe into a definitely or a nah.The XX Encounter
Let's Face It
When the User is You
Talking to Yourself