As mentioned in the previous section, the starkit file has a small header containing the initialization script that executes the externally available tclkit
. What would happen if we replaced this header with a binary code of Tclkit? In such cases, we would get a Starpack, a self-contained starkit, and a Tcl interpreter—all in one single file. This is the solution we are searching for in this chapter—a standalone executable file without any dependencies that does not require installation or configuration!
A Starpack file can be created in the standard way using the wrap
command, but with the additional flag -runtime
, which specifies what Tclkit binary should be put together with the starkit that is being produced. A typical usage is:
c:workspaceTclHelloWorld>tclkitsh-win32.upx.exe sdx.kit wrap hello.exe runtime tclkitsh-win32.upx.copy.exe
5 updates applied
Note that the Tclkit specified with -runtime
must be different from the one actually executing this command, because a running Tclkit instance cannot copy itself. In this case we simply copied it, but here comes the beauty of this solution—you can use any Tclkit you want to, even for other platforms like Linux or Solaris. Therefore, you will be able to produce versions for different systems without even having access to them!
By default, when the output filename is of the form<app-name>.exe
, or simply<app-name>
in case of non-Windows platforms, SDX will search for the<app-name>.vfs
directory holding the contents of your application.
After executing the hello.exe
program, you will notice that it works in the same way as the .kit
version:
c:workspaceTclHelloWorld>hello.exe
Hello World one more time!
The benefits of using Starpacks are:
The limitations of using Starpacks are:
exec
to run programs inside VFS will not work correctly.3.142.114.19