Two files are involved, tclkit and the starkit. Each consist of two parts:
1. tclkit, the executable file is:
A. a large binary prefix, i.e. a statically linked tclsh or wish
(plus a few extensions linked in: incrtcl, tclvfs, and metakit)
B. a metakit dataset, loaded as VFS - containing all standard Tcl
scripts, i.e. lib/tcl8.4/ and such (plus some vfs support pkgs)
In effect everything you get is an installed version of Tcl, with or
without Tk, but wrapped up together in a single file with the scripts
that are needed to make it go, and some additional bits that extend
the capabilities of the package as a whole.
2. the application starkit:
C. a tiny tcl prefix, which is what starts running first
D. a metakit dataset, containing the files "inside" a starkit
The application, which is a bunch of scripts and libraries made to
look to tclkit as if it were a file system, although in fact it is
structured as a metakit dataset.
A then starts "running" script C (exactly the same as when tclsh runs a tcl script file). C asks A to reopen #2, but as metakit database. To complicate things a bit: C does that using a package called "starkit", which is stored in part B of tclkit. The starkit package opens file #2, calls the vfslib package (also stored in part B) to "mount" that file, and then has access to all of D as a virtual file system. The last thing the starkit package does, is source the (virtual) file /bin/main.tcl, which is stored in part D.
That's it - main.tcl is in control and does what the app wants to do.
Tclkit knows how to run a tcl script, and what it sees at the beginning of a the script it launches tells it that this in fact a starkit, so it should interpret the rest of the file in that way. There are rules built in to tell tclkit where to go to get the next script to actually deliver the application, which makes for flexibility: you can set things up so that the starkit behaves differently depending on how it is invoked.