Tcl/Tk on Windows Frequently-Asked Questions

18-Mar-96

This list of frequently-asked questions, also called a FAQ, covers problems with Tcl/Tk on the Windows platform. Please send any additions or corrections to Eric Johnson (the address is at the bottom). This FAQ is located on the Internet at the following (unfortunately very slow) URL:

http://ourworld.compuserve.com:80/homepages/efjohnson/tclwin.htm

Questions answered here include:

How to get Tcl/Tk For Windows
A-1: Binary release of Tcl/Tk.
A-2: Windows 3.1 Requires Win32s
Installing/Can't Run At All
I-1: Don't upgrade over a previous version
I-2: Wish generates a UAE error at startup
I-3: Increasing environment space in DOS.
Differences From Unix
D-1: \ Won't Work!
D-2: How to create a valid font name on Windows.
D-3: How to build loadable extensions on Windows
Windows-Specific Bugs and Problems
B-1: Wish uses a lot of system resources and doesn't free them.
B-2: Once exec fails, the next exec generates a fatal error.
B-3: Puts bugs.
B-4: fileevent only supports sockets under Windows
Compiling
C-1: Getting the source code
C-2: Tcl uses long file names
C-3: Tcl was compiled with Borland C++
Compiling with Microsoft Visual C++
M-1: Where is the makefile for Microsoft Visual C++?
M-2: How to fix the makefile for Microsoft Visual C++
M-3: Can I use the Binary Release .DLL with my compiled applications?
M-4: How to compile with Microsoft Visual C++
Expect
E-1: Expect isn't ported to Windows


How to get Tcl/Tk For Windows

A-1: Binary release of Tcl/Tk for Windows

A binary release of both tclsh and wish exist for Windows. You can get them from ftp.smli.com, in the /pub/tcl directory. The win41b3.exe file is a self-extracting archive and contains the wish executable. The URL is:

ftp://ftp.smli.com/pub/tcl/win41b3.exe

A-2: Windows 3.1

If you run Windows 3.1, you will need to install the Win32s subsystem. You may have already done that. Check that you have the Win32s DLL (dynamic-link library) at version 1.25. If not, you can get a self-extracting archive, W32S125.EXE, from the same FTP location. If you use Windows NT or 95, you won't need the Win32s subsystem.

-Eric Johnson




Installing/Can't Run At All

I-1: Don't upgrade over a previous version

It seems there is a bug in the Windows binary installer. If you are installing over the top of a prior version of Tcl, it is not correctly handling the versioning for the libraries. You will end up with a mixture of old and new files. The symptoms vary, but if you are seeing problems with the console or other stdio related features, the installer could very well be the culprit.

The solution is to completely remove the old/broken installation and reinstall from the release file. This should give you a consistent set of files.

Thanks to Gerald Lester for helping to identify this problem.

-Scott Stanton

I-2: Wish generates a UAE error (Unhandled Win32s Exception) at startup.

If you get a UAE error when starting wish on Windows 3.1 (this problem does not appear on Windows NT), here's what you can do.

1. Add the following lines to your autoexec.bat file:

set tcl_library=/tcl/lib/tcl7.5
set tk_library=/tcl/lib/tk4.1

Note that these paths refer to the standard installation of wish, e.g., C:\tcl. If you installed in a non-standard location, you'll need to modify this. Also note the forward (/), not backward (\) slashes for directory separators.

2. You can also type in the values at a shell (i.e., DOS) command line, but wish is a Windows program, so this must be placed into the environment for Windows. When I typed these commands in at the DOS level, I received an error that I had run out of environment space. This may also be a problem for you. DOS 5 only allows a small amount of space for environment variables. If this is the case, you'll need to remove other environment settings (I pared down my PATH, which came from the manufacturer with extraneous options).

3. You must reboot, since the autoexec.bat is only read at start-up.

-Eric Johnson

I-3: Increasing environment space in DOS.

If you type in the tcl_library and tk_library environment variables and get an out of space error, you can increase the amount of memory allocated to the DOS environment through the COMMAND.COM command line options. For example, add the following line to your CONFIG.SYS file:

shell=C:\COMMAND.COM /e:1024 /c autoexec

