![]() |
ActivePerl User Guide |
![]() |
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()
syscall()
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.
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).
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 flock().
Finally, many helpful programs that are available on Windows NT/2000 are not
there on Windows 95. hostname
, for example, is not available on
Windows 95.
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 Windows 95 or Windows 98.
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:
Calls to functions unimplemented in ActivePerl. For a list, see Certain functions don't seem to work on ActivePerl..
Calls to standard library modules or CPAN modules that aren't available on ActivePerl, or that don't work.
system()
or backtick (``) calls to system tools that aren't
available on ActivePerl.
Reading and writing files that may be binary. See Reading from and writing to files mysteriously fails. What's wrong?.
File-system dependent path names and path name parsing. Watch for hard-coded UNIX paths like /usr/lib.
The module or script may require a specific version of Perl or another
module. Watch out for things like require 5.003;
or require
Sockets 1.03;
Check to see if the script or module really requires
the new version.
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. Sometimes the author will be gracious enough to make changes that will let the program run on ActivePerl. If the author won't change the program, ask if you can make the altered version available to other users.
chmod()
is supported in ActivePerl. However, it can only be used
for setting "owner" read/write access. (The "group" and
"other" bits are ignored.)
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/2000 systems using NTFS can also have more specific permissions granted on individual files to users and groups. For builds 300 and above, and the Perl Resource Kit for Win32, you can use the Win32::FileSecurity module to maintain file permissions.
4DOS doesn't recognize the escaped quote on the command line, because all double-quote characters are seen as delimiters for command line parameters. This is one of the few points (if not the only one) where 4DOS doesn't quite match up to COMMAND.COM.
To get around this, you can enter
perl -e "print \"Hello, World\n\""
as
perl -e "print qq(Hello, World\n)"
using Perl's alternative quoting mechanism. The alternative quotes are qq()
for double quotes, q()
for single quotes, qx()
for
backquotes, and qw()
for list quotes. The parentheses can be
substituted for just about anything (like + or | or {} or <> or #), but
that looks weird.
You may get unexpected results when you try to redirect the output of files that use Windows NT/2000's file association feature. You can use PerlApp or pl2bat to convert a Perl script to an executable or a batch file. This should solve any problems you may have with redirection.
Signals are unsupported by the Win32 API. The C Runtime provides crude support for signals, but there are serious caveats, such as inability to die() or exit() from a signal handler. Perl itself does not guarantee that signal handlers will not interrupt critical operations such as memory allocation, which means signal invocation may throw perl internals into disarray. For these reasons, signals are unsupported at this time.
This FAQ was originally assembled and maintained by Evangelo Prodromou. It has been revised and updated by Brian Jepson of O'Reilly and Associates, and David Grove, David Dmytryshyn, and David Sparks of ActiveState.
This FAQ is in the public domain. If you use it, however, please ensure that you give credit to the original authors.
ActivePerl FAQ - Implementation Quirks |