ActivePerl-faq5 - Implementation Quirks
Issues specific to ActivePerl.
There are several functions that are unimplemented in the ActivePerl system. Here is a complete list of unimplemented functions:
alarm(), getpgrp(), getppid(), getpriority(), setpgrp(), setpriority()
endgrent(), endpwent(), getgrent(), getgrgid(), getgrnam(), getpwent(),
getpwnam(), getpwuid(), setgrent(), setpwent()
msgctl(), msgget(), msgrcv(), msgsnd(), semctl(), semget(), semop(), shmctl(),
shmget(), shmread(), shmwrite()
link(), symlink(), chroot()
getnetbyname(), getnetbyaddr(), getnetent(), getprotoent(), getservent(), sethostent(),
setnetent(), setprotoent(), setservent(), endhostent(), endnetent(), endprotoent(), endservent(),
See the perlport and Win32 documentation pages for more information on the portability of builtin functions in ActivePerl.
Perl for ISAPI and PerlScript share a process space with the web server and
any number of other extensions. As a result, the
exec() function is
unimplemented, because it would cause the web server to terminate (the
function executes a system command and never returns).
At one time, Perl on the Win32 platform was found in two versions, Gurusamy Sarathy's port, and the ActiveState port. The ActiveState port of Perl included such tools as Perl for ISAPI and PerlScript, at the expense of exposing Perl's internals in a slightly different fashion than standard Perl. Sarathy's port featured a high degree of compatibility with standard Perl, which enabled users of Sarathy's port to use many modules that were not compatible with ActiveState Perl.
The oneperl effort brought both ports of Perl together, and ActivePerl is the standard perl distribution for the Win32 system. All modules that can be used on Win32 can be used with this port. You no longer have to worry about whose perl the module is for. Just grab it, compile it (if needed), and use it.
There should be little difference between running Perl on the two operating systems. You should watch for the following, though:
The Win32::NetAdmin, Win32::NetResource, and Win32::EventLog modules will not run on Windows 95.
Some functions that work on Windows NT/2000 reportedly do not work or are
buggy on Windows 95. An example is
Finally, many helpful programs that are available on Windows NT/2000 are not
there on Windows 95.
hostname, for example, is not available on
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 What modules come with the ActivePerl distribution?.
The Camel book (aka Programming Perl (3rd edition), Wall et.al., O'Reilly & Associates 2000) 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 too hard to fiddle with them until they come out correct (see How do I make a UNIX-based script work?).
The Camel and Llama books are good learning tools. However, one of the things you learn as a ActivePerl programmer is how to port UNIX-targeted scripts and modules to ActivePerl.
For better examples of using ActivePerl, you may want to look at the Gecko book, ``Learning Perl on Win32 Systems,'' published by O'Reilly.
With ActivePerl, almost all modules will work with ActivePerl as long as they can be built to run on Win32. The problems that existed with the 3xx versions of Perl for Win32 no longer exist: modules work on Win32, not just this port or that port of Perl for the Win32 platform!
If a module doesn't work, it may be because the functions it uses are specific to UNIX and won't work on Win32, or specific to NT/2000 and won't work on