This sets the environment space to 1K. Note that (on my system, at least) the /c autoexec command is needed to make DOS run the autoexec.bat file during booting.

-Alex Hubbard


Differences From Unix

D-1: \ Won't Work!

Remember that \ is a special character in Tcl.

This is a problem because Windows uses a backslash for separating directories, while Unix uses a forward slash.

So, in Tcl and in the Tcl shell, wish, you need to enter directories and paths with either two backslashes, e.g., \\, or with the Unix-style forward slash, e.g., /.

For example, don't use:

$dir\$filename

Use either:

$dir\\$filename

or:

$dir/$filename

D-2: How to create a valid font name on Windows.

You can either use X Window font names, in X Logical Font Description (XLFD) format, or a special Windows-specific format.

1. XLFD format font names

Windows Tk will accept X font names, but you must supply all the parts (you can use a * for a wild-card, though, see below). You can also use a number of XLFD elements, such as "bold", etc. to control the fonts.

For example, the following all are valid font names on Tk in Windows:

button .b1 -text "Arial" \
    -font "-*-arial-bold-r-normal--*-*-*-*-*-*"
button .b2 -text "Courier" \
    -font "-*-courier-medium-r-normal--*-*-*-*-*-*"
button .b3 -text "Symbol" \
    -font "-*-Symbol-medium-i-normal--*-240-*-*-*-*"
pack .b1 .b2 .b3

To get the list of valid Windows font names, look in an application like Microsoft Word (or WordPad, which comes with Windows 95) and check the font list. Most True Type ("TT") fonts should be scalable to a number of sizes.

-Eric Johnson

2. Windows-specific font names

In addition to the X style font names, Tk 4.1 accepts a special tuple format consisting of a 3 element list of the form:

	{name size stylelist}

You can use any font name that Windows understands for the first element. The size is in points, and the style is a list of zero or more items from the set of supported styles: normal, bold, medium, heavy, thin, extralight, light, semibold, extrabold, italic, oblique, underline, strikeout. Many of these styles won't do anything for a given font. For example, to get a 20 point TrueType Times Roman font with bold and italic style, you would say "{Times Roman New} 20 {bold italic}".

Note that the 3 part font specifier is just a place holder for font objects. Eventually we will support font objects that take various configuration options and return a handle that can be used anywhere a font string is used now.

-Scott Stanton

D-3: How to build loadable extensions on Windows

Building loadable Windows extensions for Tcl still requires a DllEntryPoint routine (for Win32s 32-bit extensions). This routine is called when LoadLibrary is invoked to load the extension, and must return TRUE (after any specific initialization it does) to succeed for the initial load. See the LoadLibrary and DllEntryPoint functions in the Win32 manual for full details.

In hello.c, the sample extension, I was satisfied with adding the following code near to the top of the file:


#ifdef _RTLDLL
#include 
BOOL _export WINAPI DllEntryPoint (HINSTANCE hInstance, DWORD seginfo,
LPVOID lpCmdLine)
{
  /* Don't do anything, so just return true */
  return TRUE;
}
#endif

Since the makefile defines _RTLDLL, and that is associated with DLLs, this seems a reasonable thing to do. The extension appears to load properly with this change.

-Michael Schwartz

Michael Schwartz also has an extension for Windows 3.11 users, which provides for some windows-specific behavior.

The extension (so far) will asynchronously exec another windows application. I have tried to adhere to package constructs as well, so if you have done the pkg_mkIndex thing, then you should be able to do the package require tkmswin and get this automatically loaded. The 2nd argument seems to be off a byte (tkmswin exec notepad xyz.dat will try to start notepad with file yz.dat), but I don't think this problem is in the extension code.

This command is quite crude--no thought is given to piping stdout or stderr, no attributes are parsed from command line switches, no new environment, no new starting directory, and the command itself is jammed in with a strcmp. Certainly nothing elegant. But, at least it works, and may be a place to build from.

Use:

I called the extension Tkmswin, to allow for incorporation of other windows-specific features later.

-Michael Schwartz


Windows-Specific Bugs and Problems

B-1: Wish uses a lot of system resources and doesn't free them.

