- Wrong branch

      - Collector #2002: fixed broken 'ls -R' functionality (didn't
        recurse properly subclasses of OFS.Folder)

- I must be blind

- Another dependency

- Fetch the dependencies with curl

InnoSetup 4 CAN NO LONGER BE USED.

Besides that there's no future in relying on obsolete
versions of tools, version 5 introduced a vastly easier
way to manage the custom dialog pages Zope wants.  That
allowed getting rid of about 60 lines of inscrutable
Pascal code.  Of course the code that replaces them is also
inscrutable, but there's about 60 fewer lines of it to
torture future generations ;-).

This matches the set of files converted by the Z4I
Windows installer now, except omits .csv files (because
there aren't any of those in the Zope tree).

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.