Tclkit

A Tclkit Is an executable Tcl interpreter that can be combined with a starkit to produce a starpack.

See Also

Tclkit Mobile

Tclkit on a PDA.

Differences between tclkit and tcl

The (Few) Differences between Tcl and Tclkit

How do I use a .kit file?

Swisskit

An elaborate build of Tclkit Lite for Mac OS X.

Wikit Command Line for Windows95

Tclkit Kitgen Build System

A tclkit based on vlerq and metakit.

Tclkit and Starkits (pdf)

A sample chapter on Brent Welch's site from his book, Practical Programming in Tcl and Tk.

Using zip files like a .kit file

Prefixing a zip file with a self-extractor stub results in something like a .kit file.

LUCK

Lean Undroidwish Construction Kit (undroidwish/vanillatclsh/vanillawish) for different platforms. The executable can be unzipped with standard zip tools to extract the packages (easy way to get precompiled librairies).

News

Motorized Scripts , Klaus Kröll, Linux Magazine, 2013-03

Description

A Tclkit is a single executable file that contains a Tcl interpreter and the startup scripts and support libraries needed to access a starkit bundled together with the Tclkit into a a starpack. A Tclkit can also be also be used as a tclsh workalike.

The original tclkit contained exactly Metakit or vlerq, zlib, tclVFS, incr Tcl, and optionally Tk. Various Tclkits are available and ready to use on various platforms, including many Unix, Windows, and MAC OS X systems. For example, TclKit Lite is a Tclkit that avoids Metakit and instead uses a library that avoids C++ and also removes incr Tcl. dqkit is yet another Tclkit.

Some Tclkits load Tk so that they are useful as either a tclsh or wish. On Windows this dual use is not possible, and there is a separate tclkitsh to run a command-line tclsh only system. On Macintosh (prior to MacOS X), there is only a GUI-based wish version.

Documentation

README (alternate )

A short introduction to Tclkits on the home page for the original Tclkit project.

Tclkit Documentation

Information about tclkits as well as pointers to other useful pages of information.

Building Tclkit

Tclkit solves problems

A magazine article that introduces uses of Tclkit, and especially its VFS capabilities, as a deployment solution.

Community

mailing list

For TclKit and StarKit issues.

Resources

equi4.com/pub/tk/tars

The source for kitgen and the various other pieces that go into a tclkit or tclkit-lite.

https://bitbucket.org/ihmin/tclkit

Prebuilt binaries for windows machine.

Tclkit Build Tools

KitCreator Web Interface , by Roy Keene

Configure your own Tclkit for different platforms, with several additional packages like Tcllib, tDOM, TLS, TclUDP, etc, wait for the KitCreator online service to build it, and finally download it. Seems to support newer (latest?) versions of tcl.

KitCreator

A build environment to create a tclkit-like executables.

KitCreator nightly builds

As of 2021-06-12, provides 8.5.19, 8.6.11, and fossil trunk builds for various platforms.

kitgen, by Pat Thoyts

A system for creating Tclkits.

TCL3D Kits

The TCL3D project has TCL8.6.0/1 starkits with some source modifications.

Tclkits (most up-to-date first)

TclKits , by Roy Keene

As of 2022-02-04, provides 8.5.17 through 8.6.12 for various platforms. Roy is active in the Tcl Chatroom, and usually happy to help troubleshoot TclKit issues.

KitCreator downloads by Roy Keene, using KitCreator

Provides nightly builds of Tclkits containing various versions of Tcl. As of 2022-02-14, the most recent manually-built kits are 8.6.12 (Windows 32, Windows 64,) 8.5.17 (Windows 32, Windows 64, Mac OS, RHEL5, Solaris). KitCreator supports cross-compiling Tclkits.

TWAPI Kits

The TWAPI project provides 8.5.17 and 8.6.3-8.6.12 windows Tclkits with and without twapi. They also support the sdx icon import functionality.

CustomKit

