How About an InstallSqueak Image?
Marcel Weiher
marcel at system.de
Wed Jun 16 07:25:11 UTC 1999
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
More information about the Squeak-dev
mailing list
|