merge trunk

8 files changed, 31 insertions, 136 deletions

diff --git a/changes b/changes
index 79a242d..d92c340 100644
--- a/changes
+++ b/changes
@@ -8492,4 +8492,19 @@ include ::oo::class (fellows)
 
 --- Released 8.6.3, November 12, 2014 --- http://core.tcl.tk/tcl/ for details
 
+2014-11-21 (bug)[743338] Win: socket error encoding (ladayaroslav,nijtmans)
+
+2014-12-01 (bug) restore tbcload/tclcompiler support (kupries)
+
+2014-12-03 (bug)[0c043a] Fix compiled [set var($) val] (porter)
+
+
 2014-12-17 (TIP 427) [fconfigure $h -connecting, -peername, -sockname] (oehlmann,rmax)
+
+
+
+
+
+
+
+--- Released 8.6.4, March 12, 2015 --- http://core.tcl.tk/tcl/ for details
diff --git a/doc/Encoding.3 b/doc/Encoding.3
index 1478c35..6664b3b 100644
--- a/doc/Encoding.3
+++ b/doc/Encoding.3
@@ -257,47 +257,13 @@ is filled with the corresponding number of bytes that were stored in
 .PP
 \fBTcl_WinUtfToTChar\fR and \fBTcl_WinTCharToUtf\fR are
 Windows-only convenience
-functions for converting between UTF-8 and Windows strings.  On Windows 95
-(as with the Unix operating system),
-all strings exchanged between Tcl and the operating system are
-.QW "char"
-based.  On Windows NT, some strings exchanged between Tcl and the
-operating system are
-.QW "char"
-oriented while others are in Unicode.  By
-convention, in Windows a TCHAR is a character in the ANSI code page
-on Windows 95 and a Unicode character on Windows NT.
-.PP
-If you planned to use the same
-.QW "char"
-based interfaces on both Windows
-95 and Windows NT, you could use \fBTcl_UtfToExternal\fR and
-\fBTcl_ExternalToUtf\fR (or their \fBTcl_DString\fR equivalents) with an
-encoding of NULL (the current system encoding).  On the other hand,
-if you planned to use the Unicode interface when running on Windows NT
-and the
-.QW "char"
-interfaces when running on Windows 95, you would have
-to perform the following type of test over and over in your program
-(as represented in pseudo-code):
-.PP
-.CS
-if (running NT) {
-    encoding <- Tcl_GetEncoding("unicode");
-    nativeBuffer <- Tcl_UtfToExternal(encoding, utfBuffer);
-    Tcl_FreeEncoding(encoding);
-} else {
-    nativeBuffer <- Tcl_UtfToExternal(NULL, utfBuffer);
-}
-.CE
-.PP
-\fBTcl_WinUtfToTChar\fR and \fBTcl_WinTCharToUtf\fR automatically
-handle this test and use the proper encoding based on the current
-operating system.  \fBTcl_WinUtfToTChar\fR returns a pointer to
-a TCHAR string, and \fBTcl_WinTCharToUtf\fR expects a TCHAR string
-pointer as the \fIsrc\fR string.  Otherwise, these functions
-behave identically to \fBTcl_UtfToExternalDString\fR and
-\fBTcl_ExternalToUtfDString\fR.
+functions for converting between UTF-8 and Windows strings
+based on the TCHAR type which is by convention
+a Unicode character on Windows NT.
+These functions are essentially wrappers around
+\fBTcl_UtfToExternalDString\fR and
+\fBTcl_ExternalToUtfDString\fR that convert to and from the
+Unicode encoding.
 .PP
 \fBTcl_GetEncodingName\fR is roughly the inverse of \fBTcl_GetEncoding\fR.
 Given an \fIencoding\fR, the return value is the \fIname\fR argument that
