Updated to latest CVS version of pthreads

1 files changed, 252 insertions, 225 deletions

diff --git a/pthreads/README b/pthreads/README
index 545360bfa..9e9bb8103 100644
--- a/pthreads/README
+++ b/pthreads/README
@@ -10,15 +10,14 @@ specific to pthreads-win32, copyrights and the LGPL.
 What is it?
 -----------
 
-Pthreads-win32 is an Open Source Software implementation of the
-Threads component of the POSIX 1003.1c 1995 Standard (or later)
-for Microsoft's Win32 environment. Some functions from POSIX
-1003.1b are also supported including semaphores. Other related
-functions include the set of read-write lock functions. The
+Pthreads-win32 (a.k.a. pthreads4w) is an Open Source Software
+implementation of the Threads component of the POSIX 1003.1c 1995
+Standard (or later) for Microsoft's Windows environment. Some functions
+from POSIX 1003.1b are also supported, including semaphores. Other
+related functions include the set of read-write lock functions. The
 library also supports some of the functionality of the Open
-Group's Single Unix specification, version 2, namely mutex types,
-plus some common and pthreads-win32 specific non-portable
-routines (see README.NONPORTABLE).
+Group's Single Unix specification, namely mutex types, plus some common
+and pthreads-win32 specific non-portable routines (see README.NONPORTABLE).
 
 See the file "ANNOUNCE" for more information including standards
 conformance details and the list of supported and unsupported
@@ -27,15 +26,15 @@ routines.
 
 Prerequisites
 -------------
-MSVC or GNU C (MinGW32 MSys development kit)
+MSVC or GNU C (MinGW32 or MinGW64 MSys development kit)
 	To build from source.
 
 QueueUserAPCEx by Panagiotis E. Hadjidoukas
-	To support any thread cancelation in C++ library builds or
-	to support cancelation of blocked threads in any build.
+	To support any thread cancellation in C++ library builds or
+	to support cancellation of blocked threads in any build.
 	This library is not required otherwise.
 
-	For true async cancelation of threads (including blocked threads).
+	For true async cancellation of threads (including blocked threads).
 	This is a DLL and Windows driver that provides pre-emptive APC
 	by forcing threads into an alertable state when the APC is queued.
 	Both the DLL and driver are provided with the pthreads-win32.exe
@@ -47,7 +46,7 @@ QueueUserAPCEx by Panagiotis E. Hadjidoukas
 	Pthreads-win32 will automatically detect if the QueueUserAPCEx DLL
 	QuserEx.DLL is available and whether the driver AlertDrv.sys is
 	loaded. If it is not available, pthreads-win32 will simulate async
-	cancelation, which means that it can async cancel only threads that
+	cancellation, which means that it can async cancel only threads that
 	are runnable. The simulated async cancellation cannot cancel blocked
 	threads.
 
@@ -64,6 +63,11 @@ handling schemes and compilers - and because the library
 may not work reliably if these are mixed in an application,
 each different version of the library has it's own name.
 
+Please do not distribute your own modified versions of the library
+using names conforming to this description. You can use the
+makefile variable "EXTRAVERSION" to append your own suffix to the
+library names when building and testing your library.
+
 Note 1: the incompatibility is really between EH implementations
 of the different compilers. It should be possible to use the
 standard C version from either compiler with C++ applications
@@ -82,80 +86,85 @@ version (it should be arbitrary) as pthread.dll, including
 pthread.lib and libpthread.a as appropriate. This is no longer
 likely to happen.
 
-Note 4: the compatibility number was added so that applications
-can differentiate between binary incompatible versions of the
-libs and dlls.
+Note 4: the compatibility number (major version number) was
+added so that applications can differentiate between binary
+incompatible versions of the libs and dlls.
 
-In general:
-	pthread[VG]{SE,CE,C}[c].dll
-	pthread[VG]{SE,CE,C}[c].lib
+In general the naming format used is:
+    pthread[VG]{SE,CE,C}[c][E].dll
+    pthread[VG]{SE,CE,C}[c][E].lib
 
 where:
