There are several functions that are unimplemented in the Perl for Win32 system. Primary among these are alarm() and fork(), which are used in quite a lot of modules developed for UNIX. Because they're missing in Perl for Win32, you can't use those modules.
Other unimplemented functions include System V IPC functions, UNIX system calls, Berkeley sockets functions that aren't WinSock functions, and some other weird ones. Here's a list, as extracted from unsupported.ntt, the perl script that tests unimplemented functions to make sure they stay that way and don't spontaneously implement themselves:
alarm(), chroot(), fork(), getpgrp(), getppid(), getpriority(),
getpwnam(), getgrnam(), getpwuid(), getgrgid(), getpwent(),
getgrent(), setpwent(), setgrent(), endpwent(), endgrent(), kill(),
link(), msgctl(), msgget(), msgrcv(), msgsnd(), semctl(), semget(),
semop(), setpgrp(), setpriority(), shmctl(), shmget(), shmread(),
shmwrite(), symlink(), syscall(), times(), wait(), waitpid(),
getnetbyname(), getnetbyaddr(), getnetent(), getprotoent(),
getservent(), sethostent(), setnetent(), setprotoent(), setservent(),
endhostent(), endnetent(), endprotoent(), endservent(), socketpair()
Many other functions act in unexpected ways or are poorly implemented. Here is a (definitely non-exhaustive) list:
[Others? -ESP]
Besides not being a UNIX program, PerlIS has the second disadvantage of
sharing a process space with the Web server and any number of other
ISAPI extensions. Because of this, there are further restrictions on
what a Perl script run by PerlIS can and cannot do. Some are built in,
and some are just "bad" things to do.
According to the PerlIS info page, there are two things you can
not/should not do in a Perl script run from PerlIS:
Oh, a whole lot. The standard distribution was developed and is
maintained in a UNIX-centric world, and there are a lot of
OS dependencies built in. Here's a short list of the differences:
Finally, there's a difference in culture. perl is developed and
maintained by the people who use it, and there's a collaborative nature
to the progress of that product. Conversely, Perl for Win32 is de facto
owned by ActiveWare, which has neither the participatory nature of a
loose-knit user-developer community nor the responsiveness of a
commercial software company.
Although Perl for Win32 originally did not run on Windows 95, there
should now be little difference between the two operating systems.
You should watch for the following, though:
[Other differences? -ESP]
If you're worried about using a feature from one or the other, check the
result of the function Win32::IsWinNT() to see what OS you're running
on. See question 9.12.
The Camel book (aka _Programming_Perl_, Wall et.al., O'Reilly &
Associates 1996) was written by UNIX people for, in general, UNIX
people.
Some of the examples in the Camel book will work. Some will not.
If they fail, it's because either the functions used are not available,
the external tools used are not available, or the modules used are
not available. Usually, for small scripts, it's not to hard to fiddle
with them until they come out correct (see question 5.8).
The Camel and Llama books are good learning tools. However, one
of the things you learn as a Perl for Win32 programmer is how to
port UNIX-targeted scripts and modules to Perl for Win32. So,
get used to it.
The Perl motto is "There's More Than One Way To Do It." The Perl
for Win32 motto could be "It's A Good Thing That There's More Than
One Way To Do It, Because Most Of The Ways Don't Work."
Many of the standard library modules don't work for the same reason
that other Perl code doesn't work: the functions aren't implemented,
the external tools aren't present, or modules they depend on aren't
available.
Many of the "standard library" modules that come with the perl 5.00x
standard distribution aren't distributed with the Perl for Win32
distribution because they weren't around for perl 5.001m. So, use'ing
those modules may not even be possible.
See also question 8.2.
First, make extra-super sure that you are using the script or module
in the way it was intended. Many of us are quick to blame the
module, the operating system, or the interpreter when, in reality, it is
our own code that isn't working right.
If you're sure that it's not a problem in your code, the best way to
make a UNIX-based script work is to desk-check it before running it.
Look for some of the following things:
Of course, it should go without saying that for everything you take out
you'll have to put in a work-around.
Once you've worked around UNIX dependencies in the script or module,
try running it through the debugger to see if what you did helps. If
the script or module comes with a ".t" test file, try using that to
test your changed version.
If you _do_ make a change to a UNIX-based script or module, please
let the author know. They will sometimes be gracious enough to make
changes that will let the program run on Perl for Win32. If the author
won't change the program, ask if you can make the altered version
available to other users.
chmod() will execute as expected in Perl for Win32. However, it may
not have the results you want. [Can someone tell me what works and
what doesn't? -ESP]
UNIX-style security for files is not applicable to files on Win32
systems. Win32 systems inherit from DOS four possible "file attributes":
archived (A), read-only (R), hidden (H), and system (S). These can
be checked and set with the Win32::File::Get/SetAttributes().
Windows NT systems using NTFS can also have more specific permissions
granted on individual files to users and groups. In build 110, you
can retrieve and set these by running the CACLS program (type HELP CACLS
at the command line for details). For builds 300 and above, you can
use the Win32::FileSecurity module to maintain file permissions.
5.2. Function Y doesn't seem to work under PerlIS. Why not?
5.3. What's the difference between Perl for Win32 and the standard distribution?
5.4. What's the difference between running Perl for Win32 on Windows NT versus running it on Windows 95?
5.5. Why don't my examples from the Camel book work?
5.6. Why doesn't standard library module Z work?
5.7. How do I make a UNIX-based script work?
5.8. How does the chmod function work on Win32 platforms?