Wish does not release the system resources it uses even when it exits normally. Run through the widget demo, exit and look at the system resources count. You may find it dropped by 17%. During the widget demo, monitoring system resources found that wish does not seem to release system resources when it destroys widgets. During a wish session free resources just keep declining. Given this situation, large wish applications may slow down or crash.

-Charles A. Shartsis

B-2: Once exec fails, the next exec generates a fatal error.

Tcl7.5a1/Tk4.1a1 bugs with exec on Windows.

Once an exec command fails the next exec command results in a fatal error (when typing exec commands into the Console window). For example:

tcl> exec xyzzy
Couldn't read output file "TMP37.$$$" for command: no such file or directory
tcl> exec dir

and you will get a popup window about the fatal error...

Other exec bugs on Windows:

I'm using the recent b2 release with Windows 95 with tclsh75.

Exec is not redirecting output properly. There seems to be a race condition.

When I try 'exec co -p foo.c > bar.c', co should write to stdout and tclsh75 should redirect the output to a new file.

Instead, co -p writes to stdout and it appears on the console window. If I attempt to grab the output by doing:

        set result [exec co -p foo.c > bar.c ]

result is set to "" after the command, even though co writes out the file to stdout.

Now it gets interesting: If I trace through Win32Pipeline() and stop at the CreateProcess() call, and then step through it closing the files, the whole thing works the way it should - that is, co writes to stdout, which goes into a file. If after it stops at CreateProcess() I hit the continue, everything breaks again. So it seems that tclsh needs to create the rpocess and close down the files before letting the child run. Very odd.

-Josh Putnam

- When you exec a command the screen blanks out (system -> DOS?) and then redraws as the command ends. Can this be stopped?

- There is a resource leak somewhere in the exec command. If you do "exec dir" several times you will find that the Free Memory and Free System Resources (as in Program manager/Help/About) decrease each time.

-Gordon Lack

The beta 1 release should fix the exec bug in Windows '95.

-Scott Stanton

Calling exec brings on blank-screen mode

In article <9603091208.AA08832@diana1.paisley.ac.uk>, Shicheng Tian wrote:

On my PC, from Windows, I run a tcl script file with the following one line code:

exec del "c:/rubish.tcl"

The file 'rubish.tcl' DOES get deleted, but the trouble is:

the PC goes back to the DOS environment (i.e. a black screen!), then it comes back to Windows again.

My enquiry is: is it possible to run the 'exec' command shown as above WITHOUT showing the DOS black screen?

You can change this behavior by modifying the .PIF file for MS-DOS so that it does not use full-screen mode.

-Scott Stanton

Another way to call exec

It wasn't obvious to me either how to get native DOS window commands to work and it sometimes hung on me as well. I recently got it working, however...

exec cmd.exe >&@stdout <@stdin /c dir

will do the directory command for the current directory. Check out the Windows help for the switches available under cmd.exe. "/c" tells it to execute the command and then exit. "/k" tells it to execute the command and keep the DOS command interpreter active. (Note that cmd.exe is the name of the MS-DOS interpreter on Windows NT.)

-Robert Philpott

B-3: Puts bugs

The following Tcl procedure may fail on Windows NT, depending on the amount of data written to the file:

proc testPuts { fileName output times } {
  set fileID [ open $fileName w ]
  for { set i 0 } { $i < $times } { incr i } {
    puts $fileID $output
  }
  close $fileID
}

When it fails, there are only a couple of characters in the output file (basically garbage). The Tcl error reports back:

error writing "fileX": No error

For example, if I call:

 testPuts {C:/TestFile} {HI THERE} 455

it works perfectly well. However, if I call:

 testPuts {C:/TestFile} {HI THERE} 456

it fails.

You can work around this bug by flushing the file descriptor after each puts call, like the following:

proc testPuts { fileName output times } {
  set fileID [ open $fileName w ]
  for { set i 0 } { $i < $times } { incr i } {
    puts $fileID $output
    flush $fileID
  }
  close $fileID
}
The big question is whether this is a bug in Tcl or Windows NT 3.51. Has anyone seen this before or have any related information? If it is a bug in Windows NT, will Tcl7.5b2 handle this?

-Brian L. Rubow

B-4: fileevent only supports sockets under Windows

