Subject: Tcl/Tk on Windows Frequently-Asked Questions
Date: 23 Mar 1996 01:54:40 GMT
X-Last-Updated: 1996/03/22

Posting-Frequency: monthly


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 <windows.h>
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 (mschwartz@mmc.com) 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:
    load tkmswin.dll (alternative to the package require command)
    tkmswin exec filename.exe [command line arguments]

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&gt; exec xyzzy
Couldn't read output file "TMP37.$$$" for command: no such file or directory
tcl&gt; 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 -&gt; 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  <tian_ci0@paisley.ac.uk> 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

changed all instances of RC to rc32, CC to cc32 and TOOLS to TOOLS32

changed resource compiler to use -r flag.

-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:

You must have installed both MSVC++ 1.5 (16-bit compiler)
and MSVC++ 2.2 or higher (32-bit compiler). I used 4.0 on Windows 95.

Fix the makefiles as described above, if necessary.

Go to the Tcl and Tk source directories. Copy makefile.vc
to makefile. Do this in both directories.

In the Developer Studio, open the makefile in the Tcl source directory. 
You'll need to select all files (*.*) and then set the file type to 
Makefile. This will create a new "project" with an executable name of 
"makefile1.exe". Change this to tclsh.exe.

Now, select Rebuild All in the Build menu to compile the
library and tclsh.exe.

When completed, go to the Tk directory and open its makefile
the same way you did the Tcl directory makefile. This
will create a new project for the Tk sources.

This time, rename the executable from "makefile1.exe" to wish.exe.

Rebuild all again to compile Tk and wish.exe.
When you're done, you'll need to copy tclsh.exe, wish.exe and all
.DLL files from both the Tcl and Tk directories into your target directory.
The .DLL files are the new dynamic link libraries you created with
Microsoft's, instead of Borland's, C++ compiler.

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

-- 
Eric F. Johnson     URL: http://ourworld.compuserve.com:80/homepages/efjohnson/
CAMAX Manufacturing Tech., Inc.
7851 Metro Parkway           phone: +1 612 854 5300     fax: +1 612 854 6644
Minneapolis, MN 55425 USA    email: johnsone@camax.com

