On Mar 31, 3:48 pm, Bernd Paysan <bernd.pay...@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas wrote:
> > If you're thinking in terms of compiling applications on the spot,
would
> > it make sense to have a virtual file system? So you could put all your
> > files into one big file and users who install it all can then have
just
> > two files to deal with -- the Forth system and the application file.
> Actually, you could put the virtual file system (e.g. a zip archive) at
the
> end of the executable itself, and then have only one single file for
> everything. That's not that bad as idea, even if I prefer that the user
is
> able to extract the sources, too. If the virtual file system happens to
be
> a standard zip archive, the user can have the advantage of a single file
> *and* sources he can manipulate (by extracting the zip archive,
changing,
> and then using zip to manipulate the archive).
> The executable in front would be the Forth loader, and it would use the
zip
> archive to load the image and the sources from.
Indeed the executable in front could just be a self-extractor, which
would load the Forth from the archive with the desired start-up
options.
> However, with the typical setup.exe on Windows and package manages on
Linux,
> I don't see a need for that - even though there may be hundred of files,
> the user sees a single icon, and they expect to install programs through
> setup.exes (which also provide an uninstaller). Also, when you have more
> than a single program, things would be a bit more difficult (but not too
> much - you probably can use the zip archive as generic starter, and an
> additional parameter would be the source file to load).
It would be used for a single program ... which could be a wrapper
that accesses others. Once you start installing systems of programs,
you get to the reason for the installation management systems built
into or bundled with the OS.
It wouldn't be for permanent installations ... indeed, there is an
appeal among some users for programs that simply sit in a directory
and are executed from a shortcut. This allows:
* try it out to see whether to keep it
* low profile install to subdirectory with shortcut / symbolic links
(which means uninstall has to be accessible from the program itself)
* full fledged install
Scaling up from a simple executable is easier than scaling down from a
full fledged install.
> Any volunteer who would evaluate which zip-like archive has the best
sup****t
> as virtual filesystem, and put an add-on to Gforth or bigForth for using
> such a virtual filesystem to retrieve image and sources?
If a self-extracting executable system exists for a zip archive system
that allows starting a binary with access by that binary to the rest
of the archive, that all that is needed is to do a SAVE-SYSTEM of the
underlying Forth system with the initialization set to read the start-
up from the correct file in the archive.
And, yes, this could readily be before OBJECTS.FS is loaded from
archived source.
The simplest way to make the source itself immediately available is to
use a widely sup****ted archive format that is capable of accessing
self-executing archives using normal archive tools. That is, I would
suppose, the .zip archive itself, which can create self-executing
files that can be opened like .zip archives. For niche systems, that
best leverages existing efforts by other developers for those systems.
|