by Roy Keene. As of 2013-03-20, the latest builds are 8.5.11 (Solaris), 8.5.10 (Win32), and 8.5.9 (Mac OS X)

ActiveTcl basekit

ActiveTcl includes basekits with each distro release that mirror the core release of the dist. basekits are found in the bin directory

ODIE

Includes a so-far-not-very-user-friendly system for generating zip-based Tclkits.

cookit

Uses cookfs.

Tclkit download matrix

The original Tclkit. Provides 8.5.9 and older for various platforms.

Tclkit complete list

The original Tclkit. Longer listing of available kits providing 8.5.9 and and older for various platforms.

Tclkit aqua x86_64 builds for Mac OS X , by David Zolli

Currently provides versions 8.6.7 and 8.5.19.

Tclkit aqua x86_64 builds for Mac OS X , by David Zolli

Provides KitCreator builds of 8.6.7 and 8.5.19.

Tclkit Kitgen Build System

As of 2016-04-11, 0.4.9 provides 8.6.6 for various platforms

bleeding-edge builds , by Pat Thoyts

Look to the "files" section near the bottom of the page to find links to pages containing, as of 2013-03-20, 8.5.13 (Windows), 8.5.10 (Linux), 8.6b1.2 (Android), 8.5.7 (Solaris). 8.6.0 kits (Windows, Linux, Mac) built with Pat's version are available at that Tcl3D site .

Tclkit Lite

Like Tclkit, but with fewer extensions included.

Tclkit Mobile

A port of Tclkit + Tkcon to certain PDAs.

Tclkit-X11 (Mac OS X only)

Like Tclkit but with Tk/X11 in place of Tk/Aqua; part of the TclTkAquaBI distribution for Mac OS X.

TixTclKit (Windows only)

A different set of extensions including Tix and Windows-specific tools.

Dqkit

A much larger set of extensions, including BLT.

kbskit

A build environment for creating either tclkit-like or tclkit lite-like executables (slightly different, but intended to be similar).

tcltkaquabi

Tcl/Tk Aqua Batteris Included. Includes a single-file Wish program similar to a basekit

Tclkit Lite

A light-weight variant of Tclkit.

Wize - Wish Integrated Zip Executable

Like Tclkit, with a compiler and a lot of goodies.

The following table lists the package version numbers for the basekits above. The version numbers and availability come from the latest version available at the time of writing.

[anyone want to build a table that lists what extensions are in each basekit?]

Legend:

• varies - Indicates that the value varies depending on the version of some other package (usually the version of Tcl)
• same - Indicates that thet value is the same as the nearest filled in value leftwards
• (opt) - Indicates that this Tclkit is available with and without this package
• same as Tcl - Indicates that the value is the same value as the version of Tcl
• Win-only - Indicates this is only supplied when being built for Microsoft's Windows platform
• ??? - Indicates that this package looks like it should be available, but is not.

Check tclkit version

Ro: 2002-09-06: The old way to check the version of Tclkit

puts $tcl_platform(vfs)

The “new” way to check the version of Tclkit

puts $::vfs::tclkit_version

tclkit and kitten

Another concept to check out is Kitten, an example of packaging a group of add-on extensions into a scripted document for use by other documents.

Tclkit 8.4 Information

The following section refers only to 8.4 - 8.5 has an encoding dirs command and 8.5 TclKit binaries include a broader range of encodings, missing only the larger Asian encoding files.

Encodings

Tclkit 8.4 only has a few Unicode encodings built-in. There is an experimental "librarypath" command that can be used to change/extend the places where Tclkit looks for encoding files [...]]

2002-03-18: update: here's a transcript to illustrate the new behavior, based on a built-in Tclkit command called "librarypath":

