=== Top of the Swiki === Attachments ===

FAQ: Squeak Executables

How do you make a Squeak executable that can be distributed?

It has been asked a number of times in a number of ways on the Squeak Mail List -- with a variety of possible approaches suggested. There should be a useful mechanism for creating and using fine-grained modularity in Squeak 2.4 -- from there it is a short step to packaging applications. Other approaches are in the works.


There are a few other issues to deal with when creating an end-user application:


1. Preventing end-user access to developer tools (bulletproofing)

At 3:13 PM -0200 1/9/00, andregarzia@openlink.com.br wrote:
>I created a little game using smalltalk and i want to distribute it
>to the end user, but i do not want the user to damage the
>app by "clicking around" and "dragging and dropping" in the
>browser.
>
>Is there some way to compile the code or assemble an image that
>does not contain the development environment in it?

If your application is in morphic and if it does not involve any text-bearing SystemWindows, you may find that you can directly use a bulletproofing facility already present in the system. (If you're not in morphic, or if you're in morphic but do need text-bearing system windows to be present in your application, you may need to make some further simple modifications to get the complete effect.)

Note that the process described here does not strip out the development environment -- it simply makes it inaccessible.

Here's what to do:

a. Put the expression "Preferences disableProgrammerFacilities" into your "do..." menu.
b. Set everything about the image exactly as you want it to appear when your target user fires it up. Make certain there are no windows left on the display. (To make it possible for the user to exit from
the resulting image to be, put some sort of "exit" control somewhere on the screen.)
c. Snapshot your system (just for safety).
d. Choose that "Preferences disableProgrammerFacilities" from the "do..." menu
e. When asked to confirm that you really want to do this, say yes.

All the bulletproofing steps will then be undertaken at once, and the system will be snapshotted in that bulletproofed state. This will be a "save as" operation, so you'll be asked to provide a new name for the image.

(If subsequently you want to make any changes, fire up the earlier, prebulletproofing snapshot you saved in step c, and resume the sequence starting with step b.)

The resulting image will be bulletproof -- no hooks into the development environment, no ability to snapshot, no way to see code, no way to get a menu, no way to evaluate an expression, no cmd-period (alt-period) interruptability, no "missing sources" warnings, no cmd-key shortcuts, etc. All the user can do in the resulting image is use the ui afforded by what's on the screen at the moment of bulletproofing.

-- Scott Wallace

Also see FAQ: Simplifying the Interface.


2. Stripping out unused code to reduce the size of the image (if desired)

The further process of eliminating unnecessary code is more involved, but there is a fair amount of support for it in Squeak. Look in SystemDictionary>>majorShrink and related methods.

-- Dan Ingalls

Running #majorShrink discards most non-fundamental subsystems within Squeak, including Morphic, so it must be run from within MVC. For those who have not used #majorShrink before, do the following:


(A SystemDictionary>>majorShrink operation should reduce the size of the image to under 1 megabyte.)


3. Distributing an end-user Squeak application for various platforms

Lex Spoon has created a sample application with Windows, Linux and Macintosh end-user distributions at http://chaos.resnet.gatech.edu:8000/~lex/hanoi/. This is meant to encourage further discussion of what format Squeak applications should appear in, for "end-users" who do not already have Squeak installed. This process could potentially be automated.