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.
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).
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?
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
|
