I am guessing you mean ActiveState. If you look at the
ActiveState requirements, it states all platforms of
Windows.
If you look at the PerlWin32 reference, you would find:
This set of instructions is meant to describe a so-called
``native'' port of Perl to Win32 platforms. This includes
both 32-bit and 64-bit Windows operating systems. The resulting Perl requires no additional software to run (other than what came with your operating system). Currently, this port is capable of using one of the following compilers on the Intel x86 architecture:
and
Notes on 64-bit Windows
Windows .NET Server supports the LLP64 data model on the Intel Itanium architecture.
The LLP64 data model is different from the LP64 data model that is the norm on 64-bit Unix platforms. In the former, int and long are both 32-bit data types, while pointers are 64 bits wide. In addition, there is a separate 64-bit wide integral type, __int64. In contrast, the LP64 data model that is pervasive on Unix platforms provides int as the 32-bit type, while both the long type and pointers are of 64-bit precision. Note that both models provide for 64-bits of addressability.
64-bit Windows running on Itanium is capable of running 32-bit x86 binaries transparently. This means that you could use a 32-bit build of Perl on a 64-bit system. Given this, why would one want to build a 64-bit build of Perl? Here are some reasons why you would bother:
A 64-bit native application will run much more efficiently on Itanium hardware.
There is no 2GB limit on process size.
Perl automatically provides large file support when built under 64-bit Windows.
Embedding Perl inside a 64-bit application.
Here is the Link
| 