We're getting ready to move to Windows 7 and Server 2008R2. Is my ActivePerl supported on these platforms?
For 5.8, ActivePerl builds 827 or higher have been tested on Windows 7 and Server 2008R2.
For 5.10, ActivePerl builds 1007 or higher have been tested on Windows 7 and Server 2008R2.
For 5.12, ActivePerl builds 1200 or higher have been tested on Windows 7 and Server 2008R2.
All ActivePerl 5.14 builds have been tested on Windows 7 and Server 2008R2.
Whether of not your ActivePerl is supported depends on which product line you are using. Community Edition products are only eligible for installation support, and they become unsupported when a newer version is available, even if the older version remains online for downloading. Business Edition and Enterprise Edition products have different support conditions.
I'm trying to compile a custom module to include in a PerlApp executable. I'm using Visual Studio 2008 to compile the module. The resulting executable will not run on XP machines that do not have the compiler suite installed (a dependency seems to be generated on a C runtime library). Can you tell me what compiler toolchain I should be using to compile the module so I don't generate extra dependencies in the PerlApp executable?
For 32-bit work on 5.18 and newer:
The recommended compiler for building extensions is MinGW and dmake. There are known issues with using MicroSoft compiler toolchains, these versions are not compatible with MicroSoft Compilers.
For 32-bit work on Perl 5.16 and older:
The recommended compilers for building extensions are VC6 and MinGW. nmake from VC6, the free nmake15 download, or dmake (for MinGW) all work as the make tool.
ActivePerl was compiled with VC6 because VC6 is the last VC version that produces code that links against MSVCRT.dll, and MSVCRT.dll is the only runtime which is a standard part of Windows (and not part of a particular C compiler release). The free GCC compiler from MinGW also uses this same runtime library.
This has advantages for deployment tools like PerlApp, Perl2exe and PAR (and most of the rest of the PDK) in that they don't need to bundle MSVCR70.dll, or MSVCR71.dll, or MSVCR80.dll, or MSVCR90.dll etc into their generated executables; MSVCRT.dll is already guaranteed to be on absolutely every Windows machine.
For most extensions, there should be no problem if you build them with a later VC version, but if you use such a module with PerlApp/Perl2exe/PAR then you will need to package and auto-extract the additional runtime libraries for those compilers too. It is of course possible to mix and match multiple runtime libraries, but due to incomplete macro redefinitions in the Perl headers, that can run into problems in certain cases.
For 64-bit work on Perl 5.18 and newer:
The recommended compiler is MinGW64 and dmake. There are known issues with using MicroSoft compiler toolchains, these versions are not compatible with MicroSoft Compilers.
For 64-bit work on Perl 5.16 and older:
The recommended compiler is the VC compiler from the Windows 2003 Platform SDK. The 32-bit or 64-bit versions of nmake from this SDK, or the nmake from VC6 will work.
Once again, we used this SDK because it uses the 64-bit version of MSVCRT.dll that ships with all 64-bit versions of Windows. This has the same benefits for 64-bit users that using the standard MSVCRT.dll has for 32-bit users. As with 32-bit, you can use a newer compiler, but you will then have to include the matching C runtime (and keep in mind that Microsoft does have a right to attach conditions to redistribution of their libraries).
The make tools tend to be more of a problem with 64-bit. The old standard, nmake15, is only a 16-bit binary so it's not usable on 64-bit systems. nmake from VC6 isn't free, and the official way to get the nmake tools from the 2003 SDK is to download the entire massive SDK.
----------------- Information that applies to use with wrapping solutions like PerlApp ---------------
When building modules for use with PerlApp, your treatment of third party libraries is also very important.
Common practice when building a dll (or a sofile or dylib on other operating systems) is to dynamically link the new library for the module to the third party libraries installed on the system. This keeps the files small, avoids legal liabilities, and reduces the amount of maintenance needed on your Perl module. Most non-ActiveState PPM repositories build modules with dynamic linking. However, when dynamic linking is used, and the result is wrapped with PerlApp, the target system's dynamic loader will be called upon to find the third party library. Unless the library is present on the target system in a place where the dynamic loader can find it, your wrapped executable will fail. If the target system has an incompatible version of the third party library available to the dynamic loader, the results can be unpredictable. Binding the desired version of the third party library into your wrapped executable will have no effect, unless the dynamic loader somehow knows where that library will be extracted.
For use with PerlApp, it is desirable that modules be built with static linking. The modules in ActiveState's PPM repositories are built with static linking. Static linking embeds the third party library into the new dll, and makes the application using it truly portable. On the other hand, using static linking places legal onus on you to ensure that you have permission from the owner of the third party library to embed, and thereby redistribute, their intellectual property. In some cases, the reason a module is *not* available in PPM is that the license terms of the required third party libraries are unacceptable to us, or simply do not allow redistribution. Make sure you do your homework to understand the restrictions and conditions attached to the use of any necessary third party libraries before you create modules with static linking.
I have installed the module Tk-TableMatrix 1.23 ( Installed from AS, using
AS Perl Package Manager). All my scripts using this module are broken. I
have tried to run the "demo" scripts provided in the package. And no matter
which one I run. I get the following message.
--> perl -w basic.pl
Tk::TcldeclsVtab wrong size for TcldeclsVtab at
C:/PRG/Perl/lib/DynaLoader.pm line 252.
Tk::TkeventVtab wrong size for TkeventVtab at C:/PRG/Perl/lib/DynaLoader.pm
You need a version of Tk-TableMatrix 1.23 that is compiled against Tk 804.x.
When the Tk shipped with ActivePerl was updated to 804.x in the middle of the 5.8.x series, it was recognized that modules which depended on Tk would need to be recompiled. Doing so would, however, makes those modules incompatible with older releases still using Tk 802.x. Since PPM only supports one version of any given module revision per repository, all those older 5.8.x releases would have lost their PPM sources.
Improvements to the functionality of PPM are envisioned which will allow dependency based selection of module versions. For now, the workaround has been to distribute different versions of these modules with compatibility issues from different PPM repositories, some of which are not maintained by ActiveState.
Modules with dependencies on Tk802.x will continue to be available at ActiveState. Modules with dependencies on Tk804.x are available from Randy Kobes' University of Winnipeg PPM repositories:
I downloaded Activeperl form your website, but when I go to start the installation process I get this error:
"This installation package could not be opened. Contact the application vendor to ensure that this is a valid installer package."
What is wrong?
This error message *always* indicates that the MSI installation package has been corrupted during the download. You will need to re-download.
It is very common to get repeated bad downloads. Please remember to flush your local cache, or switch to a different browser program. Also remember that the bad file is likely cached at your ISP, so you may have to wait a while before the bad cache is cleared.
You can verify the downloaded file against the MD5SUMS published in each download directory:
You can get a tool to generate md5sum hashes from here:
Often you can get past a cache issue by navigating to the file differently. You might have better luck starting from here:
On Unix I can run commands like "foo.pl | bar.pl" and have the output of foo.pl be the input of bar.pl. This doesn't seem to work on Windows. How can I make this work?
The Windows command interpreter cmd.exe does not support IO redirection for programs started via shell associations, like those created for .pl files during the ActivePerl installation. It only works for .bat, .com, .cmd, and .exe files.
You need to write:
perl foo.pl | perl bar.pl
Or if the files are not in your current directory but are on the PATH:
perl -S foo.pl | perl -S bar.pl
Alternatively, you can wrap your .pl files into .bat scripts using pl2bat:
Then run them as:
a | b
This is also the case for > and <.
What are the implications of the March 2007 DST changes for ActivePerl running on Windows?
The daylight saving time (DST) for the localtime() function is
determined by the C runtime library function of the same name.
This function has 2 different operating modes:
1) The TZ environment variable has been set.
In this case MSVCRT calculates DST itself, based on the USA rules.
The latest released version (as of (March 5th 2007) of MSVCRT.dll has
not yet been updated for the 2007 DST rules. The localtime() function
will still apply the old rules to 2007. Microsoft claims to have a
hotfix for this, that is available from Microsoft Customer Support
2) The TZ environment variable has *not* been set.
In this case MSVCRT retrieves the DST transition times from the
This API only provides the transition times according to the *current*
DST rules. There is no database of historical transition times. That
means that localtime() applied to previous years will use the new
transition times even for old timestamps.
Windows Vista (and Longhorn Server) support a new API called
GetDynamicTimeZoneInformation() that implements a database of historic
DST rules. It is not known if the hotfix mentioned above will make
use of this API when running on Vista.
When I try to install a ppm package I get this error:
Downloading ActiveState Package Repository packlist...failed 500
Can't connect to ppm4.activestate.com:80 (connect: Unknown error)
It looks like your local network firewall or Proxy is preventing you from connecting with our ppm servers. Instructions on how to configure Proxy authentication are available here:
Alternatively, if you have a Business Edition license, you can download zip packages for the modules you need from:
This shows the build status of each module. The column marked Logs will have a build log for the last attempt. If a module failed to build, the icon for the failed platform will have a red box around it. Like AAC-Pvoice. It fails on every platform. If you click the red box icons, you will get a report on how it failed.
If it doesn't fail to build, an icon for the platform will appear in the PPMX column. These icons are links to downloadable .ppmx files. PPMX is a newer format than the old .ppd files, but a ppmx file can be used exactly the same as the old PPD files as described in the manuals. The main advantage is that PPMX is compressed like a zip, but doesn't need to be manually unzipped before use:
Please note that some modules have dependencies and may fail to install because of this. It would be helpful to connect on an internet-enabled machine, and use ppm's 'tree' command to see what dependencies there are:
ppm> tree Date-Calc
Will ActivePerl handle the new US DST changes?
ActivePerl relies on the underlying operating system for any date information. Providing the operating systems are patched to take into account the new DST laws there should be no issues.
Please note that you will want to ensure that you check any extra modules (beyond the core and enterprise edition modules that we provide) that are used are up to date.
This module needs updating, as it contains actual switchover times for various time zones. The module is updated frequently on CPAN to keep it in sync with the Olson timezone database and the latest version contains the updated rules.
What is the best version of ActivePerl to use with Windows 7?
The best version of ActivePerl to use on Windows 7 is always the most recent build of ActivePerl.
ActivePerl passes the same suite of tests on Windows 7 as they do on Windows XP or Vista and other supported versions of Windows.
ActivePerl's known issues on Windows Vista include:
If you run into other issues, please report them at:
PPM4 fails on Windows systems where users have non-ASCII characters in their username and/or there are non-ASCII characters in common paths. Is there a work-around for this?
This issue has been resolved in ActivePerl 820 and higher
PPM in ActivePerl 819 on Windows fails to start up for users with non-ASCII user names. The error message displayed is something like:
ppm gui failed: DBI connect('dbname=C:\Documents and Settings\ \Application Data/ActiveState/ActivePerl/ppm-MSWin32-x86-multi-thread-5_8.db', '',...) failed: unable to open database file(1)
This is caused by limitations in Perl's handling of Unicode and we plan to address this issue in the upcoming release. The recommended workaround is to tell PPM to access its state database from a path consisting of plain ASCII characters only. It is achieved by setting the ACTIVEPERL_PPM_HOME environment variable to the name of a directory that ppm should use. For instance:
C:\> set ACTIVEPERL_PPM_HOME=C:\Perl\Temp C:\> ppm