What you have to do is to tell IIS that when it encounters a file ending in '.cgi' it has to invoke Perl, pass the file to it and send the results to the client that made the request. Invoking Perl can be made in a number of ways, most notably using the 'true' CGI interface or by using a filter. The 'true' CGI interface is much slower because a new process is created for each request, but you won't notice much of a slowdown unless you have tens or hundreds of clients accessin your script. So you can go fo the 'true' CGI if installing for developement purpouses on your own box. IIS of course offers a wealth of configuration options, but you should not probbaly care much about them at this point.

I don't want to write a full tutorial on this subject (there is plenty on the net). More or less, you should launch the Internet Information Services manager, then "Your_machine/Default Web Site/Home Directory/Configuration/Mappings" and then add ".cgi", select the ececutable path for Perl, add "%s %s" to its end, map it on every request type (at least GET and POST).

Another thing: make sure you have logging enabled. On home boxes, IIS runs often with no logs or reduced logs. A full log - one that offers execution times and referrers - will be very useful. Make sure you activate it (see "Your_machine/Default Web Site/Home Directory" and click on Log Visits - see also "Your_machine/Default Web Site/Enable logging" and put it to on, then "Your_machine/Default Web Site/Enable logging/Properties/Extended properties" and select everything).

My .02 euro :-)

There are several good tutorials on CGI here. If I were you, I would check out Ovid's tutorial.

He also has some good lessons here.

May your time with Perl be long and fruitful.

cLive ;-)

IndigoPerl is available at http://www.indigostar.com/indigoperl.htm. IndigoPerl comes with Apache Webserver, and installs Apache as part of the Perl installation process. The result is a system that is pretty easy to develop and test CGI scripts on.

How about something more recent? Apache Perl comes with Apache webserver (ok, it's just activeperl bundled with apache by the apache folks):

http://www.apache.org/dyn/closer.cgi/perl/win32-bin/

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

Edit by tye, change H1 to H3

I would like to attempt to clarify something that is a source of much unfortunate semantic confusion - CGI.

The Common Gateway Interface is (pretty much) a protocol that allows web servers and external apps to communicate with each other. Practically all common web servers can use the CGI protocol.

CGI-scripts/apps are programs that use this protocol w/o a whole lot of extra features. These 'CGI programs' can be very slow, especially under load, because the web server will (generally) spawn a new process to handle each CGI request, no matter if your app is written in Perl, Python, C, Java, whatever. Perl is simply an especially popular choice for writing 'CGI programs'.

On the other hand, there is CGI the Perl module. This is one of the most popular of many modules that 'wrap' the CGI protocol to make writing 'CGI programs' a lot easier.

Numerous way have been invented to overcome the performance limitations of 'CGI programs', including ASP, servlets, etc. All of them having different ways of avoiding the classic 'CGI program' problem of spawing new processes for each request. Note that Perl has not been left behind in this regard. The Perl-world has mod_perl, FastCGI and probably other modules/apps that attempt to 'embed' a Perl process into Apache servers. Activestate's PerlEx kind of does the same thing for IIS. All of these are rip-snorting fast compared to standard 'CGI programs'.

It's important to note, though, that the use of mod_perl or PerlEx does not necessarily preclude the use of the CGI module or CGI-related modules. The CGI module will just run alot faster w/ mod_perl or PerlEx.

Developing classic 'CGI programs' isn't always a bad idea, despite the wide availability of mod_perl and PerlEx. Some applications will never need the extra performance, and faults in 'CGI programs' won't crash or cause weirdness in your web server.

You have had some good advice here so far. My standard production environment, and that of the majority of the internet it seems - is apache web server with perl or mod_perl on linux servers - but somebody else has the fun job of installing them and maintaining them. My experience of recently setting up a development environment goes like this:

1. Xitami is a nice web-server out of the box, but the SSL implementation is not free - it has a $2500 licence fee.
2. IndigoPerl is nice, it is implemented by a member of the Toronto Perl Mongers and does install and work well. It is a good compact development environment if you don't need to use mod_perl.
3. IIS is a pig and everything seemed to be counter-intuitive. Although I have had an IIS install on my LAN for about 6 years (regularly updated and whatever) I only use it for intranet documents and nothing else.
4. I decided after some considerable installing and uninstalling that none of this could be worse than doing Apache/mod_perl/SSL in Linux. Which I did. There were many problems, but perlmonks and the various mailing lists were a great help over the few days of the installation adventure. ApacheToolbox was a great help and if you go the *nix route then use it at least until you have enough experience to attack the problems confidently.
5. I was not aware of the binary package from Apache for win-32 with all the goodies. If I hadn't switched to Linux then this is probably what I would use.

jdtoronto