Archive-name: tcl-faq/tk/windows
Posting-Frequency: monthly
Last-modified: 1996/09/27
   
   Tcl/Tk on Windows Frequently-Asked Questions

   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/homepages/efjohnson/tclwin.htm
   
   There is also a Tcl on Windows mailing list. For more information, and
   an archive of messages, see the following URL:
   
   http://www.smli.com/tcl/lists/wintcl-list.html
   
   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
          D-4: How to Run Scripts from Windows
          D-5: Cut, copy and paste in the Tcl Console window
          D-6: Using the Windows Clipboard
          D-7: send is not implemented on Windows
          D-8: Start-up Files tclsh.rc and wishrc.tcl
          
   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
          B-5: winfo interps and send fails on Windows
          B-6: You need at least 256 colors
          B-7: Windows 3 doesn't support help contents file
          B-8: Problems with clock command on Windows
          B-9: wm iconbitmap doesn't work on Windows
          B-10: If you use a pipe (|) in open, until the child process
          has terminated no events will be processed.
          B-11: The rightmost mouse button is Button-3.
          
   Windows 3.1 Issues 
          W3-1: How to execute tclsh75.exe from Windows 3.1
          
   Compiling 
          C-1: Getting the source code
          C-2: Tcl uses long file names
          C-3: Tcl was compiled with Borland C++
          C-4: Where are the .lib files?
          C-5: Creating Dynamic Extensions on Windows
          C-6: C++ and DLLs
          
   Compiling with Microsoft Visual C++ 
          M-1: How to fix the makefile for Microsoft Visual C++
          M-2: Can I use the Binary Release .DLL with my compiled
          applications?
          M-3: Allocate memory with Tcl_Alloc
          M-4: How to compile with Microsoft Visual C++
          
   Extensions 
          E-1: Expect isn't ported to Windows
          E-2: Tix works on 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 win41p1.exe
   file is a self-extracting archive and contains the wish executable.
   The URL is:
   
   ftp://ftp.smli.com/pub/tcl/win41p1.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:
   
     * 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. Tkmswin is useful set of utilities
   for emulating a number of Unix commands reasonably in the Win32s
   environment. The commands provided are (as of version 0.1.0.1 of
   Tkmswin):
   
   tkmswin exec filename args
          Used to create threads for windows programs to run
          independently At this time, this is not connected to any
          program pipe or descriptor Also, the -directory and -geometry
          options don't seem to work under Win32s
          
   tkmswin print filename ...
          Used to send a file to the printer in "raw" format (e.g.,
          postscript) Despite the documentation on EPS, the MSWindows
          preamble does get sent to a Postscript printer, and thus a
          blank page is emitted at the end of each job.
          
   tkmswin rm filename ...
          Used to remove files Does not support any options, and cannot
          be used to remove directories
          
   tkmswin mv filename newfile or tkmswin mv file1 file2 ... dir
          Used to rename a file or set of files. Does not support any
          options or moving directories
          
   tkmswin cp filename newfile or tkmswin cp file1 file2 ... dir
          Used to copy a file or set of files Does not support any
          options or copying directories
          
   tkmswin mkdir dir1 ...
          Used to create a directory or set of directories
          
   tkmswin rmdir dir1 ...
          Used to remove an empty directory or set of directories
          
   tkmswin get_profile -section sectname [-private filename] \
          [-default defstring] [-key string] [-max maxsize]
          Used to get information from Win3.1 .INI files -private
          filename points to a particular .INI file -section sectname
          points to the proper section of the .INI file -default
          defstring is a string to return if the key is not found
          (default "") -key string is the value to search for. If
          omitted, a list of keys is returned -max maxsize is the biggest
          return value expected (default 1024). for example, the call
          tkmswin get_profile -section fonts would normally require a
          bigger -max.
          
   tkmswin set_profile -section sectname [-private filename] \
          -key keyname -value valuename
          Similarly, sets values in the .INI files.
          
   tkmswin version
          Returns the version of this package
          
   Items to go:
          
          + cp, rm, mv should take -f arguments (instead of always
            implementing -f)
          + Directories should be movable and removable (-r option)
          + Real windows registration services should be supported
          + Common Dialog Boxes should be supported
            
   
   
   You can pick up the source code for tkmswin from Michael Schwartz's
   home page at:
   
   http://www.nyx.net/~mschwart
   
   See the ATk page from this link.
   
   -Michael Schwartz
   
   D-4: How to Run Scripts from Windows
   
   How do I run a script?
   
   There are three approaches to starting scripts in Tcl: source,
   shortcuts, and file associations.
   
   The most obvious way is to launch the Wish application and use
   "source". This is the best way to debug scripts.
   
   The second alternative is to create a Program Manager icon (Windows
   3.x or NT) or a shortcut (Windows 95). The binary release uses this
   technique for the widget tour icon. The command line for the icon
   should be something like:
   

