Re: Images and libraries (was: OBJECTS.FS Question)
- From: Bruce McFarling <agila61@xxxxxxxxxxxx>
- Date: Tue, 1 Apr 2008 08:22:47 -0700 (PDT)
On Mar 31, 3:48 pm, Bernd Paysan <bernd.pay...@xxxxxx> 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 support
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 supported 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.
.
- References:
- Re: Images and libraries (was: OBJECTS.FS Question)
- From: Bernd Paysan
- Re: Images and libraries (was: OBJECTS.FS Question)
- Prev by Date: Re: BETWEEN
- Next by Date: Re: The Promise of Forth
- Previous by thread: Re: Images and libraries (was: OBJECTS.FS Question)
- Next by thread: Re: BETWEEN
- Index(es):
Relevant Pages
|
|
