Hi,

Dwight Hughes wrote the following regarding creating a new image from
scratch:
> There is currently no way to do this in Squeak. You might take a look at
> a bit of discussion on bootstrapping an image in the Squeak FAQ on the
>Squeak Swiki: http://minnow.cc.gatech.edu/squeak.471

Following the above link provided by Dwight I found some intersting tidbits
that provoked these thoughts:

1a) Where does Squeak Image file come from?

Quote from above link: "Some bits in this Squeak are descended from
Smalltalk-76. They have been loaded and saved in a 'core image' many
times."

1b) Does this mean that Squeak's image file is actually a
smaltalk-76-modified-copy-modified-copy-etc... of the original Smalltalk 76
image file? Please confirm and elucidate if possible. (Do Alan, Dan or
other Smalltalk originators have any historical info on this? If so please
comment). 

1c) What is the exact pedigree (so to speak) of the Squeak Image? 

1d) How was the original Smalltalk 76 file generated? 

1e) What are the copyright issues when using this method of image
reproduction?

2a) LittleSmalltalk can generate it's own Image File

Quote from above link: "Budd's "Little Smalltalk" has this capability I
believe (for a greatly simplified implementation)."

I can confirm that Little Smalltalk does indeed have this ability. In fact
if you compile the sources for your architecture (as I did for a NextStep 
machine many years ago) you must run a utility to create an image (or 
world file) before you can get LittleSmalltalk running - as easy as eating
your favorite pie.

A short C program does the Image birthing procedure (file creation). The
code is not all that complicated and makes use of C subroutines in the
LittleSmalltalk VM C source for manipulating the image. Basically core
objects, such as "true", "false", "nil" and others need to be instantiated.
A system dictionary needs to be set up. Classes loaded... Basically any
environmental objects that the VM needs to get running once the image file
is loaded.

2b) It should be straight forward to add this capability to Squeak. What do
you think? How would you add it?

3) Digitalk(ObjectShare) VisualSmalltalk uses a combination of copying an
existing (17k) starter image AND having you add in your own classes. But
you still do need a working development image so this is only a partial
solution.

 It does allow you to load in your own classes:
	a) statically (they are filed into the image or statically loaded as
dynamic link libraries or actually smalltalk link libraries (sll); or,
	b) dynamically (again from the smalltalk link libraries) at runtime by the
image as it boots.

Smalltalk Link Libraries are files (of some unknow internal format) that
Visual Smalltalk uses to store objects, compiled methods, or 'what have
you' in them - you basically can put anything you want into them. 
There are big problems with the Digitalk approach, though - convience,
reliability, source access, versions of sll's, etc... that make this
approach difficult to use and quite fragile and brittle. 

The brittleness of this approach leads to many sunken images, thus I don't
recommend this approach for Squeak.

4) A Squeak Custom Image Creation Capability Would Be A Good Thing
The fact that the Squeak Image is derived from existing images is a bit
scarry and very interesting at the same time (a lot like the way biological
organisms reproduce! ;--).

5) Image Corruption Concerns
Biological systems can tolerate modifications of a bit of information in
the DNA, in fact these are know as mutations and further the evolution of
the replicated organism's offspring. 

Allmost all information systems, with the exception of "genetic based
software",  including  Squeak Smalltalk can't tolerate bit errors in them
very well. Random mutations in squeak does not further it's development.
(Mutations by programers may further Squeak's development however ;--).

Most bit errors can lead to failure of the image (any research on this?)
unless it's in the middle of a string's data. For example, 'Hi there' being
changed to 'Hi Zhere' might not crash a running application, but if an
essential object's oop or header gets changed look out and expect debug
windows or your squeak vm to crash.

Also, there are situations and bugs that can corrupt your image
'environment' rendering it unusable.

Creating a new image from an existing corrupted image could lead to hard to
find bugs.

5b) What steps does Squeak take to prevent or detect image corruption?

6a) Clean Custom Images
It seems to me that there are plenty of cases where you want to generate a
clean custom image where you know ALL the contents of the image. Generating
a new image by copying from an existing image could carry objects into the
new image that you might not want. By explicitly choosing what to put into
an image you can get the best possible minimum size for the image.

For example, let's say that I want to generate a new Image for a small
application and I only want to put in the objects that are needed by that
application. There are two possible routes: 
	a) use the ability of Squeak to remove classes and objects from an image;
or,
	b) generate a new image from scratch (as in 2 above).

Both of these approaches have their advantages and disadvantages which I
think that we should explore further.

6b) Are there any other possible approaches or variations of creating an
image?

7a) In conclusion, I think that it would be best to have both of these
capabilities.

7b) How would we go about adding the "create a new image from scratch"
ability to Squeak to complement the existing "remove what you don't want
and save a new image" ability? 

7c) What objects and environmental settings are needed to construct a
working image?

Peter