$ tclkit
% librarypath
/home/jcw/bin/tclkit/lib/tcl8.4
% encoding names
iso8859-2 utf-8 cp1252 ascii macRoman identity unicode iso8859-1
% librarypath /home/tcl/lib/tcl8.4
% encoding names
cp860 cp861 cp862 cp863 cp864 cp865 cp866 gb12345 cp949 cp950 cp869
dingbats ksc5601 cp874 macCentEuro macUkraine jis0201 gb2312 euc-cn
euc-jp iso8859-10 macThai jis0208 iso2022-jp macIceland iso2022
iso8859-13 jis0212 iso8859-14 iso8859-15 cp737 big5 euc-kr macRomania
macTurkish gb1988 iso2022-kr macGreek cp437 ascii
macRoman iso8859-1 iso8859-2 iso8859-3 koi8-r iso8859-4 macCroatian
iso8859-5 cp1250 iso8859-6 macCyrillic cp1251 koi8-u iso8859-7
macDingbats cp1252 iso8859-8 cp1253 iso8859-9 cp1254 cp1255 cp850
cp1256 cp932 identity cp1257 cp852 macJapan cp1258 utf-8 shiftjis
cp855 cp936 symbol cp775 unicode cp857
%

What this means is that you get only a few encodings as part of the packaged tclkit, but to get more you can re-point it to another area containing an appropriate "encoding/" subdirectory, and it'll use those.

The reason a special command is needed to do this is documented in Tcl Bug 463190 , which is as yet not fixed.