c:\tcl\bin\wish41.exe c:\myscript.tcl

   
   
   The third way to launch a Tcl script is to create a file type
   association for the extension ".tcl" (or ".tk"). Using the File
   Manager (or My Computer in Windows 95), create a new file type for
   .tcl, and add an "open" action. The command for the action should be
   something like:
   

"c:\Program Files\tcl\bin\wish41.exe" "%1"

   
   
   Once you have set up the association, you will be able to double click
   on script files in File Manager to launch the app.
   
   Note that if either the location of wish or the location of the script
   contains spaces in any of the file names, you must enclose the name in
   quotes. For example:
   

"c:\Program Files\tcl\bin\wish41.exe" "c:\Program Files\myscript.tcl"

   
   
   -Scott Stanton
   
   You may also want to add an Edit action for Tcl files. For this, you
   need to pick an editor that won't place extra carriage returns on the
   end of lines. (Windows uses a carriage return/line feed combination to
   end each line of text, while Unix only uses a line feed.)
   
   In the Windows 95 Explorer, pick the Options choice from the View
   menu. Under the File Types tab, find your Tcl file type and Edit it.
   Under Actions, click New and name your new Action Edit. Choose your
   editor and accept all your changes.
   
   You should now be able to easily bring up an editor with a right-click
   on the file and the Edit popup option.
   
   -Hume Smith
   
   D-5: Cut, Copy and Paste in the Tcl Console Window
   
   The Tcl Console window uses the default bindings for the Tcl text
   widget, which is not compatible with the Windows standard of
   
     * Ctrl-x: cut
     * Ctrl-c: copy
     * Ctrl-v: paste
       
   
   
   Instead, the Tcl Console window (by default) uses the following
   bindings:
     * Ctrl-x: deletes selected text
     * Ctrl-w: cut
     * Alt-w: copy
     * Ctrl-y: paste
       
   
   
   -Eric Johnson
   
   D-6: Using the Windows Clipboard
   
   Associated with the Cut, Copy and Paste functions, the selection
   functions do work between Windows apps and Tcl/Tk scripts.
   
   To see this, try the following: select some text in MS Word, Write or
   any other Windows app. Copy the data to the clipboard (inside the
   app). Then, enter the following at your wish prompt:
   

 set clip [selection get -selection CLIPBOARD ]


   The variable clip should now hold the data from the clipboard.
   
   The parts that may be troublesome are that:
   
     * Unix apps tend to use an active copy and paste with the PRIMARY
       selection.
       
     * Windows apps tend to use a passive copy and paste, placing the
       data in the clipboard as an intermediary stopping point between
       the applications.
       
     * Motif applications on Unix do use the CLIPBOARD selection.
       Decoding the Motif clipboard is a left as an exercise for the
       reader.
       
     * The X selection mechanism handles a lot more than text, which
       introduces some interesting complexity.
       
   
   
   All in all, Tk does pretty good with handling selections on multiple
   operating systems.
   
   The part that may be confusing you is that wish, by default, doesn't
   use the Windows bindings for cut, copy and paste (Ctrl-X, C and P,
   respectively, at least on English systems), see above for more on
   this.
   
   -Eric Johnson
   
   D-7: send is not implemented on Windows
   
   Furthermore, it is unlikely send will be ported soon, because send
   uses the X server for communication.
   
   D-8: Start-up Files tclsh.rc and wishrc.tcl
   
   Tcl looks for ~/tclsh.rc, and wish looks for ~/wishrc.tcl. The
   tclsh.rc name is pretty inconsistent, and should probably be
   tclshrc.tcl. We don't use the .tclshrc form because it doesn't work on
   FAT filesystems. -Scott Stanton
   
   
   
   
     _________________________________________________________________
   
   
   
  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
   
   Calling exec brings on blank-screen mode
   
   In article , 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
   
   Strange behaviour of exec under Win 3.1
   
   Unfortunately the support for exec under Win32s is very limited. Most
   of this is because of Win32s. There are definitely some improvements
   that could be made (e.g. letting you start Windows apps), but it is
   never going to be as good as the Windows 95 or NT versions. Basically
   Windows 3.1 doesn't have a very complete process model, and most of
   what you see in the DOS window is done using non-Windows APIs. I could
   probably get Tcl to do the same things, but it's going to require a
   lot of very Windows 3.1 specific coding to get it to work. There are a
   number of other things that are higher priority, so it probably won't
   happen for a while. I would encourage anyone who really wants this
   feature to work on it and send me patches.
   
   -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

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


