On Windows [tclkit] is provided as two executables. One (tclkit) is a GUI mode program and the other (tclkitsh) is a console mode program. To build starkits yourself you should fetch both executables along with the sdx.kit starpack. sdx should be run using the console mode executable. A simple way to handle this is to create a simple batch file to handle this, for instance sdx.bat can be just: @tclkitsh c:\path\to\sdx.kit %1 %2 %3 %4 %5 %6 %7 %8 %9 To illustrate the usage, lets create a trivial "Hello, World" program: mkdir hello.vfs echo package require Tk > hello.vfs\hello.tcl echo tk_messageBox -message "Hello, World" >> hello.vfs\hello.tcl echo exit >> hello.vfs\hello.tcl echo package require starkit > hello.vfs\main.tcl echo if {[starkit::startup] ne "sourced"} { source [file join $starkit::topdir hello.tcl] } >> hello.vfs\main.tcl This gives us a vfs directory with two files. The application file and the starkit intialization script. We can test the application in place very simply: tclkit hello.vfs\main.tcl and we can wrap it into a platform-independent starkit: sdx wrap hello.kit tclkit hello.kit or create a standalone executable, a [starpack]: sdx wrap hello.exe -runtime c:\path\to\tclkit.exe hello.exe If your application is to be a console mode application then use tclkitsh instead of tclkit as the executable and be aware that you cannot pass the same executable as the argument for -runtime as you are running. You need to make a copy and pass that (a restriction caused by the way Windows locks running executable files). ---- December 20, 2002 If you use Windows \ notation for a filename, SDX fails. If you try to add registered methods to the .KIT filetype (wrap, unwrap etc) then when you right-click on the filename and choose the method, SDX fails. This appears to be fixed for the *first* filename but not for the second. That is, tclkitsh can find sdx.kit, but tclkitsh with SDX can't find your file. It creates an empty correctly-named .vfs folder and aborts. When I massaged the filename the problem went away: file unwrap.tcl set aa [lindex $argv 0] set aa [string map {\\ /} $aa] exec tclkitsh.exe sdx.kit unwrap $aa I registered this as "tclkitsh unwrap.tcl %1" and it worked for me on Windows XP and Windows 98. It might be possible to fix this inside SDX assuming that you'll never need a unix backslash character in a filename. I'm not sure that's a good idea. Jonah Thomas ---- ZipGuy 06-06-2003 - I have created a Starkit to solve this problem on Windows. It's called [Windows SDX Shell Fix] and it front-ends sdx.kit. ---- [LV] 2007 July 11 Here's what I see as I am attempting to survive my first dealings with [starkit]s under [Windows] (shudder). No questions yet ... just wanted other first timers to see what to expect. Hopefully the experts will wander by and add useful tips for us here. I have a tclkit.exe, a starkit (tls.kit), and sdx.kit. I open a cmd.exe window and I type: sdx.kit lsk tls.kit Initially, I get a dialog from windows saying it doesn't know how to deal with a .kit file. I point it to the tclkit.exe. I then type the command again. This time, I get a tkcon console, as well as a widget that is titled "sdx" with a label of "Command line:". I type "help", and the sdx help output appears in the console. But the command line dialog is gone. Okay, that's how things work on Unix... So, I quit the tkcon, and type the command again. I see that the arguments are doing me no good in cmd.exe, so I type just the arguments into the sdx command line window. That seems to work. ---- AsifH 26-07-2007 I got the latest http://www.equi4.com/pub/tk/8.5a6/tclkitsh-win32.upx.exe (WinXP) and http://www.equi4.com/pub/sk/sdx.kit I created a simple '''helloWorld.tcl''' file containing: puts "Hello World!" I generated a '''helloWorld.kit''' by executing: tclkitsh-win32.upx.exe sdx.kit qwrap helloWorld.tcl I built the vfs directory '''helloWorld.vfs''': tclkitsh-win32.upx.exe sdx.kit unwrap helloWorld.kit I built '''helloWorld.exe''' by executing: tclkitsh-win32.upx.exe sdx.kit wrap helloWorld.exe -runtime tclkitsh-win32.upx.exe When I execute '''helloWorld.exe''', I get: ./helloWorld.exe: ./helloWorld.exe: cannot execute binary file So I: cp tclkitsh-win32.upx.exe tclkitsh-win32-runtime.upx.exe then I build '''helloWorld.exe''' once again: tclkitsh-win32.upx.exe sdx.kit wrap helloWorld.exe -runtime tclkitsh-win32-runtime.upx.exe Now I execute '''helloWorld.exe''' and I get the expected result: Hello World! Why do I need to copy '''tclkitsh-win32.upx.exe''' to a different filename (for example) '''tclkitsh-win32-runtime.upx.exe''' in order for this to work? [LV] One of the documented restrictions for sdx is that you must provide a physically seperate file as -runtime argument from the file involved in running the sdx. I read somewhere it had to do with OS limitations in using files that were being executed. I never saw an extended explanation, but certainly you have provided an example of the problem. ---- See [http://groups.google.com/group/starkit/browse_thread/thread/c3a302890d437848/a46232780bde6c40#a46232780bde6c40] for a thread from March 2008 on the [starkit] mailing, discussing changing the Windows icon and other resources in a starpack. list about ---- During October, 2008, [PT] answers a [comp.lang.tcl] poster's question about how to set a [starpack]'s file description, etc. He says: === You can create a [tclkit].inf file in the root of your [vfs] tree and the [sdx] utility will read this and modify the string version resources. For instance, [tkchat] uses: CompanyName "Pat Thoyts" LegalCopyright "Copyright (c) 2001-2008 Bruce Hartweg et al." FileDescription "Jabber multi-user chat client" ProductName "tkchat" ProductVersion "2.0.0.0" === ---- !!!!!! %| [Category Tclkit] |% !!!!!!