Yikes! I just got around to reading the cookbook, and I didn't have to do most of that stuff to get Twiki running on NT or Win2k!

I did finally find I was happiest using cygwin stuff for grep, fgrep, ls, rcs etc., but I didn't have to actually set up to run cygwin as described with mount points etc, nor have I found it necessary to relock anything. I've also subsequently found "native" solutions for most of the utilities - in WinCVS?! It ships with diff, diff3 and rcs exe's, leaving only *grep and ls to be found as exe's and they do exist.

I would also like to demur about one claim that cmd.exe is used to run perl cgi scripts. I don't believe this is the case: I think perl.exe is invoked directly by Apache. I think this is true for python.exe too. (You can use a .bat file with cmd.exe as a cgi, but you don't have to.)

I just got Apache 2.0.32 running on Win2k, and the registry/shebang line option is no longer supported: it's shebang all the way and the shebang executable must end in ".exe" as in "#! j:/perl/bin/perl.exe".

-- DavidLeBlanc - 08 Mar 2002

Oops, I should have mentioned that rcs itself isn't part of cygwin's standard download, nor is in the package installer GUI. There is a version of rcs made to be built on cygwin and you can find it via the cygwin site - a regular distribution of rcs doesn't compile on cygwin I found the hard way. I have mentioned this on another post to TWiki, but I don't recall where.

re: rcs -- I just installed it yesterday via the cygwin GUI installer (2.218.2.9), and it appears to work fine. -- ChrisWolske - 07 Jun 2002

About cygwin: you don't have to actually have cygwin running to use most cygwin tools as long as the requisite bin directory is in the path for the exe and cygwin.dll you want to use. I remain far less then convinced that you need cygwin installed at all, and if twiki.org would allow some storage space, a utilities distribution could be put together for windows folk that would be far smaller then 10-11mb cygwin binary d/l.

As for editors, I have never had a problem I could trace to cr/lf vs. lf in config files, but if you really want to maintain the same state of your eol's, then I unreservedly recommend SciTE (aka WSciTE) available at http://www.scintilla.org/SciTE.html. It's free, comes with source and knows how to colorize more languages then the tower of babble, including apache conf files, perl, python, C, C++, ruby, lua... etc. etc. etc. AFAIK, it honors line endings and if you somehow get them muxed up, has menu items to quickly canonaclize them to your prefered flavor.

-- DavidLeBlanc - 08 Mar 2002

I'm glad you found a simpler way of doing things, but I found that re-locking was essential (did you try editing the delivered topics, or were you somehow running as 'nobody'?), and the binary mount points were also essential.

It seems that you built RCS from source, which is fairly painful. This is no longer necessary, as rcs is now part of the standard installation packages for Cygwin - please see the cookbook for details.

I realise you can do a minimal install of Cygwin, but copying files and DLLs is much more error-prone than just doing a Cygwin install - and the latter is easily upgraded as Cygwin bugs are fixed. If someone would like to try a minimal install (i.e. exactly which Cygwin packages are needed) I will include some details - however, the Perl install requires gcc, make, and many other Unix tools, so I doubt if a minimal install would be very small (unless you manually install the required Perl modules without the cpan tool).

There is a definite trade-off between ease of installation and download size, and since so many people have had problems with Windows installations of TWiki, I've aimed for the former - Cygwin lets you install everything except Apache in a single process, which simplifies things a great deal. If you want a minimal install, you can go the route of using Win32 binaries plus ActivePerl, since its ppm module installer doesn't require Unix tools.

-- RichardDonkin - 13 Mar 2002

No real point in getting into a big discussion about this... You can do a binary only download and install of Cygwin/Perl etc. I think this is an avenue attractive to many people on Windows because the availablity of and/or knowledge of how to use a C/C++ compiler isn't as prevelant as it is on Unix/Linux/BSD. (It doesn't help that GCC isn't well documented in my experience.) The download source/compile/go mode that's common to Linux/Unix isn't at all common on Windows.

For all of the CygWin command line tools i'm familiar with, and in particular, grep, awk, ls, diff and rcs, require nothing more then the cygwin dll to operate. They can do this with or without a CygWin compiled Perl or Bash etc. AFAIK, even Bash will run bare on Windows too.

As for Perl, neither CygWin or ActiveState are the only avenues available to obtaining a Windows Binary. I believe that Perl people make binaries available for Windows from a number of locations.

Based on your mention of PPM etc., I think you have this vision of Windows people being able or willing to download, compile and install arbitrary Perl modules etc. I think this is far from a plausible scenario. I regret to say this, but most Windows people, like most Mac people are appliance users, and they want what they need to come in one box without excessive fuss and bother. If that isn't possible, then I think the numbers of potential customers are reduced. (This doesn't even begin to address the aversion (justified or otherwise) towards GPL software by Windows people, nor Microsoft's recent prohibition in their licensing of using Microsoft compiler products to compile GPL, Apache, Sun and other open source licensed software.)

WRT to PPM and CPAN, I have never had as much luck using PPM as CPAN to download and install Perl modules. It's also worth noting that both PPM and CPAN require the presence of a C/C++ compiler to install many modules ("native" ports require VCC for example).

You might argue that the intended audience, at least those actually installing the product, are more technically savy then the typical Windows User. Well, they're somewhat more savy, but most do not approach the skill level of a typical Unix/Linux sysadmin who frequently have at least some programming background. On Windows, even writing scripts isn't the commonplace activity that it is on Linux/Unix. Windows sysadmins are skilled at installing and managing Microsoft and Microsoft compatible software which generally has less user settable features then their Linux/Unix counterparts and mostly offer GUI based administration tools as well.