Only Call exec on 32-bit Applications

Tcl/TK for Win32 is really rotten at doing an exec on DOS mode
programs. This includes any of the DOS-like commands of the Win95
shell! If you use exec with any of the DOS mode commands, the command
might execute but control will never be returned to the WISH shell.

However, 32 bit programs work just fine with WISH. To see what I mean,
try the following command from the WISH console:

        exec notepad

This command will run the Windows notepad editor and return control to
WISH after the notepad program is exited.  If you want to run notepad
and return control immediately to WISH just use:

        exec notepad &

This behavior is identical to the UNIX versions of Tcl/TK.

So, the moral of the story is:

Only "exec" 32 bit programs with the Win32 version of Tcl/TK.

-Dennis R. LaBelle




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



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

Fileevents are supported on Win32 platforms for sockets only. We have not
yet found a way to discern when a file has more input than was already
consumed. Any help or ideas will be gratefully accepted. I believe
fileevent does not work reliably for pipes either, on Win32 platforms. I
know that fileevent does work reliably for sockets.

Two possible solutions:

     * "file size " works fine on NT, so you could poll for file size
       changes on the log file and read the new data as it comes in.
       
     * You could create a server socket in the tcl process and read from
       that in an event driven manner. Then, you could create a small
       program (written in C?) that connects to the socket. The
       subprogram polls for file size changes on the log or does a
       blocking read, and when there is data it writes it on the socket.

-Jacob Levy



B-5: winfo interps and send fails on Windows

Unfortunately, neither "winfo interp", nor "send" are implemented in
any of the Tk for Windows releases.  Hopefully this will be available
in the next release.

-Scott Stanton



B-6: You need at least 256 colors

A number of people have reported that wish simply won't work
unless you set your screen resolution to have at least 256
colors and preferably, 1024x768 pixel resolution.




B-7: Windows 3 doesn't support help contents file

The problem is that Win3.1/3.11 don't support the contents file. I
think what is needed is an additional help page that lists the
contents. This is redundant under Windows 95 and NT, but necessary
for 3.1/3.11.

For now, however, you should be able to use the keyword search
facility to get to any of the man pages.

-Scott Stanton




B-8: Problems with clock command on Windows

Beware of clock format commands across operating systems

Tcl's clock format command eventually passes it's format string
to strftime(). strftime() may have different implementations
depending on the underlying operating system.

For example, Windows NT 3.51 doesn't implement the %D, %e, and %h
directives.  This can some interesting side effects.

The bug report: If you do supply one of these unknown directives
(and nothing else), Tcl can go into a loop. The FormatClock
routine keeps calling strftime() because it mistakenly assumes that
a 0 return must mean that the target buffer is too small.  Indeed,
if you just pass it "%e", the strftime() function gets annoyed at it
as a directive and erroneously returns 0. Oddly enough adding
a bit of whitespace to the format command gets rid of the loop.

This may be an NT oddity only, I don't think you can know for sure
that it won't happen elsewhere.

-Dave Griffin





B-9: wm iconbitmap doesn't work on Windows

The wm iconbitmap command does not work on Windows.
if you execute the following command, you'll still see Tcl's icon for
your application:

wm iconbitmap . filename

To change this, you need to substitute your own .ico file and recompile
the relevant parts of the Tk source code.

-Eric Johnson


B-10: If you use a pipe (|) in open, until the child
process has terminated no events will be processed

If you start a process in a pipe, e.g., 'open "| ...."' until the child
process has terminated no events will be processed.

-John Robert LoVerso


  __________________________________________________________________________




  WINDOWS 3.1 ISSUES
  
W3-1: How to execute tclsh75.exe from Windows 3.1

You can run tclsh75.exe under Windows 3.1, but not from a DOS shell.
You can invoke tclsh75.exe by making a program manager icon for
the command line that you want to execute. Since tclsh75.exe is not a DOS
application, you can not invoke it from the shell.

-Scott Stanton


B-11: The rightmost mouse button is Button-3

Even with a two-button mouse, the rigthmost mouse button is identified in
Tk as Button-3.

