What evidence do you have that this is *the* issue preventing people from installing perl on Windows? My experience is in fact that that is a non-issue. What evidence do you have that this same non-issue is the reason that C, Python, Scheme, Fortran and Intercal are not commonly used for "internet apps". Please explain how this does not contradict the fact that major "internet apps" like exim, apache, bind, openssh and INN are all written in C and mailman in Python.

Fact 1: Apache / *nix is a far more common hosting platform than IIS / Windows

Fact 2: Perl comes automatically installed on most if not all *nix and *nix-like OSes

Opinion: It looks to me like you're talking nonsense. You say you sell perl scripts, and that perl scripts running on IIS are running into infinite loops and causing problems. Would these scripts happen to be yours? If so (and this is conjecture - not fact) then the problem would not seem to be perl or IIS.

This is the reason why the problem isn't being resolved. Ignorance and denial in the Perl community

DrHyd:
"Downvoted due to being Just Plain Wrong." - Likewise.
"What evidence do you have that this is *the* issue preventing people from installing perl on Windows?" - 5 years experience talking to many different windows hosts about why they won't install Perl.
Feel free to contact them yourself. Meeting many people and E-business networking events and being asked about why Perl is such a problem on Win32. To these people this is a big deal, and why they do not choose Perl. Business people not choosing Perl is a problem.
"internet apps" - As in website applications. Scripts. Bind, Apache are obviously done in C. But last time I looked Apache wasn't a script that ran on apache - get the drift? Same goes for Bind, etc. What percentage of CGI Scripts are coded in C & Python put together? I'll give you a clue <1%


Hostyle:
quote - "Fact 1: Apache / *nix is a far more common hosting platform than IIS / Windows
Fact 2: Perl comes automatically installed on most if not all *nix and *nix-like OSes"
Trees are also green and the sky is blue. This is irrelevent to the issue.
No MY scripts are not running into infinate loops on IIS. I heavily test all my scripts and include failsafes on all routines that might possibly cause an infinite loop if errourness data is input.
YES there are hundreds a new Perl programmers
YES their scripts will create infinate loops while they are still learning and debugging.
YES there are thousands of Perl scripts avilable to download and install
YES many of this scripst will have bugs
YES some of them will generate infinate loops
YES this will cause the outlined problems with Perl on Win32
NO I'm not saying this isn't an error in their perl scripts causing the infinite loops
NO this doesn't stop the fact that it's happening, and that it will continue to happen until some failsafe is put in place.


Here is some sample code for those of you that want to see this error in action. It's purposefully designed to create the problem



alarm 30;
$|=1;

## Choose operating system

BEGIN {
  if (($^O eq 'MSWin32') || defined($ENV{'OS'})) {
    $operatingsystem = 0;
    $operatingsystemoldnt = 0;
    $systempath = "$ENV{'PATH_TRANSLATED'}";
    $systempath =~ s/(\\[a-z0-9]*\.pl)$//g;
    unless ($systempath) {
      $systempath = "$ENV{'SCRIPT_FILENAME'}";
      $systempath =~ s/(\/[a-z0-9]*\.pl)$//g;
    } ## End unless
#    $operatingsystemoldnt = 1;
#    $slash = '\\';
    $slash = '/';
  } ## End if
  else {
    $operatingsystem = 1;
    $systempath = "$ENV{'SCRIPT_FILENAME'}";
    $systempath =~ s/(\/[a-z0-9]*\.pl)$//g;
    if ($systempath =~ /cgiwrap/) {
      $systempath = "$ENV{'PATH_TRANSLATED'}";
      $systempath =~ s/(\/[a-z0-9]*\.pl)$//g;
    } ## End if
    $slash = '/';
  } ## End else
## $systempath = "systempath to your folder"; ## Enter the correct val
+ue and un-comment this if you are having system path detection proble
+ms
  push (@INC, "$systempath");
} ## End BEGI

print "Content-type:text/html\n\n";

## Directory navigator


$directorypath = "c:/";
my @directories;
my @variables;
my $directoryname = 1;
push (@directories,"$directorypath");