IMO, if you want to get mindshare from the sorts of organizations that aren't technically oriented and who I think could really benefit from TWiki (social organizations, charities, marketing organizations etc. i.e. group-oriented organizations), you need someone to offer a drop-in, turnkey, GUI/web administered solution that includes all the things that TWiki depends on, including Perl, Apache, RCS and utilities. (N.B. I don't think a business is going to be all that dismayed any more by a multi-megabyte download, and if they are, then there are places that will burn a CD to order for a nominal fee!) This is the approach taken by the Zope folks, and that's even with Python being already a "drop-in" tool suite - Zope includes it's own Python interpreter etc. (I just installed Zope again last evening and my biggest challenge was choosing the directory I wanted it in and even the Zope people don't get that right since they offer to install in a directory path containing a space!)

Finally, to those Windows people who are likely to read this: obviously, since you're here, you're not one of the typical Windows folk described above. You're enough of a geek or are motivated enough to cope with what it takes to get TWiki up and running on Windows! A relative few of us on Windows actually enjoy fooling with compiler options, settings, configurations and paths

Peace,

-- DavidLeBlanc - 13 Mar 2002

The cookbook does of course do a binary only download/install of Cygwin, Perl, etc. The use of GCC is only because of the use of the cpan tool, which hides all the gcc stuff, so the lack of knowledge in the Windows user based about using compilers doesn't really apply. As I mentioned, the only point in downloading the various Cygwin packages is to simplify installation - if you would like to do an alternative version of the cookbook that doesn't download so many packages, you are very welcome! PPM didn't require a compiler for the few modules required by TWiki, and worked very well out of the box, so it would probably be a good option for a minimal or non-Cygwin install.

ActivePerl is the currently recommended version of Perl for Win32 - see this perl.com page. Cygwin Perl works well for Cygwin of course, but the 'core Perl' ported to Win32 is obsolete.

As for a point and click installer - the cookbook is not an alternative to this, and the TWikiUnixInstaller work is very important, but it's much easier to write a flexible installation doc than to write an equally flexible installer (particularly since TWiki currently requires source file editing when it's installed). The cookbook is really just establishing the 'base camp', making it a bit easier to write the installer. I'm well aware that most Windows users want a point and click installer, but that's a much bigger piece of work - of course, you are quite free to do that if you prefer

If we can develop some consensus as to the best versions of Apache, Perl, RCS, etc, to use on Windows, and fix some of the TWiki issues, it would be possible to turn the cookbook into an improved version of the TWikiUnixInstaller. However, putting together a bundled TWiki distribution involving all those components is quite a maintenance challenge - who will update the distribution when there's an Apache security fix, or an RCS file corruption fix (as happened recently with Cygwin RCS)?

To get mindshare amongst low-tech-skills organisations, one approach is a TWiki hosting service - the organisation just fills in a web form, and someone sets up a TWiki site behind the scenes. Running an in-house web server of any sort is going to take more skills than can easily be hidden behind an installer/admin tool without a lot of work, IMO.'

One final, and probably controversial, point - having a somewhat complex installation process on Windows is not a wholly bad thing: if installing TWiki became incredibly simple, and a huge new base of TWiki installations appeared, there would be a corresponding flood of very basic questions in the Support web, and I'm not sure that the TWiki community is geared up for that at the moment... However, the installation process can be simplified quite a lot before we get to that point.

-- RichardDonkin - 14 Mar 2002

"yourdomain.com" is now a live url! I suggest changing the examples to use "localhost" and/or 127.0.0.1. I have had the experience with Apache that sometimes it doesn't like "localhost" as domain or server name (t'was with NT, so maybe that had something to do with it), so that's why the loopback address is suggested as an alternative. Might be beneficial to point out DHCP issues too maybe?

I'd also like to point out that not all win2k users have administrator priviledges on their box (some win sysadmins are pretty anal), but that's not a stop to installing Apache, TWiki etc.

-- DavidLeBlanc - 14 Mar 2002

WRT to Apache configuration: changing the documentroot to twiki makes the apache server doc unavailable.

mod_env simply extends the system environment, and all those settings can be put into the system environment using the control panel. This has worked for me either standalone or as a service.

I found that if I do:
Alias /twiki/ "h:/apache/twiki/"
ScriptAlias /twiki "h:/apache/twiki/bin/view"

I can just type "http://localhost/twiki" to start up twiki (this is with the default Apache document root setting). I only recently discovered this trick - before I didn't have the "view" on the end of the ScriptAlias and had to add that to the browser line above.

-- DavidLeBlanc - 14 Mar 2002

I'll have to change the examples to http://www.example.com/, which is guaranteed by the IETF to never be allocated! However, this is a fairly minor issue.

'localhost' works fine, and is installed by default. DHCP is outside the scope of the cookbook - most Windows NT and Win2000 environments use WINS or Dynamic DNS, respectively, meaning you can just use the hostname.

What would be useful is some more specific comments - e.g. if the user is not the administrator, here are the following additional steps that must be taken. I'm more interested in things that fix specific problems than 'here's another way we could do the install'.... For example, ptting things into the system environment is an option, but using the Apache config makes this a cut and paste operation, removing a source of errors. Also, when running as a service, I believe the System environment is not used (or at least some people have had problems).

I'm aware of the way the current setup removes access to the Apache docs etc, but I was focusing on just getting the basic TWiki working. I should fix that at some point - specific changes to the cookbook are always welcome.

-- RichardDonkin - 14 Mar 2002