This really isn't bad, especially if you coded your pop-up menus to
appear on Button-3 events, following the style of most Motif programs.
Your scripts will continue to work on Windows.

-Eric Johnson


 B-12: Tk on Windows supports cursors

The -cursor option should work on Windows now with all the
built-in X Window cursors.


  __________________________________________________________________________




  COMPILING
  
C-1: Getting the source code

The Tcl7.5 and Tk4.1 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.

For Windows users, you'll likely want the source code compressed
in ZIP format, rather than GNU gzip. Pick up the
files tcl75.zip and tk41.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++

Although the Tcl and Tk DLL's were generated using the Borland C++
compiler, it is possible to write extensions and applications in
Visual C++ (or other compilers).  There are a couple of gotchas to be
aware of, however.

First, you will need the VC++ .lib files, which can be found at
ftp://ftp.sunlabs.com/pub/tcl/vclibs41.zip.

Second, because the malloc/free supplied by Borland is not compatible
with that supplied by Microsoft, you must not free memory allocated by
Tcl using the Microsoft free(). Instead, you should use the
Tcl_Ckfree() call. The most common case is uses of Tcl_SplitList.

Additonally, you should not pass malloc'ed memory to Tcl, expecting
Tcl to free it. If you want to allocate memory that Tcl will free,
use Tcl_Ckalloc() instead. This will mostly affect uses of
Tcl_SetResult (or interp->result) and the TCL_DYNAMIC flag.

In future releases, ckalloc and ckfree will use Tcl_Ckalloc() and
Tcl_Ckfree() instead of malloc and free, but for now you should use
these routines directly.

-Scott Stanton




C-4: Where are the .lib files?

   For Borland:
          You can generate the .lib files from the .dll files shipped
          with the binary release by using the implib.exe utility that
          comes with Borland C++. For example, to generate tcl75.lib, you
          would issue the following command:
          

        implib tcl75.lib tcl75.dll

   For Visual C++:
          The .lib files for Visual C++ are available on the Sun ftp site
          for the binary release. Look for:
          

        ftp://ftp.sunlabs.com/pub/tcl/vclibs41.zip

-Scott Stanton




C-5: Creating Dynamic Extensions on Windows

Version 7.5 of Tcl now has the ability to dynamically load binary Tcl
extensions at run time. We have written a sample dynamically loadable
extension that should work on all of the platforms where dynamic
loading is supported. This example can serve as a template for
building your own extensions.

The example is available from ftp://ftp.smli.com/pub/tcl

   example.tar.Z
          This file contains a sample loadable Tcl extension for
          Macintosh, Windows, and Unix platforms.
          
   example.tar.gz
          Same as example.tar.Z except compressed with gzip instead of
          compress.
          
   example.zip
          Same as example.tar.Z except archived with zip instead of tar
          and compress.
          
-Scott Stanton





C-6: C++ and DLLs

If you write your Tcl extensions in C++, you'll likely need to
use the extern "C" { }; statement in C++ to use your functions
in Tcl. This is due to the user of "name mangling" in most C++
compilers.



  __________________________________________________________________________




  COMPILING WITH MICROSOFT VISUAL C++?
  
M-1: 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-2: Can I use the Binary Release .DLL with my compiled applications?

The binary release is compiled with Borland C++. You can build the
DLLs from source code, or download the libraries compiled with
Microsoft Visual C++ from the the Sun FTP server:

ftp://ftp.sunlabs.com/pub/tcl/vclibs41.zip

-Scott Stanton and Cristian Mata



M-3: Allocate memory with Tcl_Alloc

If you allocate memory from within a Visual C++ program and pass that
memory on the the Tcl DLLs, you must allocate that memory with
Tcl_Alloc().

If you allocate memory via some other means, pass that memory to Tcl
and later get a crash, you were warned.



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


  __________________________________________________________________________




  EXTENSIONS

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.


E-2: Tix works on Windows

The Tix extension has been ported to windows.



  __________________________________________________________________________


Thanks To:

John Buckman
Gordon Chaffee
Joe English
Dave Griffin
Alex Hubbard
Dennis R. LaBelle
Gordon Lack
Jacob Levy
Don Libes
John Robert LoVerso
Cristian Mata
Robert Philpott
Josh Putnam
Brian L. Rubow
Michael Schwartz
Charles A. Shartsis
Hume Smith
Scott Stanton
Larry Virden


Compiled by Eric Johnson, author of Graphical Applications
with Tcl and Tk. 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/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

