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:
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
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
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 #includeBOOL _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
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
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...
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:
When it fails, there are only a couple of characters in the output file
(basically garbage). The Tcl error reports back:
For example, if I call:
it works perfectly well. However, if I call:
it fails.
You can work around this bug by flushing the file descriptor after each
-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
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
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:
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:
-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
The changes made are:
Added:
Changed:
-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
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
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.
exec cmd.exe >&@stdout <@stdin /c dir
proc testPuts { fileName output times } {
set fileID [ open $fileName w ]
for { set i 0 } { $i < $times } { incr i } {
puts $fileID $output
}
close $fileID
}
error writing "fileX": No error
testPuts {C:/TestFile} {HI THERE} 455
testPuts {C:/TestFile} {HI THERE} 456
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?
Compiling
C-1: Getting the source code
Compiling with Microsoft Visual C++?
M-1: Where is the makefile for Microsoft Visual C++?
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.
cc32 = $(TOOLS32)\bin\cl -I$(TOOLS32)\include
rc32 = $(TOOLS32)\bin\rc
TOOLS32 = c:\msdev
makefile.vc
to makefile
. Do this in both directories.
makefile
the same way you did the Tcl directory makefile
. This
will create a new project for the Tk sources.
Expect
Gordon Chaffee
Alex Hubbard
Gordon Lack
Don Libes
Robert Philpott
Josh Putnam
Brian L. Rubow
Michael Schwartz
Charles A. Shartsis
Scott Stanton
Larry Virden
Home
|
Linux
|
Tcl Overview
|
X/Motif
|
Japanese
|
Suggestions?