SDX under Windows

Basic Usage

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, let's 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. If we had some libraries we would create a hello.vfs\lib directory and place the library directories under that path. In this sample the application file is in the top level, but we could have created a hello.vfs\bin directory to keep things tidy for a larger application. The main.tcl file contains a little boilerplate that properly initializes the starkit runtime.

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).

Modifying executable resources

sdx has some support for modifying the executable resources for a starpack. You can change the icon resource by placing a file called tclkit.ico in the top directory of the vfs tree. See [enter a wiki web page name here] for the details of the icon format. You can also modify the version resources by including a tclkit.inf file in the top directory. For instance, the tkchat application uses a tclkit.inf containing the following:

  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"

Code signing

For some time Windows has supported certificate signatures attached to executable files. Since the release of Windows Vista this has started to become more important. On this version of Windows if an executable located on a remote drive is run, the user will be presented with a warning dialog. If the application has been signed by a valid certificate then a 'friendly' dialog appears where the default action is to run the application. If the file is unsigned then a less friendly dialog appears and the default action is not to run the application. The normal tclkit executable does not support authenticode signatures. Such signatures are attached to the end of the binary file and tclkit expects to find the virtual filesystem at that location. However, the vlerq-based tclkit executables (tclkit-gui and tclkit-cli) can support such signatures. These versions of tclkit use a different library to read the Metakit database containing the virtual filesystem and this is able to account for the appended signature.

PO 2022-12-13

Modern tclkits like the one contained in the BAWT distribution are able to store certificates at the end of the file.

The following is a short description of my experiences generating a code signing certificate and attaching it to a Starpack.

1. Create a self-signed certificate for code signing

If you do not have a valid certificate, you can generate one for testing as follows.

Open a PowerShell window and check your execution policy:

  > Get-ExecutionPolicy

If the output is Undefined, set the policy to RemoteSigned:

  > Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

Now you are able to create a self-signed certificate by issuing the following command:

  > New-SelfSignedCertificate -Subject "[email protected],CN=poSoft.de" -Type CodeSigning -CertStoreLocation Cert:\CurrentUser\My

Check, if the certificate is in the personal certification store:

  > certmgr.msc

Export the certificate into a file (ex. poSoft.cer): Note: The following command assumes, that the certificate created in the previous step is the first one (Index 0).

  > Export-Certificate -Cert (Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert)[0] -FilePath poSoft.cer

More information regarding self-signing can be found ex. here: http://woshub.com/how-to-create-self-signed-certificate-with-powershell/

2. Sign the starpack executable

You can sign your executable (ex. poApps.exe) using either the signtool from VisualStudio or the Set-AuthenticodeSignature cmdlet. Note: You are able to sign a bunch of executables by using *.exe instead of the file name.

I used signtool, so it can be called from a batch script using the VisualStudio command shell, as is done in the BAWT framework.

  > signtool sign /v /fd SHA256 /f poSoft.cer /t http://timestamp.comodoca.com/authenticode poApps.exe

That's it. Using the property dialog of poApps.exe, it now shows the digital signature.

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 "<path>tclkitsh <path>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

EasySDX

Zipguy 2013/12/31 - You can find out my email address by clicking on Zipguy.

You might also like to look at ezsdx - a small frontend for sdx which offers a few interesting features.:). It is Windows only, and is at v0.98b (and up). It does try to prevent people, who may be ignorant, from doing stupid things. It can:

• Run xxx.tcl programs
• QWrap/Unwrap xxx.tcl programs (which does give you a xxx.kit file)
• Makes it easy to re-generate your xxx.kit file (after editting and saving)
• Can even make xxx.exe

Also, it has extensive screenshots, to explain how to go all the way, from a xxx.tcl, to a xxx.kit, to an xxx.exe.

LV 2007 July 11

Here's what I see as I am attempting to survive my first dealings with starkits 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.