[Robert Conner]

Well color me purple, it does work.

Good! How could anything on Windows fail to work ;-)?

I was just so used to seeing the "Zope Ready to handle Requests" message that when it never appeared I just assumed it was not working at all. I've broken Zope on my computer 100 times and always when its broken it does not display "Zope Ready to handle Requests". I won't make any more excuses for myself here, they don't help anything. Man, I'm sorry for the inconvenience.

Not a problem: if one person doesn't understand what they're seeing, then at least a hundred more won't understand it either, and it's very good to have a discussion about it archived on a public mailing list then. FWIW, I don't know why Zope doesn't display anything useful in the console anymore, and I don't even know whether that's unique to Windows.

...

Or another way (something I'd never do in real life, but I guess some people do)

I always run Zope in the console.

So do I, but there's difference: I open a DOS box and type "bin\runzope" myself. What I never do is use the Start menu "shortcut". A DOS box you open yourself stays visible even if Zope dies ungracefully, and after the first time you type "bin\runzope" you only have to hit two keys (up-arrow ENTER) to start it again.

The only reason I even use the Windows version is for development. As far as I can tell the fastest way for me to stop and restart Zope if to close down the command window and then start it back up again. When I develop, I restart Zope all the freeking time, so the faster the restart, the better.

Doesn't the ZMI have a "restart Zope" button? If you open your own DOS box, then a sloppy all-keyboard restart dance is "Ctrl+Break up-arrow ENTER", and a careful all-keyboard restart dance is "Ctrl+C up-arrow ENTER". The latter gives Zope a chance to close files gracefully, but by the same token it takes longer for Zope to shut down. "Ctrl+Break" kills the process instantly (and runs some risk of leaving data in I/O buffers without writing it to disk).