Implementation Quirks


ActivePerl-faq5 - Implementation Quirks


Issues specific to ActivePerl.

Certain functions don't seem to work on ActivePerl.

There are several functions that are unimplemented in the ActivePerl system. Here is a complete list of unimplemented functions:

Functions for processes and process groups

alarm(), getpgrp(), getppid(), getpriority(), setpgrp(), setpriority()

Fetching user and group info

endgrent(), endpwent(), getgrent(), getgrgid(), getgrnam(), getpwent(), getpwnam(), getpwuid(), setgrent(), setpwent()

System V interprocess communication functions

msgctl(), msgget(), msgrcv(), msgsnd(), semctl(), semget(), semop(), shmctl(), shmget(), shmread(), shmwrite()

Functions for filehandles, files, or directories

link(), symlink(), chroot()

Input and output functions


Fetching network info

getnetbyname(), getnetbyaddr(), getnetent(), getprotoent(), getservent(), sethostent(), setnetent(), setprotoent(), setservent(), endhostent(), endnetent(), endprotoent(), endservent(), socketpair()

See the perlport and Win32 documentation pages for more information on the portability of builtin functions in ActivePerl.

The exec function doesn't seem to work under Perl for ISAPI or PerlScript. Why not?

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 exec() function executes a system command and never returns).

What's the history of ActivePerl on Windows?

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.

What's the difference between running ActivePerl on Windows NT versus running it on Windows 95?

There should be little difference between running Perl on the two operating systems. You should watch for the following, though:

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?.

Why don't the examples from the Camel book work?

The Camel book (aka Programming Perl (3rd edition), Wall, 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.

Why don't certain standard library modules work?

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