I’ve made it a new year’s resolution to break the habit of using .NET, improve my C++ skills and learn TCL/TK. Indeed, I’m planning on using C++ for the Cryptology practicals (we do get some choice here, apparently), with the aim of eventually releasing a more professional version of the XeroCrypt software. In fact, I’m getting interviewed shortly for a job that might well involve developing and evaluating real-world solutions that absolutely must be fit for purpose. Following a recent discussion with someone regarding encrypted comms on social networks (another real-world problem), I set about looking through libraries that handle application-specific crypto tasks in C++, and I somehow came across TCL.
TCL appears a fairly easy language to pick up, being something of a C/BASH hybrid, and apparently it can be integrated with C/C++ code. Despite being something of a niche programming language, there are enough reference materials and IDEs out there supporting it.
For whatever reason, it’s in the realm of the arcane and esoteric from the perspective of someone who’s been taught programming in Java, Visual Basic, C++ or whatever mainstream language. Although a fair number of applications for Linux were developed with TCL/TK, the only time I recall actually hearing it mentioned was in passing at the Unified.Diff presentation on node.js last year. According to David Welton’s blog, Sun Microsystems invested in the improvement of TCL/TK for a while, before ditching it in favour of Java.
The downside is the tclsh interpreter (or tclsh.exe for Windows) is required to run the code in Windows and UNIX-based systems, and most people won’t have that installed unless they already have other applications using it, and perhaps the biggest drawback is the method of expanding functionality by adding separate extensions prevents it becoming truly portable. For example, if I developed something like XeroCrypt using TCL, users would need tcl itself, tcllib and tk libraries to run it. This is partly the reason we get dependencies, now solved by archiving the source code with XML files that tell today’s package managers what else to pull from the software repos.
Anyway, the following are the more interesting features of TCL/TK that caught my eye.
Reading and Writing Files
Since TCL enables us to access external files, we can do some other interesting things, such as modularise code, store runtime data and interact with network interfaces. We can also work with virtual files in system memory (instead of the disk), which might be useful for cryptographic stuff, although that part should really be implemented in C/C++. In fact, Password Gorilla was coded in TCL/TK to do exactly this. The file manipulation features integrate perfectly with the UNIX filesystem and permissions. A program an also access and manipulate database entries with the TDBC extension.
The file access features enable us to break program down into several files that execute code from each other, although this is done by using the source command to call the relevant one. A modular TCL software could have a master file and others for handling specific functions. Alternatively, it could have a file dedicated to storing global variables accessible to all the source files.
Sockets are essentially virtual files we can read/write to, just like a conventional file, and these could be thought of as buffers for the actual network interface. There are two types we could use: client and server. In addition, tcllib provides a nice collection of binaries for encrypting communications. This enables the creation of anything from messengers to heavy duty server platforms.
WiSh (Windowing Shell)
And that’s not all. TCL and its TK extension can be used for creating graphical interfaces with relatively little code. This is the bit I jumped straight into, and the example below (download file here) was a graph plotting application that I stripped down to just 54 lines of code to demonstrate the interaction between a window canvas and buttons.