FAQ: Squeak Executables <strong>How do you make a Squeak executable that can be distributed?</strong>
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 at some point -- from there it is a short step to packaging applications. Other approaches are in the works. - <b>Creating a two-file distribution</b> This is the simplest option, which works on all platforms. Basically, you just get rid of all of the unnecessary files (.changes, .sources, etc.) which are only needed for development, and you just keep the *VM* and the *.image file*. The VM is the executable (.exe) which end-users can double-click on. (Or you can usually double-click on the image.) - <b>Creating a two-file distribution.</b> This is the simplest option, which works on all platforms. Basically, you just get rid of all of the unnecessary files (.changes, .sources, etc.) which are only needed for development, and you just keep the *VM* and the *.image file*. The VM is the executable (.exe) which end-users can double-click on. (Or you can usually double-click on the image.) - <b>Creating a single-file distribution.</b> If you literally want to create a combined VM and image, then you can try "Smalltalk saveAsEmbeddedImage". This works on some platforms (e.g. non-Carbon Macintosh), but not on others (e.g., Unix). VM implementors should look at #snapshotEmbeddedPrimitive if they want this functionality themselves.
Usually, however, people are not literally desiring a single EXE, but some other property of a distribution. Here are some thoughts on a few possible issues:
! 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*.
! Stripping out unused code to reduce the size of the image
If you like to reduce the size of the image before releasing it consult the *Smalltalk majorShrink* page.
If you don't pass on the sources and changes file along with the image - what you probably want to do when distributing only an "exe" - you have to change the method #openSources:andChanges:forImage: in the class *FileDirectory*. Replace the method body with
<tt>SourceFiles _ Array with: nil with: nil</tt>.
Note that beginning with 3.3alpha, a *Modules* system is being put in place which will allow Squeak to be easily broken down into smaller parts (and thus smaller standalone applications). Then *Smalltalk majorShrink* will no longer be necessary.
! *FAQ: How do I prepare an image/executable to start up with my application*
! Distributing an end-user Squeak application for various platforms
It is nice to distribute software to people who themselves don't know how to use Squeak. This is no different in Squeak than with anything else. *Julia Explorer* is one example, and *Distribution Scripts* is a page dedicated to making the process very smooth.
See also *Production Squeak* for actual examples of commercial and non-commercial uses of Squeak.