-	[VG] indicates the compiler
-	V	- MS VC, or
-	G	- GNU C
+    [VG] indicates the compiler
+        V	- MS VC, or
+        G	- GNU C
 
-	{SE,CE,C} indicates the exception handling scheme
-	SE	- Structured EH, or
-	CE	- C++ EH, or
-	C	- no exceptions - uses setjmp/longjmp
+    {SE,CE,C} indicates the exception handling scheme
+        SE	- Structured EH, or
+        CE	- C++ EH, or
+        C	- no exceptions - uses setjmp/longjmp
 
-	c	- DLL compatibility number indicating ABI and API
-		  compatibility with applications built against
-		  a snapshot with the same compatibility number.
-		  See 'Version numbering' below.
+        c	- DLL major version number indicating ABI
+              compatibility with applications built against
+              a snapshot with the same major version number.
+              See 'Version numbering' below.
+        E	- EXTRAVERSION suffix.
 
 The name may also be suffixed by a 'd' to indicate a debugging version
-of the library. E.g. pthreadVC2d.lib. Debugging versions contain
-additional information for debugging (symbols etc) and are often not
-optimised in any way (compiled with optimisation turned off).
+of the library. E.g. pthreadVC2d.lib. These will be created e.g. when
+the *-debug makefile targets are used.
 
 Examples:
-	pthreadVSE.dll	(MSVC/SEH)
-	pthreadGCE.dll	(GNUC/C++ EH)
-	pthreadGC.dll	(GNUC/not dependent on exceptions)
-	pthreadVC1.dll	(MSVC/not dependent on exceptions - not binary
-			compatible with pthreadVC.dll)
-	pthreadVC2.dll	(MSVC/not dependent on exceptions - not binary
-			compatible with pthreadVC1.dll or pthreadVC.dll)
+	pthreadVC2.dll	    (MSVC/not dependent on exceptions - not binary
+                         compatible with pthreadVC1.dll or pthreadVC.dll)
+    pthreadGC2-w32.dll  (As built, e.g., by "make GC ARCH=-m32 EXTRAVERSION=-w32")
+    pthreadVC2-w64.dll  (As built, e.g., by "nmake VC ARCH=-m64 EXTRAVERSION=-w64")
 
-The GNU library archive file names have correspondingly changed to:
+For information on ARCH (MinGW GNUmakefile) or TARGET_CPU (MSVS Makefile)
+see the respective "Building with ..." sections below.
 
-	libpthreadGCEc.a
-	libpthreadGCc.a
+The GNU library archive file names have correspondingly changed, e.g.:
 
+	libpthreadGCE2.a
+	libpthreadGC2.a
+	libpthreadGC2-w64.a
 
-Versioning numbering
---------------------
 
-Version numbering is separate from the snapshot dating system, and
-is the canonical version identification system embedded within the
-DLL using the Microsoft version resource system. The versioning
-system chosen follows the GNU Libtool system. See
-http://www.gnu.org/software/libtool/manual.html section 6.2.
+Version numbering
+-----------------
 
-See the resource file 'version.rc'.
+See pthread.h and the resource file 'version.rc'.
 
 Microsoft version numbers use 4 integers:
 
 	0.0.0.0
 
-Pthreads-win32 uses the first 3 following the Libtool convention.
+Pthreads-win32 uses the first 3 following the standard major.minor.micro
+system. We had claimed to follow the Libtool convention but this has
+not been the case with recent releases. Binary compatibility and
+consequently library file naming has not changed over this time either
+so it should not cause any problems.
+
 The fourth is commonly used for the build number, but will be reserved
 for future use.
 
-	current.revision.age.0
+	major.minor.micro.0
 
 The numbers are changed as follows:
 
