Merged revisions 55325-55327 via svnmerge from

svn+ssh://pythondev@svn.python.org/python/branches/p3yk

................
  r55326 | guido.van.rossum | 2007-05-14 15:07:35 -0700 (Mon, 14 May 2007) | 2 lines

  Don't use err.message, use err.args[0].
................
  r55327 | guido.van.rossum | 2007-05-14 15:11:37 -0700 (Mon, 14 May 2007) | 259 lines

  Merged revisions 54988-55226,55228-55323 via svnmerge from
  svn+ssh://pythondev@svn.python.org/python/trunk

  ........
    r54995 | neal.norwitz | 2007-04-26 23:45:32 -0700 (Thu, 26 Apr 2007) | 3 lines

    This gets the test working on Solaris.  It seems a little hokey to me,
    but the test passed on Linux and Solaris, hopefully other platforms too.
  ........
    r55002 | georg.brandl | 2007-04-27 12:20:00 -0700 (Fri, 27 Apr 2007) | 2 lines

    Version fix (bug #1708710)
  ........
    r55021 | neal.norwitz | 2007-04-29 16:53:24 -0700 (Sun, 29 Apr 2007) | 1 line

    There really are some tests that are problematic.
  ........
    r55024 | kristjan.jonsson | 2007-04-30 08:17:46 -0700 (Mon, 30 Apr 2007) | 1 line

    Complete revamp of PCBuild8 directory.  Use subdirectories for each project under the main pcbuild solution.  Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented.  Also, some of the projects that require external libraries need extra work to fully compile on x64.
  ........
    r55025 | thomas.heller | 2007-04-30 08:44:17 -0700 (Mon, 30 Apr 2007) | 4 lines

    Make sure to call PyErr_NoMemory() in several places where
    PyMem_Malloc() could potentially fail.

    Will backport to the release25-maint branch.
  ........
    r55027 | thomas.heller | 2007-04-30 09:04:57 -0700 (Mon, 30 Apr 2007) | 8 lines

    When accessing the .value attribute of a c_wchar_p instance, and the
    instance does not point to a valid wchar_t zero-terminated string,
    raise a ValueError.  c_char_p does this already.

    The ValueError message now contains the correct pointer address.

    Will backport to release25-maint.
  ........
    r55036 | georg.brandl | 2007-04-30 23:04:11 -0700 (Mon, 30 Apr 2007) | 2 lines

    Bug #1710295: exceptions are now new-style classes.
  ........
    r55038 | georg.brandl | 2007-04-30 23:08:15 -0700 (Mon, 30 Apr 2007) | 2 lines

    Patch #1710352: add missing public functions to locale.__all__.
  ........
    r55041 | vinay.sajip | 2007-05-01 03:20:03 -0700 (Tue, 01 May 2007) | 1 line

    Added new optional credentials argument to SMTPHandler.__init__, and smtp.login() is now called in SMTPHandler.emit() if credentials are specified.
  ........
    r55042 | vinay.sajip | 2007-05-01 03:21:45 -0700 (Tue, 01 May 2007) | 1 line

    Added documentation for new optional credentials argument to SMTPHandler.__init__().
  ........
    r55070 | neal.norwitz | 2007-05-01 21:47:55 -0700 (Tue, 01 May 2007) | 3 lines

    Stop using PyMem_FREE while the GIL is not held.  For details see:
    http://mail.python.org/pipermail/python-dev/2007-May/072896.html
  ........
    r55080 | armin.rigo | 2007-05-02 12:23:31 -0700 (Wed, 02 May 2007) | 6 lines

    Fix for #1303614 and #1174712:
    - __dict__ descriptor abuse for subclasses of built-in types
    - subclassing from both ModuleType and another built-in types

    Thanks zseil for the patch.
  ........
    r55083 | georg.brandl | 2007-05-02 13:02:29 -0700 (Wed, 02 May 2007) | 3 lines

    Actually raise an exception before calling ast_error_finish.
    Triggers an assertion otherwise.
  ........
    r55087 | neal.norwitz | 2007-05-02 23:47:18 -0700 (Wed, 02 May 2007) | 1 line

    Handle a couple of uncaught errors.  This should be backported
  ........
    r55090 | neal.norwitz | 2007-05-03 00:20:57 -0700 (Thu, 03 May 2007) | 4 lines

    Remove dead code.  This code couldn't be reached because earlier in
    the function there is another check for z != Py_None.
  ........
    r55092 | thomas.heller | 2007-05-03 05:02:08 -0700 (Thu, 03 May 2007) | 1 line

    Fix building _ctypes.pyd for x64 / Windows.
  ........
    r55093 | thomas.heller | 2007-05-03 05:05:20 -0700 (Thu, 03 May 2007) | 1 line

    Don't truncate pointers to integers (on win64 platform).
  ........
    r55094 | walter.doerwald | 2007-05-03 08:13:55 -0700 (Thu, 03 May 2007) | 3 lines

    Clarify the behaviour of PyUnicode_DecodeUTF16(): A BOM is only skipped
    in native order mode, and only if it's the first two bytes.
  ........
    r55101 | kristjan.jonsson | 2007-05-03 13:04:53 -0700 (Thu, 03 May 2007) | 2 lines

    Fix pcbuild8 after recent overhaul:  Added the version resource to python26.dll. Adjust stacksize to 2Mb and made large address aware for 32 bits, and set stacksize to 3Mb for 64 bits.
    Todo:  Set .dll optimized load addresses, and side-by-side packaging of the python26.dll.
  ........
    r55102 | kristjan.jonsson | 2007-05-03 13:09:56 -0700 (Thu, 03 May 2007) | 1 line

    Fix those parts in the testsuite that assumed that sys.maxint would cause overflow on x64.  Now the testsuite is well behaved on that platform.
  ........
    r55103 | kristjan.jonsson | 2007-05-03 13:27:03 -0700 (Thu, 03 May 2007) | 11 lines

    Fix problems in x64 build that were discovered by the testsuite:
    - Reenable modules on x64 that had been disabled aeons ago for Itanium.
    - Cleared up confusion about compilers for 64 bit windows.  There is only Itanium and x64.  Added macros MS_WINI64 and MS_WINX64 for those rare cases where it matters, such as the disabling of modules above.
    - Set target platform (_WIN32_WINNT and WINVER) to 0x0501 (XP) for x64, and 0x0400 (NT 4.0) otherwise, which are the targeted minimum platforms.
    - Fixed thread_nt.h.  The emulated InterlockedCompareExchange function didn?\194?\180t work on x64, probaby due to the lack of a "volatile" specifier.  Anyway, win95 is no longer a target platform.
    - Itertools module used wrong constant to check for overflow in count()
    - PyInt_AsSsize_t couldn't deal with attribute error when accessing the __long__ member.
    - PyLong_FromSsize_t() incorrectly specified that the operand were unsigned.

    With these changes, the x64 passes the testsuite, for those modules present.
  ........
    r55107 | kristjan.jonsson | 2007-05-03 17:25:08 -0700 (Thu, 03 May 2007) | 1 line

    Revert compiler comment to AMD64 for x64/AMD64 builds.
  ........
    r55115 | thomas.heller | 2007-05-04 00:14:39 -0700 (Fri, 04 May 2007) | 4 lines

    Fix some ctypes test crashes, when running with a debug Python
    version on win64 by using proper argtypes and restype function
    attributes.
  ........
    r55117 | thomas.heller | 2007-05-04 01:20:41 -0700 (Fri, 04 May 2007) | 4 lines

    On 64-bit Windows, ffi_arg must be 8 bytes long.  This fixes the
    remaining crashes in the ctypes tests, when functions return float or
    double types.
  ........
    r55120 | kristjan.jonsson | 2007-05-04 08:48:15 -0700 (Fri, 04 May 2007) | 1 line

    Update the pcbuild8 solution.  Straightened out the _ctypes project by using a .vsproj file and a masm64.rules file to avoid redundancy
  ........
    r55121 | kristjan.jonsson | 2007-05-04 10:28:06 -0700 (Fri, 04 May 2007) | 1 line

    Minor fix of PCBuild8/_ctypes vcproj, moving include dir into the .vsprops file.
  ........
    r55129 | thomas.heller | 2007-05-04 12:54:22 -0700 (Fri, 04 May 2007) | 3 lines

    Do not truncate 64-bit pointers to 32-bit integers.

    Fixes SF #1703286, will backport to release25-maint.
  ........
    r55131 | thomas.heller | 2007-05-04 12:56:32 -0700 (Fri, 04 May 2007) | 1 line

    Oops, these tests do not run on Windows CE.
  ........
    r55140 | brett.cannon | 2007-05-04 18:34:02 -0700 (Fri, 04 May 2007) | 2 lines

    Deprecate BaseException.message as per PEP 352.
  ........
    r55154 | georg.brandl | 2007-05-05 11:55:37 -0700 (Sat, 05 May 2007) | 2 lines

    Bug #1713535: typo in logging example.
  ........
    r55158 | vinay.sajip | 2007-05-06 10:53:37 -0700 (Sun, 06 May 2007) | 1 line

    Updates of recent changes to logging.
  ........
    r55165 | neal.norwitz | 2007-05-07 00:02:26 -0700 (Mon, 07 May 2007) | 1 line

    Verify changes to the trunk go to the normal checkins list
  ........
    r55169 | kristjan.jonsson | 2007-05-07 09:46:54 -0700 (Mon, 07 May 2007) | 1 line

    As per Armin Rigo's suggestion, remove special handing from intobject.c to deal with the peculiarities of classobject's implementation of the number protocol.  The nb_long method of classobject now falls back to nb_int if there is no __long__ attribute present.
  ........
    r55197 | collin.winter | 2007-05-08 21:14:36 -0700 (Tue, 08 May 2007) | 9 lines

    Fix a bug in test.test_support.open_urlresource().

    If the call to requires() doesn't precede the filesystem check, we get the following situation:
    1. ./python Lib/test/regrtest.py test_foo # test needs urlfetch, not enabled, so skipped
    2. ./python Lib/test/regrtest.py -u urlfetch test_foo # test runs
    3. ./python Lib/test/regrtest.py test_foo # test runs (!)

    By moving the call to requires() *before* the filesystem check, the fact that fetched files are cached on the local disk becomes an implementation detail, rather than a semantics-changing point of note.
  ........
    r55198 | neal.norwitz | 2007-05-08 23:43:15 -0700 (Tue, 08 May 2007) | 1 line

    Add markup for True/False.  Will backport
  ........
    r55205 | walter.doerwald | 2007-05-09 11:10:47 -0700 (Wed, 09 May 2007) | 4 lines

    Backport checkin:
    Fix a segfault when b"" was passed to b2a_qp() -- it was using strchr()
    instead of memchr().
  ........
    r55241 | neal.norwitz | 2007-05-10 22:55:15 -0700 (Thu, 10 May 2007) | 6 lines

    Don't ever report a failure when the sum of the reference count differences
    are zero.  This should help reduce the false positives.

    The message about references leaking is maintained to provide as much
    info as possible rather than simply suppressing the message at the source.
  ........
    r55242 | neal.norwitz | 2007-05-10 23:23:01 -0700 (Thu, 10 May 2007) | 1 line

    Fix typo in docstring (the module is popen2, not 3).
  ........
    r55244 | neal.norwitz | 2007-05-10 23:56:52 -0700 (Thu, 10 May 2007) | 1 line

    Remove trailing whitespace in docstring
  ........
    r55245 | neal.norwitz | 2007-05-10 23:57:33 -0700 (Thu, 10 May 2007) | 1 line

    Deprecate os.popen* and popen2 module in favor of the subprocess module.
  ........
    r55247 | neal.norwitz | 2007-05-11 00:13:30 -0700 (Fri, 11 May 2007) | 1 line

    Deprecate os.popen* and popen2 module in favor of the subprocess module. (forgot the doc)
  ........
    r55253 | georg.brandl | 2007-05-11 02:41:37 -0700 (Fri, 11 May 2007) | 3 lines

    Remove an XXX that is unnecessary.
  ........
    r55258 | georg.brandl | 2007-05-11 04:04:26 -0700 (Fri, 11 May 2007) | 2 lines

    Patch #1714700: clarify os.linesep vs. tfiles opened in text mode.
     (backport)
  ........
    r55259 | georg.brandl | 2007-05-11 04:43:56 -0700 (Fri, 11 May 2007) | 2 lines

    Update DDJ link.
  ........
    r55273 | raymond.hettinger | 2007-05-11 10:59:59 -0700 (Fri, 11 May 2007) | 1 line

    Better tests for posixpath.commonprefix
  ........
    r55287 | georg.brandl | 2007-05-12 14:06:41 -0700 (Sat, 12 May 2007) | 2 lines

    Bug #1046945: document SWIG options of distutils.
  ........
    r55290 | georg.brandl | 2007-05-13 01:04:07 -0700 (Sun, 13 May 2007) | 2 lines

    Add bz2 to content encodings.
  ........
    r55297 | neal.norwitz | 2007-05-13 13:45:05 -0700 (Sun, 13 May 2007) | 3 lines

    Remove Amoeba doc which was removed in version 1.0! according to Misc/HISTORY.
    Hopefully Guido won't shed a tear. :-)
  ........
    r55298 | neal.norwitz | 2007-05-13 13:54:19 -0700 (Sun, 13 May 2007) | 1 line

    Remove references to stdwin which was removed long ago.
  ........
    r55299 | neal.norwitz | 2007-05-13 14:13:42 -0700 (Sun, 13 May 2007) | 3 lines

    Remove support for freebsd[23] which haven't been released since 2000
    or earlier.  http://www.freebsd.org/releases/index.html
  ........
    r55320 | raymond.hettinger | 2007-05-14 13:52:31 -0700 (Mon, 14 May 2007) | 1 line

    Small speedup.
  ........
................

1 files changed, 57 insertions, 177 deletions

diff --git a/PCbuild8/readme.txt b/PCbuild8/readme.txt
index fa4fcb5..eb8cd31 100644
--- a/PCbuild8/readme.txt
+++ b/PCbuild8/readme.txt
@@ -2,44 +2,66 @@ Building Python using VC++ 8.0
 -------------------------------------
 This directory is used to build Python for Win32 platforms, e.g. Windows
 95, 98 and NT.  It requires Microsoft Visual C++ 8.0
-(a.k.a. Visual Studio 2005).
+(a.k.a. Visual Studio 2005).  There are two Platforms defined, Win32
+and x64.
 (For other Windows platforms and compilers, see ../PC/readme.txt.)
 
 All you need to do is open the workspace "pcbuild.sln" in MSVC++, select
 the Debug or Release setting (using "Solution Configuration" from
-the "Standard" toolbar"), and build the projects.
+the "Standard" toolbar"), and build the solution.
 
-The proper order to build subprojects:
+A .bat file, build.bat, is provided to simplify command line builds.
 
-1) pythoncore (this builds the main Python DLL and library files,
-               python26.{dll, lib} in Release mode)
-              NOTE:  in previous releases, this subproject was
-              named after the release number, e.g. python20.
+Some of the subprojects rely on external libraries and won't build
+unless you have them installed.
 
-2) python (this builds the main Python executable,
-           python.exe in Release mode)
-
-3) the other subprojects, as desired or needed (note:  you probably don't
-   want to build most of the other subprojects, unless you're building an
-   entire Python distribution from scratch, or specifically making changes
-   to the subsystems they implement, or are running a Python core buildbot
-   test slave; see SUBPROJECTS below)
-
-Binary files go into PCBuild8\Win32 or \x64 directories and don't
-interfere with each other.
+Binary files go into PCBuild8\$(PlatformName)($ConfigurationName),
+which will be something like Win32Debug, Win32Release, x64Release, etc.
 
 When using the Debug setting, the output files have a _d added to
 their name:  python26_d.dll, python_d.exe, parser_d.pyd, and so on.
 