diff --git a/doc/exec.n b/doc/exec.n
index c3f316b..5b27e40 100644
--- a/doc/exec.n
+++ b/doc/exec.n
@@ -269,17 +269,13 @@ present, as is done when launching applications under wish.  It is desirable
 to have console applications hidden and detached.  This is a designed-in
 limitation as \fBexec\fR wants to communicate over pipes.  The Expect
 extension addresses this issue when communicating with a TUI application.
-.RE
-.TP
-\fBWindows NT\fR
-.
+.PP
 When attempting to execute an application, \fBexec\fR first searches for
 the name as it was specified.  Then, in order, \fB.com\fR, \fB.exe\fR, and
 \fB.bat\fR are appended to the end of the specified name and it searches
 for the longer name.  If a directory name was not specified as part of the
 application name, the following directories are automatically searched in
 order when attempting to locate the application:
-.RS
 .IP \(bu 3
 The directory from which the Tcl executable was loaded.
 .IP \(bu 3
@@ -299,67 +295,6 @@ the caller must prepend the desired command with
 because built-in commands are not implemented using executables.
 .RE
 .TP
-\fBWindows 9x\fR
-.
-When attempting to execute an application, \fBexec\fR first searches for
-the name as it was specified.  Then, in order, \fB.com\fR, \fB.exe\fR, and
-\fB.bat\fR are appended to the end of the specified name and it searches
-for the longer name.  If a directory name was not specified as part of the
-application name, the following directories are automatically searched in
-order when attempting to locate the application:
-.RS
-.IP \(bu 3
-The directory from which the Tcl executable was loaded.
-.IP \(bu 3
-The current directory.
-.IP \(bu 3
-The Windows 9x system directory.
-.IP \(bu 3
-The Windows 9x home directory.
-.IP \(bu 3
-The directories listed in the path.
-.RE
-.RS
-.PP
-In order to execute shell built-in commands like \fBdir\fR and \fBcopy\fR,
-the caller must prepend the desired command with
-.QW "\fBcommand.com /c\0\fR"
-because built-in commands are not implemented using executables.
-.PP
-Once a 16-bit DOS application has read standard input from a console and 
-then quit, all subsequently run 16-bit DOS applications will see the 
-standard input as already closed.  32-bit applications do not have this
-problem and will run correctly, even after a 16-bit DOS application thinks 
-that standard input is closed.  There is no known workaround for this bug
-at this time.
-.PP
-Redirection between the \fBNUL:\fR device and a 16-bit application does not
-always work.  When redirecting from \fBNUL:\fR, some applications may hang,
-others will get an infinite stream of
-.QW 0x01
-bytes, and some will actually
-correctly get an immediate end-of-file; the behavior seems to depend upon 
-something compiled into the application itself.  When redirecting greater than
-4K or so to \fBNUL:\fR, some applications will hang.  The above problems do not
-happen with 32-bit applications.  
-.PP
-All DOS 16-bit applications are run synchronously.  All standard input from
-a pipe to a 16-bit DOS application is collected into a temporary file; the
-other end of the pipe must be closed before the 16-bit DOS application
-begins executing.  All standard output or error from a 16-bit DOS
-application to a pipe is collected into temporary files; the application
-must terminate before the temporary files are redirected to the next stage
-of the pipeline.  This is due to a workaround for a Windows 95 bug in the
-implementation of pipes, and is how the standard Windows 95 DOS shell
-handles pipes itself.
-.PP
-Certain applications, such as \fBcommand.com\fR, should not be executed
-interactively.  Applications which directly access the console window,
-rather than reading from their standard input and writing to their standard
-output may fail, hang Tcl, or even hang the system if their own private
-console window is not available to them.
-.RE
-.TP
 \fBUnix\fR (including Mac OS X)
 .
 The \fBexec\fR command is fully functional and works as described.
diff --git a/doc/file.n b/doc/file.n
index 5ff45fd..4c6465a 100644
--- a/doc/file.n
+++ b/doc/file.n
@@ -241,11 +241,9 @@ as relative to the cwd).  Furthermore,
 paths are always expanded
 to absolute form.  When creating links on filesystems that either do not
 support any links, or do not support the specific type requested, an
-error message will be returned.  In particular Windows 95, 98 and ME do
-not support any links at present, but most Unix platforms support both
-symbolic and hard links (the latter for files only) and Windows
-NT/2000/XP (on NTFS drives) support symbolic
-directory links and hard file links.
+error message will be returned.  Most Unix platforms support both
+symbolic and hard links (the latter for files only). Windows
+supports symbolic directory links and hard file links on NTFS drives.
 .RE
 .TP
 \fBfile lstat \fIname varName\fR
diff --git a/doc/glob.n b/doc/glob.n
index 86e450b..a2cbce2 100644
--- a/doc/glob.n
+++ b/doc/glob.n
@@ -204,13 +204,7 @@ of the form
 it refers to the home
 directory of the user whose account information resides on the specified NT
 domain server. Otherwise, user account information is obtained from
-the local computer. On Windows 95 and 98, \fBglob\fR accepted patterns
-like
-.QW .../
-and
-.QW ..../
-for successively higher up parent directories, but later versions of
-Windows do not accept these forms.
+the local computer.
 .PP
 Since the backslash character has a special meaning to the glob
 command, glob patterns containing Windows style path separators need
diff --git a/doc/open.n b/doc/open.n
index 7fccdf1..3012460 100644
--- a/doc/open.n
+++ b/doc/open.n
@@ -370,9 +370,8 @@ works for serial ports from 1 to 9.  An attempt to open a serial port that
 does not exist or has a number greater than 9 will fail.  An alternate
 form of opening serial ports is to use the filename \fB//./comX\fR,
 where X is any number that corresponds to a serial port.
-.RS
 .PP
-.
+.RS
 When running Tcl interactively, there may be some strange interactions
 between the real console, if one is present, and a command pipeline that uses
 standard input or output.  If a command pipeline is opened for reading, some
@@ -384,6 +383,7 @@ application are competing for the console at the same time.  If the command
 pipeline is started from a script, so that Tcl is not accessing the console,
 or if the command pipeline does not use standard input or output, but is
 redirected from or to a file, then the above problems do not occur.  
+.RE
 .TP
 \fBUnix\fR\0\0\0\0\0\0\0
 .
diff --git a/doc/tcltest.n b/doc/tcltest.n
index 8d2398b..29265be 100644
--- a/doc/tcltest.n
+++ b/doc/tcltest.n
@@ -642,14 +642,6 @@ This test can only be run on any Windows platform.
 .
 This test can only be run on any Windows NT platform.
 .TP
-\fI95\fR
-.
-This test can only be run on any Windows 95 platform.
-.TP
-\fI98\fR
-.
-This test can only be run on any Windows 98 platform.
-.TP
 \fImac\fR
 .
 This test can only be run on any Mac platform.
diff --git a/doc/tclvars.n b/doc/tclvars.n
index 48ab83a..a8fba47 100644
--- a/doc/tclvars.n
+++ b/doc/tclvars.n
@@ -308,18 +308,13 @@ is the value returned by \fBuname -m\fR.
 \fBos\fR
 .
 The name of the operating system running on this machine,
-such as \fBWindows 95\fR, \fBWindows NT\fR, or \fBSunOS\fR.
+such as \fBWindows NT\fR or \fBSunOS\fR.
 On UNIX machines, this is the value returned by \fBuname -s\fR.
-On Windows 95 and Windows 98, the value returned will be \fBWindows
-95\fR to provide better backwards compatibility to Windows 95; to
-distinguish between the two, check the \fBosVersion\fR.
 .TP
 \fBosVersion\fR
 .
 The version number for the operating system running on this machine.
-On UNIX machines, this is the value returned by \fBuname -r\fR.  On
-Windows 95, the version will be 4.0; on Windows 98, the version will
-be 4.10.
+On UNIX machines, this is the value returned by \fBuname -r\fR.
 .TP
 \fBpathSeparator\fR
 .VS 8.6