until ($directoryname eq "rerasfsdfsdfsdf") {
  $directoryname = shift (@directories);
  chomp($directoryname);
 opendir(CURRENTDIR, "$directoryname");
  @dirfiles = readdir (CURRENTDIR);
 closedir(CURRENTDIR);
 foreach $filename (@dirfiles) {
  chomp($filename);
  unless ($filename eq "." || $filename eq "..") {
    if (-d "$directoryname/$filename") {
      push (@directories,"$directoryname/$filename");
      print "$directoryname/$filename\n";
    } ## End if
  } ## End unless
 } ## End loop
} ## End loop
[download]

Save and run the script in your browser from IIS, not form the command prompt. Then when it's eating up your CPU quickly open task manager and try to end the process. You'll see that it won't let you (on win2000 at least). The app should die after 30 seconds from the Alarm() setting at the top. Now if you want to see it take down IIS, remove the Alarm() code, run from your browser and click the stop button. Viola IIS is crippled, this is where most WinDose hosts will reach for the reset switch. And heres the best bit, when the machine reboots and is available again the happless user, wondering what the problem is hit's the refresh button and viola, IIS is crippled. After several reboots and very pissed off WinDose hosting company understandable says "I don't get this problem with ASP or PHP, I'm going to remove Perl, it's not worth the effort."

If you can't admit this problem then your either ignoreant, or plain stupid.

Is this a problem with the Perl interpreter? Not really, but Perl is the mechanism which allows this problem to exist, and so is responsible for providing the win32 community with a failsafe solution. When the administrator opens up Task manager to see which programs have gone mad, and are taking down the machine, they don't see "Stupid newbie script error", or "badly made script" what the see is "PERL.EXE". So what program do you think they blame?

Is this a problem with the Perl interpreter? Not really, but Perl is the mechanism which allows this problem to exist

No. Using the CGI with IIS is the mechanism which allows this problem to exist. If you were to create a CGI program with equivalent resource usage in Visual Basic, C, Windows Batch files or infact PHP you would experience the same results. Please feel free to try this yourself. Note that the Microsoft documentation on tuning IIS alludes to the problem, but does not once mention Perl. No-one is denying anything here but instead trying to point out you are barking up the wrong tree.

And before you start on the fact that ASP or PHP don't appear to experience the same problem you probably should know that PHP (when run as an ISAPI extension and not as CGI ) and ASP run in-process to IIS and do not require IIS to spawn a new process. You might also care to try your example in a PerlScript ASP page to see what might happen.

/J\

Please correct me if I'm wrong, but what you appear to be saying is this: "because some newbie perl coders are putting buggy code onto live sites, and thus bringing those webservers to a halt, perl needs to be changed". That makes absolutely no sense to me(update), in particular when its a problem that only manifests itself on IIS - basically, its not a perl problem.(/update)

BTW I don't appear to have any problem whatsoever terminating these processes in taskmgr with or without the alarm() and however long I leave it and however many I have running at no point does the server become unuseable. That you are seeing something different would point to a badly configured server.

/J\

To give a little more evidence. This problem used to exist for PHP as well, take a look at this post:-
http://www.phpbuilder.com/lists/php3-list/199905/1278.php

Rather than ignoreing this issue, blaming new or bad programmers (as if advanced programmers don't make mistakes from time to time), etc. The PHP people did something about it back in version 3. Take a look at the responces, such as:-
http://www.phpbuilder.com/lists/php3-list/199905/1280.php
and
http://www.phpbuilder.com/lists/php3-list/199905/1293.php

If I wasn't such an avid perl fan I might be tempted to php, but no way.

When someone uploads a script that causes an Iloop on my server I run 'top' and kill it. If it's the middle of the night my server will be running like a slug until i wake up and kill the run away scripts. I'd rather not have to do this. It's no where near the problem you get on Win32, but it's still an issue. However on Linux you could argue this is a issue with apache not killing the cgi process it started when the browser stop button is pressed. Should my next stop be apache? Either way, the simplest solution would be perl having some sort of safeguard to prevent this.

I'm not saying Perl should never run for more than a fixed number of seconds. Of course perl scripts should do this. But when perl is launched from Apache or IIS it should have a set timeout. One that can't be broken by the users hitting his stop or refresh button.