Dan,

this sort of mechanism (storing resources in the executable) was  
used in early NeXTStep version but later abandoned for the  
"file-wrapper" and "bundle" concepts now used in MacOS-X.

A file wrapper is just a directory that is treated as a single  
file/document by GUI tools.  An example is the htmld wrapper, this is  
just a directory with a single index.html and its associated images.  
 However, the Workspace treats this directory as a double-clickable  
document.

A bundle is a specific kind of file wrapper that contains loadable  
code as well as other resources, all stored as individual files  
within the wrapper.  There are specific methods for accessing the  
code(by class) and the other (file based) resources by type.

The morphic 3D stuff, for example, would make a great bundle, with  
the plugin stored as the code resource and that part of the image  
stored as a "squeakimage" resource, additional model files could also  
be easily stored within the bundle, simply by placing the files  
there.

The Squeak GUI could also live in its own bundle, again including  
the necessary VM support as well as the Squeak code.

An application is just a specific kind of bundle, one whose  
directory has an ".app" extension and which contains a stand-alone  
code-resource.  It can contain other bundles amongst its resources or  
reference external bundles.  External code is typically stored in  
"frameworks", which are, once again, just another special kind of  
bundle.  With this model, "single app" and "multiple files" are not  
contradictory requirements.


Marcel

> From: Dan Ingalls <Dan.Ingalls at disney.com>
>
> Andrew, I like this idea a lot.  Plus, along the way, we ought to  
be able to to knock
> off the single-file app configuration for at least some platforms. 
>
> VM gurus:  How would the following play on your favorite platform...? 
>
> 1.  Assume we have a single app file consisting of three sections: 
> 	VM (need not have all features, nor be very latest release)
> 	Installer image (Can be a small subset of release, somewhere  
between
> 		our tiny (240K) and mini (540K) images)
> 	Installer data (compressed images of all files)
>
> 2.  The VM, when it starts up, looks at how big it is.  If it is  
bigger than some
> 	amount then, before looking for another image, it scans itself 
> 	for the start of an image and, if found, loads that and runs it. 
> 	Note that this is just what is needed for single-file  
clickable apps.
>
> 3.  Finally, the installer reads the last section of the same  
file, performing
> 	the decompression and any other appropriate organizational stuff. 
>
> It would appear that the only missing piece is how to glue  
arbitrary data
> (installer image and compressed files) onto the end of an  
executable file (a
> Squeak VM) in such a way that the host OS will only load the first  
part, and won't be
> unhappy about the presence of the second part.
>
> We discussed this briefly over a year ago WRT single-file apps and  
there was
> concern at the time that this approach would run afoul of many  
virus protection
> schemes.  Anyone know what's possible and what's not here?
>
> If there is a viable approach for each of the major platforms,  
then we should
> certainly give this a try.
>
> 	- Dan