The build-the-Windows-installer dance used to use it.

Don't know why it was hidden before, but can't think of a
reason, and the lack of makefile output showing its creation
just confused the heck out of me for 10 minutes ;-).

The functional tests don't even try to run, but at least this
exercises 6724 of the unit tests.

Someone who understands how Zope3 testing was changed to work
from a zpkgtools-based install should be able to figure out
how to improve this.

the password, and to stick on this screen until the passwords match.
I wrote this for a now-old Zope Z4I Windows installer, but there's
surely no reason to keep it secret ;-).

Also fiddled all the Pascal code to give it uniform indentation.

The build-the-installer process now completes, and running
the installer creates something that may or may not be a
working Zope.  It starts fine as a Windows Service, and at
least "looks like a Zope" ;-)

Nothing in the build-the-Windows-installer process here
uses anything in the root of the inst/ directory anymore.
Instead the WinBuilders zope.mk builds Zope all by itself,
using the Python created by python.mk.  Everything these
used to use in the root of the inst/ directory was so out
of whack with current reality that there was no point even
trying to reverse-engineer what it thought it was doing.

Note that comments in the code highlight what look like
bugs in distutils, and in the Windows xcopy command (that
last one took hours to track down -- sheesh).

Convert line ends on more kinds of files.

heavily used utility variables that call out to a shell.

Removed ancient info about wrestling with Win98SE.

It doesn't come installed on all Windows systems, so the
Zope installer needs to supply it.
It should NOT be distributed "randomly".  Tim Peters has
a valid Visual Studio .NET 2003 license, and because that
product is used to compile the C code in Zope, Tim has the
right to redistribute the C runtime DLL.  When someone else
builds a Zope installer, they need to have a valid MS
VC license too (or remove msvcr71.dll from the distribution).

switch to Python 2.4.2.

The code for this doesn't exist here yet, but it's the same
approach the ZRS 1.5 Windows installer took, so there's
some hope it will work here eventually too ;-).

The makefile has to know the actual name.

displayed by the installer.

This is a branch from the 2.9 tag to try to repair that.
Changes here will be limited to the WinBuilder stuff.

r21753 | efge | 2006-01-06 18:58:06 +0100 (Fri, 06 Jan 2006)
Fix cleanup of five:traversable.

r21752 | regebro | 2006-01-06 18:51:19 +0100 (Fri, 06 Jan 2006)
If one class was set to have a localsite hook twice, removing the hook
would be attempted twice during the cleanup of unit tests, and the tests
would fail.

      - Collector #1939: When running as a service, Zope could
        potentially collect too much log output filling the NT Event
        Log. When that happened, a 'print' during exception handling
        would cause an IOError in the restart code causing the service
        not to restart automatically.

        Problem is that a service/pythonw.exe process *always* has an
        invalid sys.stdout.  But due to the magic of buffering, small
        print statements would not fail - but once the file actually
        got written to, the error happened.  Never a problem when
        debugging, as the process has a console, and hence a valid
        stdout.

and http://mail.zope.org/pipermail/zope-dev/2005-December/026236.html from the Five
repository:

Log message for r21321:
  Explain what this test does and fix misleading and risky usage of pprint

Log message for r21322:
  Fix this test and re-enable it

Log message for r21325:
  Add changes entry for some recently fixed bug
  update Five 1.2 changes history
  bump version number after 1.3c "release"

the 'charset' field is automatically if not specified by the
application. The 'charset' is determined by the content-type header
specified by the application (if available) or from the
zpublisher_default_encoding value as configured in etc/zope.conf

level at which conflict errors (which are normally retried
automatically) are logged. The default is 'info'.

This doesn't interfere with the error_log site object which copies
non-retried conflict errors the the error log at level 'error'.