-There are two special configurations for the pythoncore project and
-the solution.  These are PGIRelease and PGORelease.  They are for
-createing profile-guided optimized versions of python.dll.
-The former creates the instrumented binaries, and the latter
-runs python.exe with the instrumented python.dll on the performance
-testsuite, and creates a new, optimized, python.dll in
-PCBuild8\Win32\PGORelease, or in the x64 folder.  Note that although
-we can cross-compile x64 binaries on a 32 bit machine, we cannot
-create the PGO binaries, since they require actually running the code.
+PROFILER GUIDED OPTIMIZATION
+----------------------------
+There are two special solution configurations for Profiler Guided
+Optimization.  Careful use of this has been shown to yield more than
+10% extra speed.
+1) Build the PGInstrument solution configuration.  This will yield
+binaries in the win32PGO or x64PGO folders.  (You may want do start
+by erasing any .pgc files there, present from earlier runs.)
+2) Instrument the binaries.  Do this by for example running the test
+suite:  win32PGO\python.exe ..\lib\test\regrtest.py.  This will excercise
+python thoroughly.
+3) Build the PGUpdate solution configuration (You may need to ask it
+to rebuild.)  This will incorporate the information gathered in step 2
+and produce new binaries in the same win32PGO or x64pPGO folders.
+4) (optional) You can continue to build the PGUpdate configuration as
+you work on python.  It will continue to use the data from step 2, even
+if you add or modify files as part of your work.  Thus, it makes sense to 
+run steps 1 and 2 maybe once a week, and then use step 3) for all regular
+work.
+
+A .bat file, build_pgo.bat is included to automate this process
+
+You can convince yourself of the benefits of the PGO by comparing the
+results of the python testsuite with the regular Release build.
+
+
+C RUNTIME
+---------
+Visual Studio 2005 uses version 8 of the C runtime.  The executables are
+linked to a CRT "side by side" assembly which must be present on the target
+machine.  This is avalible under the VC/Redist folder of your visual studio
+distribution.  Note that ServicePack1 of Visual Studio 2005 has a different
+version than the original.  On XP and later operating systems that support
+side-by-side assemblies it is not enough to have the msvcrt80.dll present,
+it has to be there as a whole assembly, that is, a folder with the .dll
+and a .manifest.  Also, a check is made for the correct version.
+Therefore, one should distribute this assembly with the dlls, and keep
+it in the same directory.  For compatibility with older systems, one should
+also set the PATH to this directory so that the dll can be found.
+For more info, see the Readme in the VC/Redist folder.
+
 
 SUBPROJECTS
 -----------
