Perl might have been born on UNIX, but it's also renowned to be one of the most portable programming languages. In spite of this, people generally don't think of Windows as a Perl development platform.
You might be surprised to discover that Windows is quite a suitable environment for developing with Perl. In fact, you can do almost everything you do on *nix Perl on Windows, and if you're proficient with Windows, you can keep using it and code Perl efficiently.
Today, we will show you to set up your Windows machine for Perl development, and a few of the options you have available in the way of integrated development environments.
Perl options on Windows: ActivePerl and Strawberry
Until recently, if you wanted to run Perl on Windows, the distribution of choice was ActiveState's ActivePerl. There was a significant problem with ActivePerl, however: you had to use the versions of modules available in ActiveState's repositories. If you needed a module (or version) that wasn't in ActiveState's repositories, you were in a tough place. Some of the more common culprits were any modules that made use of SSL, which was forbidden from export by various laws. This lack of (updated) modules led to the creation of various alternative repositories. Unfortunately, this often only swapped one out-of-date repository for another.
Today, there is another solution: Strawberry Perl. Strawberry Perl is billed as "A 100% Open Source CPAN-capable Perl for your Windows® computer that works exactly the same as Perl everywhere else". For some time, Strawberry was alpha-quality, but it is now a very solid option. The robustness of Strawberry was demonstrated in late 2008 when it was shown that it could run the full installation of Catalyst from CPAN.
The key benefit and the secret to Strawberry's power is that it comes with, and is well integrated with a, subset of the GNU tools. This allows developers to install modules from CPAN the exact same way everyone else does, without relying on third-party repositories. Unlike ActiveState, you don't have to mess with Cygwin, or Microsoft's broken versions of make (Older versions of nmake can't deal with command lines longer than 256 characters, which breaks most testsuites. Newer versions of nmake need to be extracted from an 800Mb VisualC++ Express DVD image).
We think Strawberry Perl is definitely the way to go for Windows Perl development. Fortunately for us, Strawberry Perl is also easy to install.
Installing Strawberry Perl
Begin by visiting the Strawberry Perl website at www.strawberryperl.com and selecting the distribution you like. We recommend Strawberry Perl 5.10. After downloading, execute the installer. The installer will place the Perl related files in C:\strawberry. You'll now have a functional Perl on Windows. Yes, it's that easy.
Making it easier
After Strawberry Perl is installed, there are a few things to make it easier to call Perl programs from the command prompt:
First, we need to add
perl.exe(and related tools -perldocetc.) to thePATH. This will allow you to run Perl programs no matter what directory you are in.- Right click on My Computer and select Properties.
- In the dialog that opens, select the Advanced tab.
- Click the Environment Variables button.
- Edit the
PATHvariable in the lower box labeled System variables. - Add your Strawberry Perl install location - by default you would add a ';' followed by
c:\strawberry\perl\bin\
Now we need to add
.plas an executable extension. This will allow you to run scripts without prefixing them withperl.exeat the command prompt:- in the same dialog box as above, edit the
PATHEXTvariable - Add
;.plto the end - If you want to be able to run tests easily, add
;.tas well
- in the same dialog box as above, edit the
Installing CPAN modules
As we mentioned before, installing modules is straightforward with Strawberry Perl. You can do it exactly the same way as with any other Perl. At a command prompt, type:
cpan My::Module
Limitations
There is a list of modules known not to install successfully on Windows, and it's a good idea to check them if you have difficulty installing a CPAN module. Some have tests failing because they depend on UNIX-specific features, while others have makefiles which assume GNU tools being present. The point is that it's quite possible to get a module running if you tweak things with some amount of insistence.
Perl IDEs on Windows
Many Windows code editors support Perl syntax. Among these, a few have built-in debugger features (single stepping, watches, breakpoints, call stack etc.):
Komodo IDE - a powerhouse IDE for all web development languages; commercial license (there is a FOSS Komodo Edit without debugging support). Komodo can edit remote files via SCP, and coupled with WinSCP synchronizing a local source tree directory on your Windows machine with a remote directory on a *nix server, provides a powerful all-in-one local/remote editing solution.
EPIC - Perl IDE and Editor for Eclipse; open-source
OptiPerl - faster than Komodo and less expensive, but less powerful.
Another promising IDE is Padre (written in Perl with wxWidgets), but it has no debugging features at the moment.
Conclusion
Development with Perl on Windows is not just possible, it's easy. There are a multitude of friendly freeware editors and IDEs, and Strawberry Perl lets you build almost any module from CPAN.
Resources
Working with Perl on Windows with Strawberry Perl is nearly identical to working with Perl on other platforms. Nearly. In case you do run into issues, you can find answers to your questions in the Win32 Perl wiki and the Strawberry Perl wiki. If you use these instructions and start developing Perl on Windows, drop us a line - we'd love to hear from you.




Thanx Dan. I haven't dared try Cat on Windows but it's nice to get a heads-up on from people with experience of it.
Hello Dan,
I have a small problem using perl through env. var.
I have integrated the perl editor EPIC with Eclipse. In order to run the scripts I have to specify in the Epic's property dialog box the location of the executable perl.exe.
I have found two solutions for this issues, but is not quite the one that I want and I was wondering if you can help me. Both sollutions use env. var.
1. To run as external tool from where I have created an env. var called PERL.
2. To add the location of perl.exe to the env. var. PATH.
I want another solution, something in between of these two.
I don't want to run perl as external tool and since my env. var. "PATH" is too big. I want to create an env. var. only for PERL. But creating this env. var. only for PERL the perl editor doesn't read it.
Do you have a solution to this problem?
Thank You.
PS: If you have a solution or want other details please contact me at ovidiuromanlucian@yahoo.co.uk