Sunday, July 22, 2007

the image file, the virtual machine, bytecodes and more

Squeak files are different. As a newbie this was initially confusing for me and a potential barrier for uptake. But now it seems that they are different but better.

On the Windows version from Squeakland I have downloaded:
SqueakPlugin.image 12.5 MB
Squeak.exe 1.05 MB

On the Ubuntu linux version on the itshare laptop there is:
Squeak3.8.image 17.5 MB
SqueakV3.sources 13.9 MB
Squeak3.8.changes 13.6 MB
(I can't see the squeak-vm file?)

On the Ubuntu linux version on my older computer I have:
squeak-image_3.8.deb 11.1 MB
squeak-sources_3.deb 3.3 MB
squeak-vm.deb 0.5 MB


Smalltalk is its own development and runtime environment. Rather than executing programs on top of an underlying operating system layer which maintains file input-output and a file system, Smalltalk runs in an “image”—a single, live “file” that manages its own memory use, reads and writes itself to disk transparently when required, and which permanently maintains the entire state of the environment. It is this ‘live’ and persistent image which allows Smalltalk to be changeable “on the fly”—other languages require that one make changes to source code files and then recompile or re-run the files in order to make a change. (From Maxwell, p. 154)

Another explanation:
Most programming systems separate the program code from the program state. Program code is just text and can be stored in a text file. Program state is the exact place (a snapshot) of where the program has got to at a particular point of time. To store program state requires an image, an exact bit by bit description.

Smalltalk / Squeak is different from most other programming languages in that it does not separate code from state. It stores the entire application state in an image file.

(LISP is another programming language which also uses image based persistence. In the case of LISP the code is a form of data, once again the distinction between the code and the state is blurred)


A Virtual Machine is a software layer that provides us with a pretense of having a machine other than the actual hardware in use. Using one allows systems to run as if on hardware designed explicitly for them

An application is written for a virtual machine and can then operate on any platform or OS. How? The application is run on a computer using an interpreter of JIT (Just in Time) compilation


The image file consists of bytecodes, which is a highly compressed and optimized representation of the source code, but is not machine code (and therefore not tied to any particular hardware). Just-in-time compilation or JIT, refers to a technique where bytecode is compiled to native machine code at runtime. This technique was pioneered in Smalltalk in the 1980s.

The Squeakland educational version does not include the sources and changes files. But the full Squeak version does include sources and changes. These files are more important for developers.

The Sources file. This is where all the source code for Squeak is stored. However, the system can be operated without any source code, owing to its ability to decompile the bytecode methods into a readable and editable version of the original source code (only comments and temporary variable names are lost).

The Changes file. Everything that you do goes into the changes file as soon as you do it: Every DoIt, every new class, every new method. This means that if you crash Squeak, your work isn't lost. It's probably in the changes file. The changes file is just a text file -- you can copy out anything that you need to recover from. From the Desktop Menu, you also have access to several
changes utilities that let you look over your changes file and recover lost things. From the Desktop Menu, select Changes, then recent change log to find see all changes from every quit or save that you’ve executed.

Project files. My Etoys projects save as *.pr files, along with a gif image. Projects are used to capture and switch the entire display state. Therefore they store much of the state.

No comments: