C programs of a particular type are known as big wish programs. They have this name because of their similarity to the wish program that is part of Tk.
Unless you are completely new to Tcl/Tk, you are familiar with the program tclsh. With tclsh you can interactively enter Tcl commands and see the results of their evaluation. Or you can name a script file for tclsh to evaluate. The Tcl interpreter within tclsh starts out with all the built-in commands provided by the Tcl package.
The program wish is quite similar to tclsh. The primary difference is that the Tcl interpreter within wish starts out with all the commands provided by both the Tcl and Tk packages. The commands of two packages are combined in one interpreter right from the startup of the program.
A big wish program is one like wish that combines Tcl and one or more packages in one program. Examples include:
...and there are others.
In the early days of Tcl, the construction of a big wish program was the only way to extend Tcl with commands provided by an extension.
One challenge in those days was if you had a Tcl script that made use of commands provided by a package other than Tcl, you had to be careful to choose the right big wish to evaluate that script, so that it had access to all the commands it used. For example, if your script used the signal command, it would need to be run with the tcl program, and not with the tclsh program, because signal comes from TclX.
Tcl 7.5 (released 1996) introduced the load command. This allowed C-coded extensions to be added to a Tcl interpreter dynamically at run time. Also new in Tcl 7.5 was the package command that offered a higher level interface to control the source-ing and load-ing of new functionality into a Tcl interpreter on demand. The authors of extensions started to use the new features to support dynamic loading. At the same time, these extensions continued to support embedding, and continued to be distributed with machinery to build an appropriate big wish program.
One valuable simplification from this time was that scripts no longer needed to be concerned about what program was used to run them. A [package require TclX] in a script would be sufficient to supply the signal command that script needed to function. The [package require TclX] would succeed the same whether the tcl program was running, so TclX was present from startup, or whether tclsh was running, and TclX was dynamically loaded as demanded by the script.
(One significant exception to this general history was the Tk extension. For a number of reasons, best described elsewhere, Tk continued to be available only in wish and other big wish programs, and did not support load-ing via a [package require Tk] for many years. The first release of Tk that could be [package require]d was Tk 8.4.0 (released in 2002). Even with Tk 8.4, the result of a [package require Tk] in tclsh is not quite the equivalent of wish. See tclsh vs. wish.)
For several years after load became available, big wish programs have remained useful, and have continued to be used. In part this is simple inertia -- why fix what is not broken -- but in part it is because big wish programs have been able to solve one of the challenges of the loadable extension approach, dependency management.
Say a script makes use of the interact command. Because the interact command is provided by the Expect package, you include a [package require Expect] in your script. You want to send that script to someone else to use. It's fairly simple to tell them "Here's a script; you'll need to run it with a program named expect." It's somewhat more complex to tell them, "Here's a script; you'll need to run it with a program named tclsh, and, oh yeah, make sure there's an extra package named Expect installed with your tclsh." The difference in complexity grows greater with each additional package your script needs. Dealing with this complexity had a number of effects. First, people often tried to do without commands provided by extensions altogether, preferring pure-Tcl solutions. Second, people continued to rely on big wish programs far longer than they might have otherwise.
Over time, other solutions to the dependency management problem have arisen. So-called batteries included distributions, such as ActiveTcl, have been released, and grown popular, making it more reasonable to assume that a [package require] of a popular extension in a script will succeed. Another approach has been to make use of virtual file systems embedded in single-file executable programs to be able to depend on the availability of loadable extensions because they are carried in the same file as the script that [package require]s them. This approach was first known as a scripted document, but later became known as a Starkit. Tcl 8.4.0 (released 2002) includes virtual file system support, providing Starkits a firm base of technical and moral support. The Tcl Dev Kit suite of tools from ActiveState is focused on supplying Starkit solutions for application delivery.
As of 2003, with their remaining advantages fading away, big wish programs are falling out of favor. Recent and pending releases of several extensions are now configured to build only a loadable package by default, omitting the construction of any big wish program.