File handlers do not correctly support disk files under Windows. They are really only useful on sockets right now.

-Scott Stanton


Compiling

C-1: Getting the source code

The Tcl7.5b3 and Tk4.1b3 releases now officially support Unix, Windows and Macintosh platforms. The source code comes with a win/ directory with Windows code. You can get the source code release on the Internet via FTP from ftp.smli.com, in the directory /pub/tcl. While these are still beta releases, I've found them quite stable.

For Windows users, you'll likely want the source code compressed in ZIP format, rather than GNU gzip. Pick up the files tcl75b3.zip and tk41b3.zip.

-Eric Johnson

C-2: Tcl uses long file names

Both Tcl and Tk use long file names. You'll need Windows 95 or Windows NT (with an NTFS file system) for the sources.

You may also need a modern ZIP program to extract the archive and maintain its long file names. Older versions of pkzip, for example, only understand the old DOS eight character (with up to three characters for an extension) file names. I use WinZip, a shareware archiver program for Windows.

-Eric Johnson

C-3: Tcl was compiled with Borland C++

The team at Sun that creates Tcl uses the Borland C++ compiler. This means that if you do want to compile your own C functions and add them to Tcl, or extend Tcl with any dynamic link libraries (or DLLs), you'll need to either use the Borland compiler or recompile Tcl and Tk with your compiler of choice.

-Eric Johnson


Compiling with Microsoft Visual C++?

M-1: Where is the makefile for Microsoft Visual C++?

Older versions, Tcl7.5a1 and Tk4.1a1, come with project/make files only for Borland's C++ compiler. Tcl7.5b3 and Tk4.1.b3 include Microsoft Visual C++ project/make files as well. You should update to this release. If you haven't upgraded yet (you should, though), you can get the makefiles over the Internet at:

ftp://ftp.smli.com/pub/tcl/

An alternate location is via FTP from mm-ftp.cs.berkeley.edu in the /pub/winnt/sun_tcltk/. directory.

-Gordon Chaffee

M-2: How to fix the makefile for Microsoft Visual C++

With Microsoft Visual C++, you need to have both a 32-bit compiler (e.g., MSVC++ 2.2 or 4.0) and a 16-bit compiler (e.g., MSVC++ 1.5). You may then have to edit the makefiles to point to the proper directories.

The default uses something like the following:

MSVC++ 4.0
C:\MSDEV
MSVC++ 1.52
C:\MSVC

-Eric Johnson

If you're getting a problem with compiling the resources for Tcl, the following may help.

The problem is that we're letting nmake define RC and CC rather than explicitly define them yourself. CC runs as cl.exe without an explicit path, so depending on your $PATH setup, it might run the wrong compiler version. I changed my makefile to use TOOLS32, rc32 and cc32, explicitly defined off of TOOLS32, and it worked fine.

The changes made are:

Added:

cc32 = $(TOOLS32)\bin\cl -I$(TOOLS32)\include
rc32 = $(TOOLS32)\bin\rc

Changed:

TOOLS32   = c:\msdev

-John Buckman

M-3: Can I use the Binary Release .DLL with my compiled applications?

The binary release is compiled for Borland C++ extensions only. If you want to use other compilers, you'll need to get the source release from the ftp site and build it with your own compiler.

-Scott Stanton

M-4: How to compile with Microsoft Visual C++

To compile Tcl with Microsoft Visual C++, I followed these steps:

-Eric Johnson


Expect

E-1: Expect isn't ported to Windows

Expect has not yet been ported to Windows. Don Libes, creator of Expect, plans a Windows NT port with a target for Summer 1996.


Thanks To:

John Buckman
Gordon Chaffee
Alex Hubbard
Gordon Lack
Don Libes
Robert Philpott
Josh Putnam
Brian L. Rubow
Michael Schwartz
Charles A. Shartsis
Scott Stanton
Larry Virden

Compiled by Eric Johnson. Please send updates to johnsone@camax.com.

DISCLAIMER. This article is provided as is without any express or implied warranties. While every effort has been taken to ensure the accuracy of the information contained in this article, the maintainer assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.


Mt. Fuji Home | Linux | Tcl Overview | X/Motif | Japanese | Suggestions?