TKS uses a virtual file system (VFS) which allows to transparently access packaged TKX archives as well as real local filesystems.
The VFS is read-only and all contained files have to be specified in a project file (TKP), which is used to map logical to local file names. The project file is evaluated when testing a project during development and finally when the project is converted to a compressed TKX archive.
This process makes it possible to package an application in a single, compact and gzip compressed file which can easily be distributed / published. Furthermore, exchanging e.g. an image file for another is merely a matter of changing the project file; no knowledge of the actual script-code is required.
Example: [project] name="example" created="8.November 2003" version="0.318309886" [authors] "programming" ="Bastian Spiegel <bs@tkscript.de>" [chapter] name="main" "code/mymodule.tks" ="mod:mymodule.tks" "code/main.tks" ="main.tks" "data/any" ="data/foo.bar"
Use the File class to access local files. The PakFile class can be used to transparently map files to either the local filesystem or the TKX virtual filesystem. Use StdInStream, StdOutStream (static globals) to access the standard file streams.
To avoid the problems that arise with the different kinds of presentations of pathnames under different operating systems, absolute pathnames should be avoided if possible.
The / char, which fortunately has become common even under Microsoft Windows (which uses the \ char by tradition) should be used to separate directories. Drive-letters and mount points should not be used for portabilities sake.
Note: For reasons of security =), the access to local files (except the ones listed in the project file) can be entirely prevented by using the command line switch --nolocalfiles.
Scripts are placed in the (virtual) code/ directory; all files in there are processed in the given order upon application start. The prefix mod: substitutes the current module searchpath.
Please consider that the script sources will be included in the packaged archives (-in order to be compiled to bytecode, then native code at runtime, if the application sources contain compile{ /*...*/ } blocks).
A TKS project (TKP) can be compiled to a compressed TKX file which will then contain all files required for execution, i.e. those listed in the project file.
Example:
tks -c bobfield.tkp
The suffix .tkp may be omitted:
Example:
tks -c bobfieldAfterwards, a bobfield.tkx file should be located in the current directory.
Hint: Creating TKX files requires zlib support.
The world wide web can be used to distribute a TKX file to other users. The file must be uploaded to a web server which has been configured to recognize the application/x-tkx file type. TKS also uses the MIME (Multipurpose Internet Mail Extension) type mechanism on the client side to integrate into the operating system and/or the web browser.
The following section describes the server-side configuration of the widely used Apache Webserver although this example can easily be carried forward to other systems:
pxxxxxxxx@kundenserver:~ > cat .htaccess AddType application/x-tkx tkx AddType application/x-tks tks
This will assign unique MIME types to files using the suffices .tkx and .tks.
By installing the TKS runtime module (tks-setup.exe) these MIME types are bound to the tks application so that it will automatically be started when a user selects a .tkx file; e.g. by clicking on a link in a web- or filebrowser.
Note: Users of alternative operating systems (e.g. Linux) need to manually take care of the TKX MIME type integration. This can usually be done easily using the browsers user interface (KDE, GNOME..).