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: * ''expect'' - includes Tcl and [Expect] packages * ''expectTk'' - includes Tcl, Tk, and [Expect] packages * ''tcl'' - includes Tcl and [TclX] packages * ''itclsh'' - includes Tcl and [Itcl] packages * ''bltsh'' - includes Tcl and Tk, and [BLT] packages * ''tcldomsh'' - includes Tcl and [TclDOM] packages * ''tixwish'' - includes Tcl, Tk, and [Tix] packages ...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 [extension]s 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 [extension]s started to use the new features to support dynamic loading. At the same time, these [extension]s 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 [load]ed 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 [load]able 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 [extension]s 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 [load]able 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 [Starkit]s 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 [extension]s are now configured to build only a [load]able package by default, omitting the construction of any ''big wish'' program. ---- [Category Glossary]