A frequent problem in DOS/Windows vs. C/Tcl is the use of backslashes as path separators. Tcl parses c:\test to have a Tab (\t) as third character, with "est" following that. Since strings may get parsed several times, the safest is to use slashes internally. You can get that canonical form from a backslashed pathname with

 set canonicalpathname [file join $backslashedpathname]

Going back to backslashes may be necessary for exec:

 set backslashedpathname [file nativename $canonicalpathname];#RS

On Windows I have a third party application (the dvi previewer Yap.exe) which can tell another application to go to a particular file and source line. Unfortunately it can't use dde (at least not directly) but can only execute a command line, so it wants to do something like this (it lets you design the command line):

    app.exe open %f -line %l

where '%f' will be substitued by the file, and %l by the line. Now, I have a Tcl/Tk application already running, which wants that information. How can I get it to my application in the easiest way??

RS In Inventory of IPC methods, I have sketched a proc fsignal which uses a file in a well-known directory. You could write a little script that calls

 fsignal send Open [list $filename $lineno]

and your "receiving app" could, when idle, call

 foreach {filename lineno} [fsignal wait Open] break

A recent question and answer from comp.lang.tcl asks:

What options are available for printing from a TCL (not TK) script running under Windows (NT/9x/2000)? (See also Printing a canvas under Windows.)

One way is to just open and write directly to a device like LPT1.

   set pr [open lpt1 w]

If the printer isn't attached to the local PC, you will need to capture the device to the network queue. One way to do this is with a command-line like:

  net use lpt1 \\server\printer /persistent:yes

A topic that's sure to come up more and more often is "What WinForms has to do with Tcl".

A frequent, sometimes implicit, topic is "How Tcl accesses the Win32 API". Also important for getting the right Windows feel is to "Register file types under Windows".

Display control panel: Bob Techentin wrote in comp.lang.tcl: According to knowledge base article "Q192806 How to Run Control Panel Tools by Typing a Command", just type "control desk.cpl" at a command prompt. You find that article at http://msdn.microsoft.com as well, if you get to the knowledge base and search for either the title or the article number. If you want to do this from C, you can look at Q232536.

Works fine from exec control desk.cpl too, but returns an error code, so you might want to catch it.

LV 2007 Oct 16 Note that there are several ways that one might use Tcl on Windows. One is natively. ActiveState makes ActiveTcl available, and there may be other distributions who also make Windows binary versions of the tcl and tk (as well as other) libraries. Another way to run Tcl applications on Windows is via an X window server. This mode would have the Tcl applications running on some other platform, and displaying via the X window protocol back to the Windows machine. This mode is more along the lines of an X terminal. More and more frequently, Unix developers find themselves faced with this situation. There are several tools which make this mode possible. One is the Hummingbird Exceed X Server. Another is called the Xming X window server. Cygwin used to have an X window server as well. I believe another is called X-Deep/32. Microsoft at one point had, I believe, some X server code as a part of their Posix implementation. There are others as well. If anyone has a link to a comparison of the various alternatives, please add it to this spot.

RS 2007-10-16: One recommended way of getting Windows binaries is Building Tcl/Tk with Mingw, and I can recommend it too. You first install the mingw/msys development environment (just unzip one big file - gives you a Unix-like tool environment), then unzip the Tcl/Tk sources, configure, make, make install, and you end up with the tcl/tk libraries and executables. See the wiki page for detailed instructions.

Worked well for me even on Windows 95 with 8.5b1 (and that combination officially isn't supported any more).

RS 2005-09-21:

This windows-specific procedure parses the output of net use and returns the remote name as a forward-slashed UNC path, or {} if something went wrong:

proc net_use drive {
  if ![catch {exec net use $drive} res] {
     foreach line [split $res \n] {
        if {[set pos [string first \\ $line]]>0} {
            return [file norm [string range $line $pos end]]
        }
     }
  }
}

% net_use h:
//kstbf05/SuchRich$