23 files changed, 77 insertions, 631 deletions
diff --git a/MANIFEST.in b/MANIFEST.in
index f28e72a..52126ae 100644
--- a/MANIFEST.in
+++ b/MANIFEST.in
@@ -9,7 +9,6 @@ include src/server/*.h
 include src/server/*.c
 exclude src/server/apxs_config.py
 include tests/*
-include win32/*
 include docs/_build/html/*
 include docs/_build/html/_static/*
 include docs/_build/html/_static/css/*
diff --git a/docs/user-guides/debugging-techniques.rst b/docs/user-guides/debugging-techniques.rst
index 13d47e8..0baf52c 100644
--- a/docs/user-guides/debugging-techniques.rst
+++ b/docs/user-guides/debugging-techniques.rst
@@ -76,25 +76,36 @@ below::
         status = '200 OK'
         output = b'Hello World!'
 
-        print >> environ['wsgi.errors'], "application debug #1"
+        print("application debug #1", file=environ['wsgi.errors']))
 
         response_headers = [('Content-type', 'text/plain'),
                             ('Content-Length', str(len(output)))]
         start_response(status, response_headers)
 
-        print >> environ['wsgi.errors'], "application debug #2"
+        print("application debug #2", file=environ['wsgi.errors']))
 
         return [output]
 
+.. note::
+
+    If you are using Python 2, you will need to enable the `print` function
+    at the beginning of the file::
+
+        from __future__ import print_function
+
+    Alternatively, always use `print` as a statement rather than a function::
+
+        print >> environ['wsgi.errors']), "application debug #N"
+
 If 'wsgi.errors' is not available to the code which needs to output log
-messages, then it should explicitly direct output from the 'print'
-statement to 'sys.stderr'::
+messages, then it should explicitly direct output from 'print'
+to 'sys.stderr'::
 
     import sys
 
     def function():
-        print >> sys.stderr, "application debug #3"
-            ...
+        print("application debug #3", file=sys.stderr)
+        ...
 
 If ``sys.stderr`` or ``sys.stdout`` is used directly then
 these messages will end up in the main server host error log file and not
@@ -108,7 +119,7 @@ exception occurring of the form::
     IOError: sys.stdout access restricted by mod_wsgi
 
 This is because portable WSGI applications should not write to
-``sys.stdout`` or use the 'print' statement without specifying an
+``sys.stdout`` or use 'print' without specifying an
 alternate file object besides ``sys.stdout`` as the target. This
 restriction can be disabled for the whole server using the
 WSGIRestrictStdout directive, or by mapping ``sys.stdout`` to
@@ -167,16 +178,16 @@ well, with process ID, user ID and group ID being shown as examples::
         input = environ['wsgi.input']
         output = cStringIO.StringIO()
 
-        print >> output, "PID: %s" % os.getpid()
-        print >> output, "UID: %s" % os.getuid()
-        print >> output, "GID: %s" % os.getgid()
-        print >> output
+        print("PID: %s" % os.getpid(), file=output)
+        print("UID: %s" % os.getuid(), file=output)
+        print("GID: %s" % os.getgid(), file=output)
+        print(file=output)
 
         keys = environ.keys()
         keys.sort()
         for key in keys:
-            print >> output, '%s: %s' % (key, repr(environ[key]))
-        print >> output
+            print('%s: %s' % (key, repr(environ[key])), file=output)
+        print(file=output)
 
         output.write(input.read(int(environ.get('CONTENT_LENGTH', '0'))))
 
@@ -288,7 +299,7 @@ follows::
             self.__ocontent = ocontent
 
         def __call__(self, status, headers, *args):
-            pprint.pprint((status, headers)+args), stream=self.__oheaders)
+            pprint.pprint((status, headers)+args, stream=self.__oheaders)
             self.__oheaders.close()
 
             self.__write = self.__start_response(status, headers, *args)
@@ -334,16 +345,16 @@ follows::
             key = "%s-%s-%s" % (time.time(), self.__pid, count)
 
             iheaders = os.path.join(self.__savedir, key + ".iheaders")
-            iheaders_fp = file(iheaders, 'w')
+            iheaders_fp = open(iheaders, 'w')
 
             icontent = os.path.join(self.__savedir, key + ".icontent")
-            icontent_fp = file(icontent, 'w+b')
+            icontent_fp = open(icontent, 'w+b')
 
             oheaders = os.path.join(self.__savedir, key + ".oheaders")
-            oheaders_fp = file(oheaders, 'w')
+            oheaders_fp = open(oheaders, 'w')
 
             ocontent = os.path.join(self.__savedir, key + ".ocontent")
-            ocontent_fp = file(ocontent, 'w+b')
+            ocontent_fp = open(ocontent, 'w+b')
 
             errors = environ['wsgi.errors']
             pprint.pprint(environ, stream=iheaders_fp)
@@ -377,19 +388,20 @@ Poorly Performing Code
 ----------------------
 
 The WSGI specification allows any iterable object to be returned as the
-response, so long as the iterable yields string values. That this is the
-case means that one can too easily return an object which satisfies this
-requirement but has some sort of performance related issue.
+response, so long as the iterable yields byte-strings (``bytes``, or
+``str`` on Python 2). That this is the case means that one can too easily
+return an object which satisfies this requirement but has some sort of
+performance related issue.
 
 The worst case of this is where instead of returning a list containing
-strings, a single string is returned. The problem with a string is that
-when it is iterated over, a single character of the string is yielded each
-time. In other words, a single character is written back to the client on
-each loop, with a flush occurring in between to ensure that the character
+byte-strings, a single byte-string value is returned. The problem is that
+when a byte-string is iterated over, a single byte is yielded each
+time. In other words, a single byte is written back to the client on
+each loop, with a flush occurring in between to ensure that the byte
 has actually been written and isn't just being buffered.
 
-Although for small strings a performance impact may not be noticed, if
-returning large strings the affect on request throughput could be quite
+Although for small byte-strings a performance impact may not be noticed, if
+returning more data the effect on request throughput could be quite
 significant.
 
 Another case which can cause problems is to return a file like object. For
@@ -400,15 +412,15 @@ okay, but if the file is a binary file there may not actually be line
 breaks within the file.
 
 For the case where file contains many short lines, throughput would be
-affected much like in the case where a string is returned. For the case
+affected much like in the case where a byte-string is returned. For the case
 where the file is just binary data, the result can be that the complete
 file may be read in on the first loop. If the file is large, this could
 cause a large transient spike in memory usage. Once that memory is
-allocated, it will then be retained by the process, albeit that it may be
-reused by the process at a later point.
+allocated, it will then usually be retained by the process, albeit that
+it may be reused by the process at a later point.
 
 Because of the performance impacts in terms of throughput and memory usage,
-both these cases should be avoided. For the case of returning a string, it
+both these cases should be avoided. For the case of returning a byte-string, it
 should be returned with a single element list. For the case of a file like
 object, the 'wsgi.file_wrapper' extension should be used, or a wrapper
 which suitably breaks the response into chunks.
@@ -416,19 +428,25 @@ which suitably breaks the response into chunks.
 In order to identify where code may be inadvertently returning such iterable
 types, the following code can be used::
 
-    import types
-
-    import cStringIO
+    import io
     import socket
-    import StringIO
+    import sys
 
     BAD_ITERABLES = [
-      cStringIO.InputType,
-      socket.SocketType,
-      StringIO.StringIO,
-      types.FileType,
-      types.StringType,
+      bytes,
+      socket.socket,
+      io.IOBase,
     ]
+    if sys.version_info < (3, 0):
+        # Python 2
+        import types
+        import cStringIO
+        import StringIO
+        BAD_ITERABLES.extend([
+            types.FileType,
+            cStringIO.InputType,
+            StringIO.StringIO,
+        ])
 
     class ValidatingMiddleware:
 
@@ -441,12 +459,10 @@ types, the following code can be used::
             result = self.__application(environ, start_response)
 
             value = type(result)
-            if value == types.InstanceType:
-                value = result.__class__
             if value in BAD_ITERABLES:
-                print >> errors, 'BAD ITERABLE RETURNED: ',
-                print >> errors, 'URL=%s ' % environ['REQUEST_URI'],
-                print >> errors, 'TYPE=%s' % value
+                print('BAD ITERABLE RETURNED: ', file=errors, end='')
+                print('URL=%s ' % environ['REQUEST_URI'], file=errors, end='')
+                print('TYPE=%s' % value, file=errors)
 
             return result
 
@@ -467,8 +483,8 @@ catching middleware component.
 One example of WSGI error catching middleware is the ErrorMiddleware class
 from Paste.
 
-  * http://www.pythonpaste.org
-    
+  * https://pythonpaste.readthedocs.io/en/latest/
+
 This class can be configured not only to catch exceptions and present the
 details to the browser in an error page, it can also be configured to send
 the details of any errors in email to a designated recipient, or log the
@@ -758,7 +774,8 @@ process debug mode from within 'gdb'.
 
 To do this it is necessary to first shutdown Apache. The 'gdb' debugger can
 then be started against the 'httpd' executable and then the process started
-up from inside of 'gdb'::
+up from inside of 'gdb' with the `-X` flag to select single-process debug
+mode::
 
     $ /usr/local/apache/bin/apachectl stop
     $ sudo gdb /usr/local/apache/bin/httpd
@@ -995,21 +1012,27 @@ Sample code which takes this approach is included below. This code could be
 placed temporarily at the end of your WSGI script file if you know you are
 going to need it because of a recurring problem::
 
+    from __future__ import print_function
+
     import os
     import sys
     import time
     import signal
     import threading
     import atexit
-    import Queue
-    import traceback 
+    import traceback
+
+    try:
+        from Queue import Queue  # Python 2
+    except ImportError:
+        from queue import Queue  # Python 3
 
     FILE = '/tmp/dump-stack-traces.txt'
 
     _interval = 1.0
 
     _running = False
-    _queue = Queue.Queue()
+    _queue = Queue()
     _lock = threading.Lock()
 
     def _stacktraces(): 
@@ -1024,7 +1047,7 @@ going to need it because of a recurring problem::
                     code.append("  %s" % (line.strip())) 
 
         for line in code:
-            print >> sys.stderr, line
+            print(line, file=sys.stderr)
 
     try:
         mtime = os.path.getmtime(FILE)
@@ -1032,7 +1055,7 @@ going to need it because of a recurring problem::
         mtime = None
 
     def _monitor():
-        while 1:
+        while True:
             global mtime
 
             try:
@@ -1072,7 +1095,7 @@ going to need it because of a recurring problem::
         _lock.acquire()
         if not _running:
             prefix = 'monitor (pid=%d):' % os.getpid()
-            print >> sys.stderr, '%s Starting stack trace monitor.' % prefix
+            print('%s Starting stack trace monitor.' % prefix, file=sys.stderr)
             _running = True
             _thread.start()
         _lock.release()
diff --git a/win32/README.rst b/win32/README.rst
deleted file mode 100644
index 58f77d9..0000000
--- a/win32/README.rst
+++ /dev/null
@@ -1,292 +0,0 @@
-===========================
-Running mod_wsgi on Windows
-===========================
-
-These instructions should no longer be used. To install mod_wsgi on Windows
-run ``pip install mod_wsgi``. Once it has been successfully installed, run
-the command ``mod_wsgi-express module-config``. Copy the output of that
-command and add it to your Apache configuration to have it load mod_wsgi.
-You will still need to separately configure Apache/mod_wsgi for your
-specific WSGI application. See the mod_wsgi package page on the Python
-Package Index (PyPi) for more information.
-
-Overview
---------
-
-Running Apache/mod_wsgi on Windows can be a bit tricky.
-
-There are four requirements that should strictly be satisified.
-
-1. You need to ensure that you are using either 32 bit (Win32) versions of
-everything or 64 bit (Win64) versions of everything. You cannot mix 32 bit
-and 64 bit binaries.
-
-2. That the Python version you are using was installed for all users
-and not just the user that installed Python.
-
-3. That you are using a precompiled Apache binary built with the same
-version of the Microsoft C/C++ compiler as the version of Python you are
-using.
-
-4. That you are using a mod_wsgi binary built with the same version of
-the Microsoft C/C++ compiler as the version of Python you are using.
-
-The Microsoft C/C++ compiler versions which were used for various Python
-versions are:
-
-* Python 2.6 - VC9
-* Python 2.7 - VC9
-* Python 3.3 - VC10
-* Python 3.4 - VC10
-
-This means that if using Python 2.6 or 2.7, you should use a version of
-Apache compiled with the Microsoft VC9 C/C++ compiler. If instead using
-Python 3.3 or 3.4, you should use a version of Apache compiled with the
-Microsoft VC10 C/C++ compiler.
-
-If you ignore these requirements and use a version of Apache compiled with
-the Microsoft VC11 C/C++ compiler, then nothing can be guaranteed to work
-and Apache may fail to startup or crash when handling requests.
-
-You may also have problems with using Python 2.6 or Python 2.7 binaries,
-which were compiled with the Microsoft VC9 C/C++ compiler, with a version
-of Apache 2.4 compiled with the Microsoft VC10 C/C++ compiler.
-
-The problem is that Apache Lounge, whose Apache binaries have been used
-up until this point, has stopped making available versions of Apache
-compiled with a VC9 compiler. This means that if you hadn't managed to
-download a Win32 VC9 version of Apache at some time in the past, you
-technically can't use mod_wsgi on Windows with Python 2.6 or Python 2.7
-any more as you can't get the right version of an Apache binary.
-
-See further comments below though about a possible way of running Python
-2.6 and Python 2.7 using a Win64 VC10 version of Apache. This is not
-gauranteed to work though as explained below.
-
-Using the pre-compiled binaries
--------------------------------
-
-Occassionally precompiled binaries will be made available for mod_wsgi.
-These may not be updated on every release because more often than not code
-changes are being made which relate only to mod_wsgi daemon mode, or
-``mod_wsgi-express``, neither of which are available for Windows.
-
-When pre-compiled mod_wsgi binaries are made available they will be
-downloadable from the github release page for the mod_wsgi project at:
-
-* https://github.com/GrahamDumpleton/mod_wsgi/releases
-
-Look back at older releases if the most current version doesn't have them
-associated with it.
-
-These mod_wsgi binaries will have been compiled with Python binaries
-available from the Python Software Foundation (PSF) site at:
-
-* https://www.python.org/downloads/
-
-The mod_wsgi binaries would generally not be usable with other binary
-Python distributions unless they specify that they are entirely ABI
-compatible with the binary Python distributions from the PSF.
-
-For Apache, mod_wsgi is compiled against Apache binaries available from the
-Apache Lounge web site at:
-
-* http://www.apachelounge.com
-
-The mod_wsgi binaries would generally only be usable with Apache Lounge
-binaries and should not be used with any other Apache binary distribution.
-
-The actual mod_wsgi binaries that are made available are:
-
-* Apache22-win32-VC9/modules/mod_wsgi-py26-VC9.so
-* Apache22-win32-VC9/modules/mod_wsgi-py27-VC9.so
-
-* Apache24-win32-VC9/modules/mod_wsgi-py26-VC9.so
-* Apache24-win32-VC9/modules/mod_wsgi-py27-VC9.so
-
-* Apache24-win32-VC10/modules/mod_wsgi-py33-VC10.so
-* Apache24-win32-VC10/modules/mod_wsgi-py34-VC10.so
-
-* Apache24-win64-VC10/modules/mod_wsgi-py33-VC10.so
-* Apache24-win64-VC10/modules/mod_wsgi-py34-VC10.so
-
-Those labelled with ``Apache22-win32-VC9`` should be used with an Apache
-2.2 Win32 VC9 version of Apache. Alas Apache Lounge no longer makes such
-binaries available any more. If you don't already have an older version of
-Apache which has been compiled with the Win32 VC9 compiler you are out
-of luck.
-
-Those labelled with ``Apache24-win32-VC10`` should be used with the Apache
-2.4 Win32 VC10 version of Apache available from:
-
-* https://www.apachelounge.com/download/VC10/
-
-Those labelled with ``Apache24-win64-VC10`` should be used with the Apache
-2.4 Win64 VC10 version of Apache available from:
-
-* https://www.apachelounge.com/download/VC10/
-
-Note that Apache Lounge never made available any Win64 VC9 binaries for
-Apache 2.4. This means that technically there is no combination
-available for correctly running mod_wsgi with a Win64 VC9 version of
-Python 2.6 or 2.7.
-
-History shows that users simply don't want to accept this and don't want to
-understand that mixing VC9 and VC10 binaries are not guaranteed to work.
-
-The specific issue is that if certain data structures are passed between
-VC9 and VC10 code, then the application could crash as the data structure
-layouts for each variant may not be compatible.
-
-As it happens the interface between Apache and Python via mod_wsgi is very
-minimal and so it is possible that there are no instances of incompatible
-data structures being passed across the ABI boundary, but that cannot be
-guaranteed.
-
-So because Apache Lounge is no longer making available any VC9 versions of
-Apache, the following binaries are still provided. Because they are mixing
-binaries using different ABIs, they may or may not work for your particular
-cirumstances. You are still welcome to try, but there is no support for
-using this combination.
-
-* Apache24-win64-VC10/modules/mod_wsgi-py26-VC9.so
-* Apache24-win64-VC10/modules/mod_wsgi-py27-VC9.so
-
-Note that no binaries for Python 3.2 are provided due to it being an older
-version in the 3.X line, but also because a Win64 VC9 version of it does
-crash a Win64 VC10 version of Apache 2.4 on startup. This shows how
-arbitrary compatibility is when you start mixing binaries built against
-different ABIs. You have been warned.
-
-Compiling from source code
---------------------------
-
-If you need to compile from source code because you are using a different
-Apache distribution or a different Python distribution, you will need to
-have installed the appropriate Microsoft C/C++ compiler. You cannot simply
-use any Microsoft C/C++ compiler you might have.
-
-The details on where the Microsoft C/C++ compilers are available from are
-given below.
-
-Python 2.6, 2.7 (32 Bit Only)
-+++++++++++++++++++++++++++++
-
-Use the latest Python 2.6 or 2.7 binary available from the PSF:
-
-* https://www.python.org/downloads/release/python-279/
-
-You must use the 32 bit version which is labelled as:
-
-* Windows x86 MSI installer
-
-Python 2.6 and 2.7 are compiled with the Microsoft C/C++ compiler from
-Visual Studio 2008. This is referred to as being compiled for VC9.
-
-You must therefore use a version of Apache compiled for VC9.
-
-For the Microsoft C/C++ compiler, you need to download it from Microsoft.
-
-* http://www.microsoft.com/en-us/download/details.aspx?id=44266
-
-This can compile both 32 bit and 64 bit binaries.
-
-Python 2.6, 2.7 (64 Bit Only)
-+++++++++++++++++++++++++++++
-
-Use the latest Python 2.6 or 2.7 binary available from the PSF:
-
-* https://www.python.org/downloads/
-
-You must use the 64 bit version which is labelled as:
-
-* Windows x86-64 MSI installer
-
-Python 2.6 and 2.7 are compiled with the Microsoft C/C++ compiler from
-Visual Studio 2008. This is referred to as being compiled for VC9.
-
-You must therefore use a version of Apache compiled for VC9.
-
-For the Microsoft C/C++ compiler, you need to download it from Microsoft.
-
-* http://www.microsoft.com/en-us/download/details.aspx?id=44266
-
-This can compile both 32 bit and 64 bit binaries.
-
-Python 3.3, 3.4 (32 Bit)
-++++++++++++++++++++++++
-
-Use the latest Python 3.3 or 3.4 binary available from the PSF:
-
-* https://www.python.org/downloads/
-
-You must use the 32 bit version which is labelled as:
-
-* Windows x86 MSI installer
-
-Python 3.3 and 3.4 are compiled with the Microsoft C/C++ compiler from
-Visual Studio 2010. This is referred to as being compiled for VC10.
-
-You must therefore use a version of Apache compiled for VC10.
-
-For the Microsoft C/C++ compiler, you need to download it from Microsoft.
-
-* http://www.visualstudio.com/downloads/download-visual-studio-vs#DownloadFamilies_4
-
-Use the one labelled as:
-
-* Visual C++ 2010 Express
-
-This version of the Microsoft C/C++ compiler can only compile 32 bit binaries.
-
-Python 3.3, 3.4 (64 Bit)
-++++++++++++++++++++++++
-
-Use the latest Python 3.3 or 3.4 binary available from the PSF:
-
-* https://www.python.org/downloads/
-
-You must use the 64 bit version which is labelled as:
-
-* Windows x86-64 MSI installer
-
-Python 3.3 and 3.4 are compiled with the Microsoft C/C++ compiler from
-Visual Studio 2010. This is referred to as being compiled for VC10.
-
-You must therefore use a version of Apache compiled for VC10.
-
-For the Microsoft C/C++ compiler, you need to download it from Microsoft.
-
-* http://www.microsoft.com/en-us/download/details.aspx?id=8279
-
-This is different to the Visual C++ 2010 Express above which could only
-compile 32 bit binaries. This version can instead compile 64 bit binaries.
-
-Triggering the build
-+++++++++++++++++++++
-
-Once Python, Apache and the appropriate Microsoft C/C++ is installed, start
-up the Visual Studio 2008/2010 or Windows 7.1 SDK Command Prompt window
-corresponding to the version of the Microsoft C/C++ compiler required for
-your Python version. Make your way to this directory. You then need to do:
-
-1. Find the appropriate makefile in the directory for your combination
-   of Apache and Python.
-2. Edit the makefile and set the path to where you installed both Apache
-   and Python.
-3. Run ``nmake -f apXYpyXY-winNN-VC?.mk clean``. Substitute 'XY' in each
-   case for the version of Apache and Python being used. Substitute 'NN'
-   with either '32' or '64' and substitute '?' with '9' or '10'.
-4. Run ``nmake -f apXYpyXY-winNN-VC?.mk``. This will build mod_wsgi.
-5. Run ``nmake -f apXYpyXY-winNN-VC?.mk install``. This will install the
-   mod_wsgi module into the modules directory of your Apache installation.
-6. Add the ``LoadModule`` line to the Apache configuration which was
-   displayed when the ``install`` target was run.
-7. Edit the Apache configuration as covered in mod_wsgi documentation or
-   otherwise to have mod_wsgi host your WSGI application.
-
-Other build scripts do exist in this directory but they are to allow bulk
-compilation of all combinations in one go and wouldn't generally be of
-interest. They require all possible Apache and Python versions to be
-available as well as all required Microsoft C/C++ compiler. You should
-therefore stick to just the makefile you need.
diff --git a/win32/ap22py26-win32-VC9.mk b/win32/ap22py26-win32-VC9.mk
deleted file mode 100644
index 7fd48f8..0000000
--- a/win32/ap22py26-win32-VC9.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache22-win32-VC9
-
-PYTHON_ROOTDIR = c:\Python26-win32-VC9
-PYTHON_VERSION = 26
-
-include common-VC9.mk
-
diff --git a/win32/ap22py27-win32-VC9.mk b/win32/ap22py27-win32-VC9.mk
deleted file mode 100644
index c494dfe..0000000
--- a/win32/ap22py27-win32-VC9.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache22-win32-VC9
-
-PYTHON_ROOTDIR = c:\Python27-win32-VC9
-PYTHON_VERSION = 27
-
-include common-VC9.mk
-
diff --git a/win32/ap22py32-win32-VC9.mk b/win32/ap22py32-win32-VC9.mk
deleted file mode 100644
index 7613bb4..0000000
--- a/win32/ap22py32-win32-VC9.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache22-win32-VC9
-
-PYTHON_ROOTDIR = c:\Python32-win32-VC9
-PYTHON_VERSION = 32
-
-include common-VC9.mk
-
diff --git a/win32/ap24py26-win32-VC9.mk b/win32/ap24py26-win32-VC9.mk
deleted file mode 100644
index 218bc56..0000000
--- a/win32/ap24py26-win32-VC9.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache24-win32-VC9
-
-PYTHON_ROOTDIR = c:\Python26-win32-VC9
-PYTHON_VERSION = 26
-
-include common-VC9.mk
-
diff --git a/win32/ap24py26-win64-VC9.mk b/win32/ap24py26-win64-VC9.mk
deleted file mode 100644
index 0b90ef0..0000000
--- a/win32/ap24py26-win64-VC9.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache24-win64-VC10
-
-PYTHON_ROOTDIR = c:\Python26-win64-VC9
-PYTHON_VERSION = 26
-
-include common-VC9.mk
-
diff --git a/win32/ap24py27-win32-VC9.mk b/win32/ap24py27-win32-VC9.mk
deleted file mode 100644
index 848513e..0000000
--- a/win32/ap24py27-win32-VC9.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache24-win32-VC9
-
-PYTHON_ROOTDIR = c:\Python27-win32-VC9
-PYTHON_VERSION = 27
-
-include common-VC9.mk
-
diff --git a/win32/ap24py27-win64-VC9.mk b/win32/ap24py27-win64-VC9.mk
deleted file mode 100644
index c5a6b8e..0000000
--- a/win32/ap24py27-win64-VC9.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache24-win64-VC10
-
-PYTHON_ROOTDIR = c:\Python27-win64-VC9
-PYTHON_VERSION = 27
-
-include common-VC9.mk
-
diff --git a/win32/ap24py32-win32-VC9.mk b/win32/ap24py32-win32-VC9.mk
deleted file mode 100644
index 2202de9..0000000
--- a/win32/ap24py32-win32-VC9.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache24-win32-VC9
-
-PYTHON_ROOTDIR = c:\Python32-win32-VC9
-PYTHON_VERSION = 32
-
-include common-VC9.mk
-
diff --git a/win32/ap24py32-win64-VC9.mk b/win32/ap24py32-win64-VC9.mk
deleted file mode 100644
index f97470f..0000000
--- a/win32/ap24py32-win64-VC9.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache24-win64-VC10
-
-PYTHON_ROOTDIR = c:\Python32-win64-VC9
-PYTHON_VERSION = 32
-
-include common-VC9.mk
-
diff --git a/win32/ap24py33-win32-VC10.mk b/win32/ap24py33-win32-VC10.mk
deleted file mode 100644
index 3270bbd..0000000
--- a/win32/ap24py33-win32-VC10.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache24-win32-VC10
-
-PYTHON_ROOTDIR = c:\Python33-win32-VC10
-PYTHON_VERSION = 33
-
-include common-VC10.mk
-
diff --git a/win32/ap24py33-win64-VC10.mk b/win32/ap24py33-win64-VC10.mk
deleted file mode 100644
index 10d6ec8..0000000
--- a/win32/ap24py33-win64-VC10.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache24-win64-VC10
-
-PYTHON_ROOTDIR = c:\Python33-win64-VC10
-PYTHON_VERSION = 33
-
-include common-VC10.mk
-
diff --git a/win32/ap24py34-win32-VC10.mk b/win32/ap24py34-win32-VC10.mk
deleted file mode 100644
index 09d0f68..0000000
--- a/win32/ap24py34-win32-VC10.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache24-win32-VC10
-
-PYTHON_ROOTDIR = c:\Python34-win32-VC10
-PYTHON_VERSION = 34
-
-include common-VC10.mk
-
diff --git a/win32/ap24py34-win64-VC10.mk b/win32/ap24py34-win64-VC10.mk
deleted file mode 100644
index 5f5a7ec..0000000
--- a/win32/ap24py34-win64-VC10.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-APACHE_ROOTDIR = c:\Apache24-win64-VC10
-
-PYTHON_ROOTDIR = c:\Python34-win64-VC10
-PYTHON_VERSION = 34
-
-include common-VC10.mk
-
diff --git a/win32/build-all.sh b/win32/build-all.sh
deleted file mode 100644
index 37a859c..0000000
--- a/win32/build-all.sh
+++ /dev/null
@@ -1,23 +0,0 @@
-set -x
-
-rm -f /c/Apache*/modules/mod_wsgi-*.so
-
-VERSION=`grep MOD_WSGI_VERSION_STRING ../src/server/wsgi_version.h \
-    | sed -e 's/^[^"]*"//' -e 's/".*$//'`
-
-TARGET=mod_wsgi-windows-$VERSION.tar.gz
-
-rm -f $TARGET
-
-NEED_VCVARSALL=1
-export NEED_VCVARSALL
-
-$COMSPEC /c build-win32-VC9.bat
-$COMSPEC /c build-win64-VC9.bat
-$COMSPEC /c build-win32-VC10.bat
-$COMSPEC /c build-win64-VC10.bat
-
-ls /c/Apache*/modules/mod_wsgi-*.so
-
-(cd /c/; tar -c -v -z -f - --transform "s%^%mod_wsgi-windows-$VERSION/%" \
-    Apache*/modules/mod_wsgi-*.so) > $TARGET
diff --git a/win32/build-win32-VC10.bat b/win32/build-win32-VC10.bat
deleted file mode 100644
index 7d87aad..0000000
--- a/win32/build-win32-VC10.bat
+++ /dev/null
@@ -1,12 +0,0 @@
-IF DEFINED NEED_VCVARSALL (
-    SET "PATH=%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC"
-    CALL vcvarsall.bat x86
-)
-
-nmake -f common-VC10.mk clean
-nmake -f ap24py33-win32-VC10.mk install
-
-nmake -f common-VC10.mk clean
-nmake -f ap24py34-win32-VC10.mk install
-
-nmake -f common-VC10.mk clean
diff --git a/win32/build-win32-VC9.bat b/win32/build-win32-VC9.bat
deleted file mode 100644
index 595ce79..0000000
--- a/win32/build-win32-VC9.bat
+++ /dev/null
@@ -1,24 +0,0 @@
-IF DEFINED NEED_VCVARSALL (
-    SET "PATH=%PATH%;%LOCALAPPDATA%\Programs\Common\Microsoft\Visual C++ for Python\9.0"
-    CALL vcvarsall.bat x86
-)
-
-nmake -f common-VC9.mk clean
-nmake -f ap22py26-win32-VC9.mk install
-
-nmake -f common-VC9.mk clean
-nmake -f ap22py27-win32-VC9.mk install
-
-REM nmake -f common-VC9.mk clean
-REM nmake -f ap22py32-win32-VC9.mk install
-
-nmake -f common-VC9.mk clean
-nmake -f ap24py26-win32-VC9.mk install
-
-nmake -f common-VC9.mk clean
-nmake -f ap24py27-win32-VC9.mk install
-
-REM nmake -f common-VC9.mk clean
-REM nmake -f ap24py32-win32-VC9.mk install
-
-nmake -f common-VC9.mk clean
diff --git a/win32/build-win64-VC10.bat b/win32/build-win64-VC10.bat
deleted file mode 100644
index b934c50..0000000
--- a/win32/build-win64-VC10.bat
+++ /dev/null
@@ -1,12 +0,0 @@
-IF DEFINED NEED_VCVARSALL (
-    SET "PATH=%PATH%;C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin"
-    CALL SetEnv.cmd
-)
-
-nmake -f common-VC10.mk clean
-nmake -f ap24py33-win64-VC10.mk install
-
-nmake -f common-VC10.mk clean
-nmake -f ap24py34-win64-VC10.mk install
-
-nmake -f common-VC10.mk clean
diff --git a/win32/build-win64-VC9.bat b/win32/build-win64-VC9.bat
deleted file mode 100644
index 8cba2a7..0000000
--- a/win32/build-win64-VC9.bat
+++ /dev/null
@@ -1,15 +0,0 @@
-IF DEFINED NEED_VCVARSALL (
-    SET "PATH=%PATH%;%LOCALAPPDATA%\Programs\Common\Microsoft\Visual C++ for Python\9.0"
-    CALL vcvarsall.bat amd64
-)
-
-nmake -f common-VC9.mk clean
-nmake -f ap24py26-win64-VC9.mk install
-
-nmake -f common-VC9.mk clean
-nmake -f ap24py27-win64-VC9.mk install
-
-REM nmake -f common-VC9.mk clean
-REM nmake -f ap24py32-win64-VC9.mk install
-
-nmake -f common-VC9.mk clean
diff --git a/win32/common-VC10.mk b/win32/common-VC10.mk
deleted file mode 100644
index 3052976..0000000
--- a/win32/common-VC10.mk
+++ /dev/null
@@ -1,53 +0,0 @@
-CPPFLAGS = \
- /DWIN32 \
- /DNDEBUG \
- /I"$(APACHE_ROOTDIR)\include" \
- /I"$(PYTHON_ROOTDIR)\include"
-
-CFLAGS = \
- /MD \
- /GF \
- /Gy \
- /O2 \
- /Wall \
- /Zc:wchar_t \
- /Zc:forScope
-
-LDFLAGS = \
- /link \
- /LIBPATH:$(APACHE_ROOTDIR)\lib \
- /LIBPATH:$(PYTHON_ROOTDIR)\libs \
- /OPT:REF \
- /OPT:ICF=2 \
- /RELEASE \
- /SUBSYSTEM:WINDOWS
-
-LDLIBS = \
- python$(PYTHON_VERSION).lib \
- libhttpd.lib \
- libapr-1.lib \
- libaprutil-1.lib
-
-SRCFILES = ..\src\server\*.c
-
-mod_wsgi.so : $(SRCFILES)
-	cl $(CPPFLAGS) $(CFLAGS) $(SRCFILES) /LD $(LDFLAGS) $(LDLIBS) /OUT:$@
-
-VARIANT = py$(PYTHON_VERSION)-VC10
-
-install : mod_wsgi.so
-	copy $? $(APACHE_ROOTDIR)\modules\mod_wsgi-$(VARIANT).so
-	:
-	:
-	:
-	:
-	: You now need to edit $(APACHE_ROOTDIR)\conf\httpd.conf and add:
-	:
-	:   LoadModule wsgi_module modules/mod_wsgi-$(VARIANT).so
-	:
-	:
-	:
-	:
-
-clean :
-	del *.obj *.so *.so.manifest *.lib *.exp
diff --git a/win32/common-VC9.mk b/win32/common-VC9.mk
deleted file mode 100644
index 4ffafd4..0000000
--- a/win32/common-VC9.mk
+++ /dev/null
@@ -1,54 +0,0 @@
-CPPFLAGS = \
- /DWIN32 \
- /DNDEBUG \
- /I"$(APACHE_ROOTDIR)\include" \
- /I"$(PYTHON_ROOTDIR)\include"
-
-CFLAGS = \
- /MD \
- /GF \
- /Gy \
- /O2 \
- /Wall \
- /Zc:wchar_t \
- /Zc:forScope
-
-LDFLAGS = \
- /link \
- /LIBPATH:$(APACHE_ROOTDIR)\lib \
- /LIBPATH:$(PYTHON_ROOTDIR)\libs \
- /OPT:REF \
- /OPT:ICF=2 \
- /RELEASE \
- /SUBSYSTEM:WINDOWS
-
-LDLIBS = \
- python$(PYTHON_VERSION).lib \
- libhttpd.lib \
- libapr-1.lib \
- libaprutil-1.lib
-
-SRCFILES = ..\src\server\*.c
-
-mod_wsgi.so : $(SRCFILES)
-	cl $(CPPFLAGS) $(CFLAGS) $(SRCFILES) /LD $(LDFLAGS) $(LDLIBS) /OUT:$@
-	mt -manifest $@.manifest -outputresource:$@;2
-
-VARIANT = py$(PYTHON_VERSION)-VC9
-
-install : mod_wsgi.so
-	copy $? $(APACHE_ROOTDIR)\modules\mod_wsgi-$(VARIANT).so
-	:
-	:
-	:
-	:
-	: You now need to edit $(APACHE_ROOTDIR)\conf\httpd.conf and add:
-	:
-	:   LoadModule wsgi_module modules/mod_wsgi-$(VARIANT).so
-	:
-	:
-	:
-	:
-
-clean :
-	del *.obj *.so *.so.manifest *.lib *.exp