@@ -267,164 +289,22 @@ _ssl
     build_ssl.py/MSVC isn't clever enough to clean OpenSSL - you must do
     this by hand.
 
-Building for Itanium
---------------------
-
-The project files support a ReleaseItanium configuration which creates
-Win64/Itanium binaries. For this to work, you need to install the Platform
-SDK, in particular the 64-bit support. This includes an Itanium compiler
-(future releases of the SDK likely include an AMD64 compiler as well).
-In addition, you need the Visual Studio plugin for external C compilers,
-from http://sf.net/projects/vsextcomp. The plugin will wrap cl.exe, to
-locate the proper target compiler, and convert compiler options
-accordingly. The project files require atleast version 0.8.
 
 Building for AMD64
 ------------------
 
-The build process for the ReleaseAMD64 configuration is very similar
-to the Itanium configuration; make sure you use the latest version of
-vsextcomp.
-
-Building Python Using the free MS Toolkit Compiler
---------------------------------------------------
-
-The build process for Visual C++ can be used almost unchanged with the free MS
-Toolkit Compiler. This provides a way of building Python using freely
-available software.
-
-Requirements
-
-    To build Python, the following tools are required:
-
-    * The Visual C++ Toolkit Compiler
-        from http://msdn.microsoft.com/visualc/vctoolkit2003/
-    * A recent Platform SDK
-        from http://www.microsoft.com/downloads/details.aspx?FamilyID=484269e2-3b89-47e3-8eb7-1f2be6d7123a
-    * The .NET 1.1 SDK
-        from http://www.microsoft.com/downloads/details.aspx?FamilyID=9b3a2ca6-3647-4070-9f41-a333c6b9181d
-
-    [Does anyone have better URLs for the last 2 of these?]
-
-    The toolkit compiler is needed as it is an optimising compiler (the
-    compiler supplied with the .NET SDK is a non-optimising version). The
-    platform SDK is needed to provide the Windows header files and libraries
-    (the Windows 2003 Server SP1 edition, typical install, is known to work -
-    other configurations or versions are probably fine as well). The .NET 1.1
-    SDK is needed because it contains a version of msvcrt.dll which links to
-    the msvcr71.dll CRT. Note that the .NET 2.0 SDK is NOT acceptable, as it
-    references msvcr80.dll.
-
-    All of the above items should be installed as normal.
-
-    If you intend to build the openssl (needed for the _ssl extension) you
-    will need the C runtime sources installed as part of the platform SDK.
-
-    In addition, you will need Nant, available from
-    http://nant.sourceforge.net. The 0.85 release candidate 3 version is known
-    to work. This is the latest released version at the time of writing. Later
-    "nightly build" versions are known NOT to work - it is not clear at
-    present whether future released versions will work.
-
-Setting up the environment
-
-    Start a platform SDK "build environment window" from the start menu. The
-    "Windows XP 32-bit retail" version is known to work.
-
-    Add the following directories to your PATH:
-        * The toolkit compiler directory
-        * The SDK "Win64" binaries directory
-	* The Nant directory
-    Add to your INCLUDE environment variable:
-        * The toolkit compiler INCLUDE directory
-    Add to your LIB environment variable:
-        * The toolkit compiler LIB directory
-	* The .NET SDK Visual Studio 2003 VC7\lib directory
-
-    The following commands should set things up as you need them:
-
-        rem Set these values according to where you installed the software
-        set TOOLKIT=C:\Program Files\Microsoft Visual C++ Toolkit 2003
-        set SDK=C:\Program Files\Microsoft Platform SDK
-        set NET=C:\Program Files\Microsoft Visual Studio .NET 2003
-        set NANT=C:\Utils\Nant
-
-        set PATH=%TOOLKIT%\bin;%PATH%;%SDK%\Bin\win64;%NANT%\bin
-        set INCLUDE=%TOOLKIT%\include;%INCLUDE%
-        set LIB=%TOOLKIT%\lib;%NET%\VC7\lib;%LIB%
-
-    The "win64" directory from the SDK is added to supply executables such as
-    "cvtres" and "lib", which are not available elsewhere. The versions in the
-    "win64" directory are 32-bit programs, so they are fine to use here.
-
-    That's it. To build Python (the core only, no binary extensions which
-    depend on external libraries) you just need to issue the command
-
-        nant -buildfile:python.build all
-
-    from within the PCBuild directory.
-
-Extension modules
-
-    To build those extension modules which require external libraries
-    (_tkinter, bz2, _bsddb, _sqlite3, _ssl) you can follow the instructions
-    for the Visual Studio build above, with a few minor modifications. These
-    instructions have only been tested using the sources in the Python
-    subversion repository - building from original sources should work, but
-    has not been tested.
-
-    For each extension module you wish to build, you should remove the
-    associated include line from the excludeprojects section of pc.build.
-
-    The changes required are:
-
-    _tkinter
-        The tix makefile (tix-8.4.0\win\makefile.vc) must be modified to
-	remove references to TOOLS32. The relevant lines should be changed to
-	read:
-            cc32 = cl.exe
-            link32 = link.exe
-            include32 = 
-	The remainder of the build instructions will work as given.
-
-    bz2
-        No changes are needed
-
-    _bsddb
-        The file db.build should be copied from the Python PCBuild directory
-	to the directory db-4.4.20\build_win32.
-
-	The file db_static.vcproj in db-4.4.20\build_win32 should be edited to
-	remove the string "$(SolutionDir)" - this occurs in 2 places, only
-	relevant for 64-bit builds. (The edit is required as otherwise, nant
-	wants to read the solution file, which is not in a suitable form).
-
-	The bsddb library can then be build with the command
-	    nant -buildfile:db.build all
-	run from the db-4.4.20\build_win32 directory.
-
-    _sqlite3
-        No changes are needed. However, in order for the tests to succeed, a
-	copy of sqlite3.dll must be downloaded, and placed alongside
-	python.exe.
-
-    _ssl
-        The documented build process works as written. However, it needs a
-	copy of the file setargv.obj, which is not supplied in the platform
-	SDK. However, the sources are available (in the crt source code). To
-	build setargv.obj, proceed as follows:
+Select x64 as the destination platform.
 
-        Copy setargv.c, cruntime.h and internal.h from %SDK%\src\crt to a
-	temporary directory.
-	Compile using "cl /c /I. /MD /D_CRTBLD setargv.c"
-	Copy the resulting setargv.obj to somewhere on your LIB environment
-	(%SDK%\lib is a reasonable place).
-
-	With setargv.obj in place, the standard build process should work
-	fine.
 
 YOUR OWN EXTENSION DLLs
 -----------------------
 If you want to create your own extension module DLL, there's an example
 with easy-to-follow instructions in ../PC/example/; read the file
 readme.txt there first.
+Also, you can simply use Visual Studio to "Add new project to solution".
+Elect to create a win32 project, .dll, empty project.
+This will create a subdirectory with a .vcproj file in it.  Now, You can
+simply copy most of another .vcproj, like _test_capi/_test_capi.vcproj over
+(you can't just copy and rename it, since the target will have a unique GUID.)
+At some point we want to be able to provide a template for creating a
+project.