Adding Encodings into TCLKit - if you want to add the full set of encodings into your TCLKit, see the code at [L1 ] (Mick O'Donnell Oct 2004)

VSU 2004-12-14: Unfortunately, the above solution (or the manual way described at the official site [L2 ]) does not work well for the encoding which should be set as the system encoding. E.g., even after adding all encoding files to tclkit, I still have:

$ echo $LANG
ru_RU.KOI8-R
$ tclkit
% encoding system
iso8859-1
%

instead of the proper value:

$ tclsh
% encoding system
koi8-r
%

Because of this, Russian text in Tk comes out as an unreadable sequence of iso8859-1 characters :(

PT: these kind of encoding issues should be solved since 8.5.6 and should also be ok in 8.4.19 I believe.

Matthias Hoffmann: Under MS Windows in Console Mode, you almost always need to have the encodings cp437 and/or cp850. So what does it matter to include just these two more in tclkit-win32-sh?

Tclkit Path Resolution

The way in that Tclkit resolves paths is not well documented. This note is an expansion on a communication from JCW to me (tomk) that helps explain the situation.

In the following discussion I have created a test.vfs directory that contains a bin and lib directory. I placed the BWidget package in the lib directory and moved the bwidget demo.tcl file from the bwidget/demo directory to bin/main.tcl in the test.vfs directory structure. The demo.tcl code normally sources other files from the local directory, which meant that when I move the code to the bin directory I had to modify the source path so that it was ../lib/bwidget/demo. This code worked fine during test, but when the code was converted to an SD it failed, which lead to the communication provided below.

<JCW wrote>

When working with an unpacked SD, you can test and debug by doing something like:

tclkit test.vfs/main.tcl

And to change to a new location in the tree, you can do:

cd test.vfs/lib/bwidget/demo

But when running in packed mode, the "test.vfs" *dir* gets replaced by the name of the SD, i.e. if you've called the SD "test.bin", then you're still running with a current working directory that is outside the SD, but the *file* is mounted and now looks like a dir, so you will have to do:

cd test.bin/lib/bwidget/demo

to get to the demo directory.

To get around this need to know how you're running things, you can do things like this in the bin/main.tcl script:

cd [file join [file dirname [file dirname [info script]]] lib bwidget demo]

Note that when the cwd is inside an SD, then things like exec work somewhat differently, because everything outside the Tcl world has no idea of VFS.

To see what I mean, try the following:

$ tclkit
% cd tclkit/lib/tcl8.4
% glob *
...
% ls
...
% pwd
...
% exec sh -c pwd
...

MHo: Perhaps this link will give a little help on the exec-problem: [L3 ]. The routine automates the process of copying an .exe out of the VFS to a temporary position and EXECing it from there.

PT 2003-05-01: The more recent versions of starkits can handle the applications location rather better. To illustrate let us create a micro starkit with hello.vfs/main.tcl containing:

package require starkit
set r [starkit::startup]
lappend r $::starkit::topdir [file dirname $::starkit::topdir]
puts $r

We can then create a starkit and starpack (sdx wrap hello.kit and sdx wrap hello.exe -runtime tclkitsh.exe) and try:

> tclkitsh hello.kit
starkit U:/lib/tcl/hello.kit U:/lib/tcl
> .\hello.exe
starpack U:/lib/tcl/hello.exe U:/lib/tcl
> tclkitsh hello.vfs\main.tcl
unwrapped U:/lib/tcl/hello.vfs U:/lib/tcl

So as you can see - [file dirname $::starkit::topdir] is always the same, no matter how it is run.

Tclkit Questions and Problems

What might cause a segfault on Linux (SuSE 8.0) when using the Img library with Tclkit? Just to be sure that loading the shared lib out of the starkit wasn't the problem, I have abstracted the problem to the following scenario: I've created a test folder with just libimg* in it, and one folder above that I have all the lib* files from the lib path of my Tcl installation. My test program is as follows:

load libimg1.2.so Img
image create photo -file foo.jpeg

When I run the code in tclsh (ActiveTcl 8.4), everything works fine; I can even put the image into a label and display it with pack. However, the exact same program crashes Tclkit (latest available as of 4 August 2002) with a seg fault. What am I doing wrong? Am I missing a shared library somewhere? unDees

Try using the version of Tclkit at http://www.equi4.com/pub/tk/newer/linux-i686.gz - there were a couple of problems with the July builds that may be causing the problem. Let me know how you go (via e-mail) and I can chase further - stevel

Thanks for the suggestion, Steve. First, I tried a later July build and at least got a JPEG to load without crashing. But packing the resulting label simply resulted in an empty window. So I tried the build from the "newer" directory as of today (August 5). Now I'm back to the original problem--the "image create" statement causes a segfault.

Can anyone replicate this error on Linux? I should add that the problem doesn't happen on Win32.

Thanks in advance... unDees

NEM: I just noticed a message in the Metakit mailing list archives about this problem. A possible work around might be to add some

catch {load blah/libjpeg.so}
catch {load blah/libpng.so}

lines before loading Img. This ensures that those libraries that are needed by image are present. (search the archive for more info)

emukang: I also met the problem when using Img package on ipaq linux pda, then I solved it by install another package, have a look of Install tcl on ipaq familiar linux PDA with Img package

When you visit the Tclkit home page (mentioned above), you will find that it was originally designed to be built using a series of tar files and a script called genkit. [That build mechanism has been replaced by a new script called kitgen.]

I am finding that on my personal platform, the g++ compiler requires me to add the directory where the g++ shared libraries reside to the LD_LIBRARY_PATH environment variable before creating the executable. This weird configuration fact (identified when attempting to run a C++ compiled app by the unable to locate libstdc++.so error message), results in the genkit steps failing. Add the appropriate directory/lib to your LD_LIBRARY_PATH variable, ensure it is exported, and try again.

AK: I can confirm this for the solaris boxes I have access to.

jcw: another gotcha I ran into on Solaris was the need to set CC in the env to "gcc"

Only one instance of Tclkit/Starkit??

CT: I am just starting to read up on kits as I plan on moving over to them exclusively with all my MetaKit database applications. One question that is burning is this: 'Is Tclkit setup in such a way to only run one instance of a particular starkit?' I ask this because some of my applications will suffer as a result of more than one process trying to update the same metakit views as metakit does not support concurrency yet.

LES 2004-01-07: Pray tell. I have so many times seen the Tcl community marvel and drool at the Starkit concept, but isn't TixTclKit [L4 ] a MUCH better way to run a tcl script (unless you have Tcl/Tk fully installed, of course), since it features a single executable and so many extensions, adding up to some sort of batteries-included single executable? Pray tell. Enlighten me, my kind lord.

CT: I believe that TixTclKit is a windows only build of the TclKit. Besides that, from what I can tell, Starkits are the actual application that you want to run in/with the TclKit, so TixTclKit would still need your application in the form of a Starkit in order to be useful unless you rebuilt the TixTclKit itself with your application embedded in it already. Not 100% sure if all my assumptions are correct but that's what I can gather anyway. Cheers.

LES: No, you can run TixTclKit.exe somescript.tcl. No starkits required.''

jcw: Tclkit includes very few extensions because it is aimed to be infra-structure (and be equivalent on two dozen or so platforms). A BI version is wonderful, but a separate topic IMO - if I had made Tclkit to include more extensions, I would have had to continuously track and maintain every build of them. The kitten approach is another way to do "BI", albeit as 2 files. FWIW, I very much like Detlef Groth's TixTclKit, and Windows really is a key platform to aim for, but they are not addressing the same issue. Note that tclkit vs. tixtclkit is not really a big deal: tixtclkit is tclkit with a very nice set of extra packages added to it (unwrap+re-wrap). Both are totally-effortless-to-deploy executables and both support starkits & starpacks - which is the key point of all this.

LES: Hmmm... "the key point of all this" says you. I would like to declare that the whole point of the starkits were never too clear to me. Sometimes I want to share one of my programs with someone, almost invariably someone who doesnt' know anything about Tcl and I say: "you can either download and install 12-Mb ActiveTcl or single-file 2-Mb TixTclKit to run my .tcl file". And guess what happens most frequently. And I feel confident telling people to use TixTclKit because I know it supports even more extensions than I am ever likely to use in all my lifetime's programs. It will run my script, you can be sure. So TixTclKit makes everyone's lives easier. If that's not what starkits are for, what is it then?

jcw: Your argument only applies to single scripts. For anything more substantial than that, starkits make my life a lot simpler. Note that TixTclKit + yourstarkit == Tclkit + yourstarkit-with-extensions. Two files either way. You seem to be arguing against ActiveTcl, not Tclkit.

Even with single scripts, I often use starkits to get extra compression. The following are equivalent:

tclkit blah.tcl

sdx qwrap blah.tcl
tclkit blah.kit

But hey - it's just a technology and it's OSS and it's optional. No one is forcing you to use tclkit or starkits :)

LES: I am not arguing against ActiveTcl. ActiveTcl has got most of the extensions. My only complaint is that it is a large download. I am arguing against Tclkit because it doesn't support the extensions, and you're also left with the extra work of building the starkit. It may not be that tough, but it's an additional step. With TixTclKit, my friends can run any of my bare-bones .tcl scripts without any extra tweaking, either on my or their side. Again: I don't see what big advantage there is in employing starkits instead of anything else. I know no one is forcing me to use them, but I sure would like to see what so many others claim to see...

LV LES, your argument works for you because you have chosen to only use extensions that exist within TixTclKit. Other people choose to only write apps which reside inside TclKit itself, or even within dqkit (another attempt at a Batteries Included single file. The bottom line is that the extensions that you need/use/find useful/find bearable and the ones that another developer finds useful may not always be the identical set. In that case, the TixTclKit developer then finds herself where the TclKit developer has been all along - determining how best to package the additional requirements so that the application can be shipped. To include every possible extension then results in a single file download that approaches the size of ActiveTcl - which most agree is too large for the average user to mess with.

So what's the solution? It's hard to say. In the case of specialized tclkits like TixTclKit, applications using them will only run on on platforms where the custom runtime tclkit has been built. In the case of the standard tclkit, the developer either makes use of a tool such as TDK, which has an interface for creating starkits with the developer specified extensions included, or they manually construct the pieces, develop/copy and debug the cross platform code loading code, etc.

MR: I don't know about you, but not too many of my programs consist of a single .tcl file, rather than lots of .tcl files, lots of image, help, and other associated data files, as well as not only fairly broadly used extensions (both Tcl and C) but also usually some C extensions pretty specific to my app. I can shove all that in one file and ship it to people.

LES: exactly 5 months later: I just read the discussion above and I am not happy with it because I didn't express myself well at all. Or maybe I didn't really know what I was talking about. Likely the latter. I finally see why starkits are so appreciated by the Tcl community. Though I still think that TixTclKit kicks some considerable ass. Now I just wish Tcl and starkits were as common and widespread as the Java runtime and .jar files.

CMcC: Since tclkit is a starkit, shouldn't one be able to take the standard tclkit and add the packages one wants using sdx? That would solve LES's problem by making it very easy to roll one's own tclkit, for a single file executable distribution.

Obviously a beginner's question: How can I run a ascii-only tcl script using tclkit (on Windows)? Currently when I try to do this, a window pops up instead of writing my output to the command prompt screen.

jcw: On Windows, use "tclkitsh.exe", which is a different download. Tclkit = wish, tclkitsh = tclsh

You can find this on the Equi4 site but I am not sure that it is a recent version.

Alternatively, add

catch {console show}

to your script which throws up a console behind the tk window.

MNO: Does anybody else see the following error when trying to load Tk in a tclkit on Solaris?

bash% ./tclkit-solaris-sparc
% package require Tk
X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Atom id in failed request:  0xed
  Serial number of failed request:  13
  Current serial number in output stream:  16

Other X programs work fine (e.g. xterm, xdpyinfo etc.). The X server is a recent Cygwin one, running under Windows 2000, if that makes a difference. ldd on the tclkit gives the following:-

bash% ldd tclkit-solaris-sparc
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /usr/platform/FJSV,GPUSC-M/lib/libc_psr.so.1

jcw 2005-03-05: See problems with some X applications, netbsd "currnet-users" mailing list, 2005-02-21 for a solution (it worked for me).

LV I use version

2004/02/02 12:54:25  11180-37925  tclkit

of tclkit on SPARC Solaris 8, and I do not see the behavior you describe.

MNO: Thanks, Larry - I'll take a look into my X server, it sounds like the problem may lie there.

It looks, from googling around a bit, that the problem is in the OpenSSH X forwarding. Interestingly, it seems to be intermittent - tclkit will repeatedly fail with the above error for a while, then suddenly, in the same session, it will start working.

How does a Tclkit compare in size to a file created using Python's freeze?

LV: you probably want to compare a starpack to the frozen program. A Tclkit isn't a stand-alone application, but instead a stand alone tcl interpreter. A starpack would be a tclkit and application, frozen into a single file.

RLH: I know that a Starpack is smaller than a Par/pp Perl/Tk application. I have the same application coded for Tcl/Tk and Perl/Tk and the Perl one is twice the size. VK ... and twice the speed: Comparing Tcl::Tk and perlTk WRT speed, perlmonks.org, 2005-01-28

LV: Just a note if you are encountering a message similar to this when attempting to execute a starkit:

extra characters after close-brace
   while executing
"return [uplevel 1 [list [namespace origin mcunknown]  $Locale $src {*}$args]]"

The problem is this - the code within the starkit requires a newer version of Tcl than your tclkit provides. This means that you should check the tclkit download matrix for an update, or in the worse case, have to build a new version yourself.

MG: I just read the license on the Tclkit website:

''The Tclkit-specific sources are license free, they just have a copyright. Hold the author(s) harmless and any lawful use is permitted.

This does not apply to any of the sources of the other major Open Source Software components used in Tclkit, which each have very liberal BSD/MIT-like licenses:

IncrTcl, Metakit, Tcl/Tk, TclVFS, Zlib ''

I hadn't realised they were all included as separate things - I'm assuming that if you wrap to a .exe then unwrap, you can remove some and rewrap (with IncrTcl, anyway). Are all of the others required, if you aren't specifically 'package require'ing them?

LV: First - if your concern is reducing the size of the tclkit portion of the exe, look to the tclkit-lite, which is an attempt to reduce things to a signifcantly smaller footprint. Secondly, in the original tclkit, certainly tcl is required, metakit, tclvfs, and I believe zlib. Tk isn't required if your application doesn't specifically require it, nor is incr tcl.

LV: Just this week I went to the site listed at the top of this page to download a tclkit for Linux. I took that version and tried it out on the Ubuntu system at home. Alas, tclkit failed, claiming it could not locate the appropriate g++ library.

I was, however, able to get the starkit in which I was interested to run using the ActiveTcl 8.5.7 tclsh8.5 executable, so if someone else runs across the same issue, they might try that approach.

garden 2011-07-23 06:51:29: It can't be simpler... but it simply does not work! Ubuntu 11.4, from a terminal, in the folder where tclkit858 is located. $ ./tclkit858 myapp.tcl $ That is: nothing happens It works perfectly on Ubuntu10.4

MHo 2012-10-31: All Tclkits I can find are relatively outdated. Unfortunally, I'm not able to produce binaries by myself.

RZ: You could try one from http://sourceforge.net/projects/kbskit/files/kbs/0.4.3/

MHo: Thanks, I'll try. Three comments:

• The executable are somewhat big. Are they UPX'd?

RZ: no

• Are the Windows .EXEs 32bit oder 64bit?

RZ: compiled under msys/mingw on 64bit Windows7

• In WindowsNT_kbsmk8.5-cli.exe, e.g., I see a dependency on
• c:\programme\mingw\bin\libstdc++-6.dll - does this mean I have to have
• this DLL to run the Kit?

RZ: I'm no expert under windows, but you could try the *kbsvq* versions. *kbsmk* versions use metakit as internal database and require C++ compiling. *kbsvq* use vlerq as internal database and only need a C compiler.

MHo:

• Since I could execute under Win XP 32 bit: the windows versions are 32bit EXEs.

AMG: Watch out, libstdc++-6.dll isn't the only dependency. I grabbed this file from MinGW [L5 ] and put it in the same directory as the *mk* executable, only to find that it also wants libgcc_s_dw2-1.dll, which can be found here --> [L6 ]. Thankfully, these are the only two DLLs I needed in order to get it to work. Oh, you'll need something that groks lzma, e.g 7zip [L7 ].

MHo: If this is the case, these kits are ineligible for me since it negates one of the biggest advantage of tclkits, the "no-install-approach". I just took a quick look at active state's basekits, they only rely on standard windows dlls.

AMG: I know, it's irritating, but at least you can put the DLLs in the same directory as the EXE and it'll work. Or just use the Vlerq (*vq*) version. I don't know why the Metakit version (*mk*) wasn't statically linked to the C++ libraries.

MG: What's the best way to obtain an ActiveTcl basekit? I'm currently building Starpacks using Tclkits from the Google Code site, but the versions aren't that recent. However, the ActiveState downloads seem to all be for installers for different platforms, and I'm trying to build Starpacks for multiple platforms from a Windows machine, so they're not really useful for me.

stevel: Download ActiveTcl on each platform you are interested in and collect the basekit for each. You can generate starpacks for any supported platform, on any supported platform. If you don't have access to a particular platform consider using the KitCreator nightly builds.

HaO 2014-01-10: (Temporary posting, please delete if obsolete) I personally enjoy the 'classic' upx-packed kits. Links are currently also on kitgen.

AMG: What are my options for obtaining or building an 8.6.6 (or newer) Tclkit for Windows 2000? Pat Thoyts's most recent offering does not work on Windows 2000. It immediately exits with no error information given. I should note that I do not require Tk and in fact prefer that it not be statically linked into the Tclkit.

Update: KitCreator (linked above) from Roy Keene works on Windows 2000. Huzzah! Now if only I didn't have to use Windows 2000...