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?