-1. If the library source code has changed at all since the last update,
-   then increment revision (`c:r:a' becomes `c:r+1:a').
-2. If any interfaces have been added, removed, or changed since the last
-   update, increment current, and set revision to 0.
-3. If any interfaces have been added since the last public release, then
-   increment age.
-4. If any interfaces have been removed or changed since the last public
-   release, then set age to 0.
+1. If the general binary interface (ABI) has changed at all since the
+   last update in a way that requires recompilation and relinking of
+   applications, then increment Major, and set both minor and micro to 0.
+   (`M:m:u' becomes `M+1:0:0')
+2. If the general API has changed at all since the last update or
+   there have been semantic/behaviour changes (bug fixes etc) but does
+   not require recompilation of existing applications, then increment
+   minor and set micro to 0.
+   (`M:m:u' becomes `M:m+1:0')
+3. If there have been no interface or semantic changes since the last
+   public release but a new release is deemed necessary for some reason,
+   then increment micro.
+   (`M:m:u' becomes `M:m:u+1')
 
 
 DLL compatibility numbering is an attempt to ensure that applications
@@ -167,13 +176,10 @@ this inevitably requires incompatible versions of the same DLLs to have
 different names.
 
 Pthreads-win32 has adopted the Cygwin convention of appending a single
-integer number to the DLL name. The number used is based on the library
-version number and is computed as 'current' - 'age'.
-
-(See http://home.att.net/~perlspinr/libversioning.html for a nicely
-detailed explanation.)
+integer number to the DLL name. The number used is simply the library's
+major version number.
 
-Using this method, DLL name/s will only change when the DLL's
+Consequently, DLL name/s will only change when the DLL's
 backwards compatibility changes. Note that the addition of new
 'interfaces' will not of itself change the DLL's compatibility for older
 applications.
@@ -186,51 +192,18 @@ or,
 What are all these pthread*.dll and pthread*.lib files?
 -------------------------------------------------------
 
-Simple, use either pthreadGCv.* if you use GCC, or pthreadVCv.* if you
-use MSVC - where 'v' is the DLL versioning (compatibility) number.
+Simple, use either pthreadGCc.* if you use GCC, or pthreadVCc.* if you
+use MSVC - where 'c' is the DLL versioning (compatibility) number.
 
 Otherwise, you need to choose carefully and know WHY.
 
 The most important choice you need to make is whether to use a
 version that uses exceptions internally, or not. There are versions
 of the library that use exceptions as part of the thread
-cancelation and exit implementation. The default version uses
+cancellation and exit implementation. The default version uses
 setjmp/longjmp.
 
-There is some contension amongst POSIX threads experts as
-to how POSIX threads cancelation and exit should work
-with languages that use exceptions, e.g. C++ and even C
-(Microsoft's Structured Exceptions).
-
-The issue is: should cancelation of a thread in, say,
-a C++ application cause object destructors and C++ exception
-handlers to be invoked as the stack unwinds during thread
-exit, or not?
-
-There seems to be more opinion in favour of using the
-standard C version of the library (no EH) with C++ applications
-for the reason that this appears to be the assumption commercial
-pthreads implementations make. Therefore, if you use an EH version
-of pthreads-win32 then you may be under the illusion that
-your application will be portable, when in fact it is likely to
-behave differently when linked with other pthreads libraries.
-
-Now you may be asking: then why have you kept the EH versions of
-the library?
-
-There are a couple of reasons:
-- there is division amongst the experts and so the code may
-  be needed in the future. Yes, it's in the repository and we
-  can get it out anytime in the future, but it would be difficult
-  to find.
-- pthreads-win32 is one of the few implementations, and possibly
-  the only freely available one, that has EH versions. It may be
-  useful to people who want to play with or study application
-  behaviour under these conditions.
-
-Notes:
-
-[If you use either pthreadVCE or pthreadGCE]
+If you use either pthreadVCE or pthreadGCE:
 
 1. [See also the discussion in the FAQ file - Q2, Q4, and Q5]
 
@@ -248,13 +221,9 @@ threads then you will need to replace the "catch(...)" with the macro
 		}
 	#endif
 
-Otherwise neither pthreads cancelation nor pthread_exit() will work
+Otherwise neither pthreads cancellation nor pthread_exit() will work
 reliably when using versions of the library that use C++ exceptions
-for cancelation and thread exit.
-
-This is due to what is believed to be a C++ compliance error in VC++
-whereby you may not have multiple handlers for the same exception in
-the same try/catch block. GNU G++ doesn't have this restriction.
+for cancellation and thread exit.
 
 
 Other name changes
@@ -285,7 +254,7 @@ from the compiler used, and one of the following was defined accordingly:
 	__CLEANUP_C	C, including GNU GCC, not MSVC
 
 These defines determine the style of cleanup (see pthread.h) and,
-most importantly, the way that cancelation and thread exit (via
+most importantly, the way that cancellation and thread exit (via
 pthread_exit) is performed (see the routine ptw32_throw()).
 
 In short, the exceptions versions of the library throw an exception
@@ -297,7 +266,7 @@ is when it's canceled or exits via pthread_exit().
 In this snapshot, unless the build explicitly defines (e.g. via a
 compiler option) __CLEANUP_SEH, __CLEANUP_CXX, or __CLEANUP_C, then
 the build NOW always defaults to __CLEANUP_C style cleanup. This style
-uses setjmp/longjmp in the cancelation and pthread_exit implementations,
+uses setjmp/longjmp in the cancellation and pthread_exit implementations,
 and therefore won't do stack unwinding even when linked to applications
 that have it (e.g. C++ apps). This is for consistency with most/all
 commercial Unix POSIX threads implementations.
@@ -329,104 +298,185 @@ now run or crash in similar ways irrespective of the pthreads platform
 you use. Or at least this is the hope.
 
 
-Building under VC++ using C++ EH, Structured EH, or just C
-----------------------------------------------------------
+Development Build Toolchains and Configurations
+-----------------------------------------------
+
+As of Release 2.10 all build configurations pass the full test suite
+for the following toolchains and configurations:
+
+DLL and static library (full inlined and small) builds:
+VC, VCE, VSE
+GC, GCE
+
+MSVS:
+Intel Core i7 (6 Core HT)
+Windows 7 64 bit
+MSVS 2010 Express with SDK 7.1 (using the SDK command shell)
+TARGET_CPU = x64 and x86
+
+GNU:
+Intel Core i7 (6 Core HT)
+Windows 7 64 bit
+MinGW64 multilib enabled
+ARCH = -m32 and -m64
+
+
+Building with MS Visual Studio (C, VC++ using C++ EH, or Structured EH)
+-----------------------------------------------------------------------
 
 From the source directory run nmake without any arguments to list
 help information. E.g.
 
 $ nmake
 
-Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
-Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
+As examples, as at Release 2.10 the pre-built DLLs and static libraries
+are built from the following command-lines:
+
+[Note: "setenv" comes with the SDK. "/2003" is used to override my build
+system which is Win7 (at the time of writing) for backwards compatibility.]
+
+$ setenv /x64 /2003 /Release
+$ nmake realclean VC
+$ nmake realclean VCE
+$ nmake realclean VSE
+$ nmake realclean VC-static
+$ nmake realclean VCE-static
+$ nmake realclean VSE-static
+$ setenv /x86 /2003 /Release
+$ nmake realclean VC
+$ nmake realclean VCE
+$ nmake realclean VSE
+$ nmake realclean VC-static
+$ nmake realclean VCE-static
+$ nmake realclean VSE-static
 
-Run one of the following command lines:
-nmake clean VCE (to build the MSVC dll with C++ exception handling)
-nmake clean VSE (to build the MSVC dll with structured exception handling)
-nmake clean VC (to build the MSVC dll with C cleanup code)
-nmake clean VCE-inlined (to build the MSVC inlined dll with C++ exception handling)
-nmake clean VSE-inlined (to build the MSVC inlined dll with structured exception handling)
-nmake clean VC-inlined (to build the MSVC inlined dll with C cleanup code)
-nmake clean VC-static (to build the MSVC static lib with C cleanup code)
-nmake clean VCE-debug (to build the debug MSVC dll with C++ exception handling)
-nmake clean VSE-debug (to build the debug MSVC dll with structured exception handling)
-nmake clean VC-debug (to build the debug MSVC dll with C cleanup code)
-nmake clean VCE-inlined-debug (to build the debug MSVC inlined dll with C++ exception handling)
-nmake clean VSE-inlined-debug (to build the debug MSVC inlined dll with structured exception handling)
-nmake clean VC-inlined-debug (to build the debug MSVC inlined dll with C cleanup code)
-nmake clean VC-static-debug (to build the debug MSVC static lib with C cleanup code)
+If you want to differentiate between libraries by their names you can use,
+e.g.:
 
+$ nmake realclean VC EXTRAVERSION="-w64"
 
-The pre-built dlls are normally built using the *-inlined targets.
+The string provided via the variable EXTRAVERSION is appended to the dll
+and .lib library names, e.g.:
+
+pthreadVC2-w64.dll
+pthreadVC2-w64.lib
+
+To build and test all DLLs and static lib compatibility versions
+(VC, VCE, VSE):
+
+[Note that the EXTRAVERSION="..." option is passed to the tests Makefile
+when you target "all-tests". If you change to the tests directory and
+run the tests you will need to repeat the option explicitly to the test
+"nmake" command-line.]
+
+$ setenv /x64 /2003 /release
+$ nmake all-tests
 
 You can run the testsuite by changing to the "tests" directory and
 running nmake. E.g.:
 
 $ cd tests
-$ nmake
+$ nmake VC
+
+For failure analysis etc. individual tests can be built
+and run, e.g:
 
-Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
-Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
+$ cd tests
+$ nmake VC TESTS="foo bar"
+
+This builds and runs all prerequisite tests as well as the individual
+tests listed. Prerequisite tests are defined in tests\runorder.mk.
+
+To build and run only those tests listed use, i.e. without the
+additional prerequistite dependency tests:
 
-Run one of the following command lines:
-nmake clean VC (to test using VC dll with VC (no EH) applications)
-nmake clean VCX (to test using VC dll with VC++ (EH) applications)
-nmake clean VCE (to test using the VCE dll with VC++ EH applications)
-nmake clean VSE (to test using VSE dll with VC (SEH) applications)
-nmake clean VC-bench (to benchtest using VC dll with C bench app)
-nmake clean VCX-bench (to benchtest using VC dll with C++ bench app)
-nmake clean VCE-bench (to benchtest using VCE dll with C++ bench app)
-nmake clean VSE-bench (to benchtest using VSE dll with SEH bench app)
-nmake clean VC-static (to test using VC static lib with VC (no EH) applications)
+$ cd tests
+$ nmake VC NO_DEPS=1 TESTS="foo bar"
 
 
-Building under Mingw32
-----------------------
+Building with MinGW
+-------------------
 
-The dll can be built easily with recent versions of Mingw32.
-(The distributed versions are built using Mingw32 and MsysDTK
-from www.mingw32.org.)
+Please use Mingw64 to build either 64 or 32 bit variants of the DLL that will
+run on 64 bit systems. We have found that Mingw32 builds of the GCE library
+variants fail when run on 64 bit systems.
 
-From the source directory, run make for help information. E.g.:
+From the source directory, run 'make' without arguments for help information.
 
 $ make
-Run one of the following command lines:
-make clean GC            (to build the GNU C dll with C cleanup code)
-make clean GCE           (to build the GNU C dll with C++ exception handling)
-make clean GC-inlined    (to build the GNU C inlined dll with C cleanup code)
-make clean GCE-inlined   (to build the GNU C inlined dll with C++ exception handling)
-make clean GC-static     (to build the GNU C inlined static lib with C cleanup code)
-make clean GC-debug      (to build the GNU C debug dll with C cleanup code)
-make clean GCE-debug     (to build the GNU C debug dll with C++ exception handling)
-make clean GC-inlined-debug    (to build the GNU C inlined debug dll with C cleanup code)
-make clean GCE-inlined-debug   (to build the GNU C inlined debug dll with C++ exception handling)
-make clean GC-static-debug     (to build the GNU C inlined static debug lib with C cleanup code)
 
+With MinGW64 multilib installed the following variables can be defined
+either on the make command line or in the shell environment:
+
+ARCH
+ - possible values are "-m64" and "-m32". You will probably recognise
+   these as gcc flags however the GNUmakefile also converts these into
+   the appropriate windres options when building version.o.
+
+As examples, as at Release 2.10 the pre-built DLLs and static libraries
+are built from the following command-lines:
 
-The pre-built dlls are normally built using the *-inlined targets.
+$ nmake realclean GC ARCH=-m64
+$ nmake realclean GC ARCH=-m32
+$ nmake realclean GCE ARCH=-m64
+$ nmake realclean GCE ARCH=-m32
+$ nmake realclean GC-static ARCH=-m64
+$ nmake realclean GC-static ARCH=-m32
+$ nmake realclean GCE-static ARCH=-m64
+$ nmake realclean GCE-static ARCH=-m32
+
+If you want to differentiate between libraries by their names you can use,
+e.g.:
+
+$ make realclean GC ARCH="-m64" EXTRAVERSION="-w64"
+
+The string provided via the variable EXTRAVERSION is appended to the dll
+and .a library names, e.g.:
+
+pthreadGC2-w64.dll
+libpthreadGC2-w64.a
+
+To build and test all DLLs and static lib compatibility variants (GC, GCE):
+
+Note that the ARCH="..." and/or EXTRAVERSION="..." options are passed to the
+tests GNUmakefile when you target "all-tests". If you change to the tests
+directory and run the tests you will need to repeat those options explicitly
+to the test "make" command-line.
+
+$ make all-tests
+or, with MinGW64 (multilib enabled):
+$ make all-tests ARCH=-m64
+$ make all-tests ARCH=-m32
 
 You can run the testsuite by changing to the "tests" directory and
-running make for help information. E.g.:
+running make. E.g.:
 
 $ cd tests
-$ make
-Run one of the following command lines:
-make clean GC    (to test using GC dll with C (no EH) applications)
-make clean GCX   (to test using GC dll with C++ (EH) applications)
-make clean GCE   (to test using GCE dll with C++ (EH) applications)
-make clean GC-bench       (to benchtest using GNU C dll with C cleanup code)
-make clean GCE-bench   (to benchtest using GNU C dll with C++ exception handling)
-make clean GC-static   (to test using GC static lib with C (no EH) applications)
+$ make GC
+
+For failure analysis etc. individual tests can be built and run, e.g:
 
+$ cd tests
+$ make GC TESTS="foo bar"
+
+This builds and runs all prerequisite tests as well as the individual
+tests listed. Prerequisite tests are defined in tests\runorder.mk.
 
-Building under Linux using the Mingw32 cross development tools
---------------------------------------------------------------
+To build and run only those tests listed use, i.e. without the additional
+prerequistite dependency tests:
 
-You can build the library without leaving Linux by using the Mingw32 cross
-development toolchain. See http://www.libsdl.org/extras/win32/cross/ for
-tools and info. The GNUmakefile contains some support for this, for example:
+$ cd tests
+$ make GC NO_DEPS=1 TESTS="foo bar"
 
-make CROSS=i386-mingw32msvc- clean GC-inlined
+
+Building under Linux using the MinGW cross development tools
+------------------------------------------------------------
+
+You can build the library on Linux by using the MinGW cross development
+toolchain. See http://www.libsdl.org/extras/win32/cross/ for tools and
+info. The GNUmakefile contains some support for this, for example:
+
+make CROSS=i386-mingw32msvc- clean GC
 
 will build pthreadGCn.dll and libpthreadGCn.a (n=version#), provided your
 cross-tools/bin directory is in your PATH (or use the cross-make.sh script
@@ -449,30 +499,12 @@ MinGW32 (creates libpthreadGCn.a as a static link lib):
 
 make clean GC-static
 
-
-Define PTW32_STATIC_LIB when building your application. Also, your
-application must call a two non-portable routines to initialise the
-some state on startup and cleanup before exit. One other routine needs
-to be called to cleanup after any Win32 threads have called POSIX API
-routines. See README.NONPORTABLE or the html reference manual pages for
-details on these routines:
-
-BOOL pthread_win32_process_attach_np (void);
-BOOL pthread_win32_process_detach_np (void);
-BOOL pthread_win32_thread_attach_np (void); // Currently a no-op
-BOOL pthread_win32_thread_detach_np (void);
-
-
-The tests makefiles have the same targets but only check that the
-static library is statically linkable. They don't run the full
-testsuite. To run the full testsuite, build the dlls and run the
-dll test targets.
-
+Define PTW32_STATIC_LIB also when building your application.
 
 Building the library under Cygwin
 ---------------------------------
 
-Cygwin is implementing it's own POSIX threads routines and these
+Cygwin implements it's own POSIX threads routines and these
 will be the ones to use if you develop using Cygwin.
 
 
@@ -485,39 +517,34 @@ from the FTP site (see under "Availability" below):
 	pthread.h
 	semaphore.h
 	sched.h
-	pthreadVC.dll	- built with MSVC compiler using C setjmp/longjmp
-	pthreadVC.lib
-	pthreadVCE.dll	- built with MSVC++ compiler using C++ EH
-	pthreadVCE.lib
-	pthreadVSE.dll	- built with MSVC compiler using SEH
-	pthreadVSE.lib
-	pthreadGC.dll	- built with Mingw32 GCC
-	libpthreadGC.a	- derived from pthreadGC.dll
-	pthreadGCE.dll	- built with Mingw32 G++
-	libpthreadGCE.a	- derived from pthreadGCE.dll
-
-As of August 2003 pthreads-win32 pthreadG* versions are built and tested
-using the MinGW + MsysDTK environment current as of that date or later.
-The following file MAY be needed for older MinGW environments.
-
-	gcc.dll 	- needed to build and run applications that use
-			  pthreadGCE.dll.
-
+	pthreadVC2.dll		- built with MSVC compiler using C setjmp/longjmp
+	pthreadVC2.lib
+	pthreadVCE2.dll		- built with MSVC++ compiler using C++ EH
+	pthreadVCE2.lib
+	pthreadVSE2.dll		- built with MSVC compiler using SEH
+	pthreadVSE2.lib
+	pthreadGC2.dll		- built with Mingw32 GCC
+	libpthreadGC2.a		- derived from pthreadGC.dll
+	pthreadGCE2.dll		- built with Mingw32 G++
+	libpthreadGCE2.a	- derived from pthreadGCE.dll
+
+You may also need to include runtime DLLs from your SDK when
+distributing your applications.
 
 Building applications with GNU compilers
 ----------------------------------------
 
-If you're using pthreadGC.dll:
+If you're using pthreadGC2.dll:
 
-With the three header files, pthreadGC.dll and libpthreadGC.a in the
+With the three header files, pthreadGC2.dll and libpthreadGC2.a in the
 same directory as your application myapp.c, you could compile, link
-and run myapp.c under Mingw32 as follows:
+and run myapp.c under MinGW as follows:
 
-	gcc -o myapp.exe myapp.c -I. -L. -lpthreadGC
+	gcc -o myapp.exe myapp.c -I. -L. -lpthreadGC2
 	myapp
 
-Or put pthreadGC.dll in an appropriate directory in your PATH,
-put libpthreadGC.a in your system lib directory, and
+Or put pthreadGC2.dll in an appropriate directory in your PATH,
+put libpthreadGC2.a in your system lib directory, and
 put the three header files in your system include directory,
 then use:
 
@@ -525,13 +552,13 @@ then use:
 	myapp
 
 
-If you're using pthreadGCE.dll:
+If you're using pthreadGCE2.dll:
 
-With the three header files, pthreadGCE.dll, gcc.dll and libpthreadGCE.a
+With the three header files, pthreadGCE2.dll and libpthreadGCE2.a
 in the same directory as your application myapp.c, you could compile,
 link and run myapp.c under Mingw32 as follows:
 
-	gcc -x c++ -o myapp.exe myapp.c -I. -L. -lpthreadGCE
+	gcc -x c++ -o myapp.exe myapp.c -I. -L. -lpthreadGCE2
 	myapp
 
 Or put pthreadGCE.dll and gcc.dll in an appropriate directory in