我应该在 Windows 上使用哪个版本的 Perl？

Strawberry Perl is just getting better and better. One problem I've repeatedly had with ActiveState is that my modules sometimes fail to install because I need an upgrade to a core module, but they won't allow that. Thus, everybody who doesn't use Windows can use my code, but they can't do that with ActiveState's Perl.

ActiveState also has a very dodgy build system which often fails to report exactly why a module failed to build. I got so tired of emailing and asking for this information that I eventually gave up. I want my code to run on Windows, but if ActiveState doesn't provide me with that information and doesn't give me any option for upgrading core modules, I just can't use it. Some of my modules have NO build failures on any operating system -- except those with ActiveState Perl. Support Strawberry Perl and just don't worry about ActiveState.

If ActiveState has fixed their build system and their 'no upgrade to core modules' policy, it's worth revisiting.

I primarily use ActivePerl, but I really like where Strawberry Perl is headed. I love that the cpan shell "just works" and I don't have to jump through a bunch of hoops to install XS modules. (e.g. ExtUtils::FakeConfig, though that's less necessary in more recent ActivePerl builds.) I'm also excited about the possibility of Perl on a thumbdrive. The dev release of Portable Perl is pretty usable already.

I agree that the main advantage of ActivePerl is Tk out of the box, but note that as of 5.10 ActivePerl no longer ships with Tk by default. It ships with Tkx instead.

ActiveState Perl has been considered the de facto Windows Perl for quite a while. While it has a lot of flaws and a lot of us use something else, it remains very popular. If you were building Perl code to be executed on a Windows machine (other than your own), I would consider writing it with an eye towards a default (or as default as I could get it) AS Perl installation executing it. Anything else and you are introducing barriers to entry for others trying to use your app later.

The future is definitely Strawberry Perl. Whichever you chose though (and this problem is not unique to Windows), if you're distributing the end result to other machines, you're going to have to be careful as regards the installer/installation instructions you provide.

There is no single-best Perl distribution. Vanilla Perl (relocatable, redistributable Perl), and it's more-developer-friendly Strawberry Perl have significant potential.

However, there is a very good reason why ActivePerl is so very popular. The advantages mostly come in the form of ease of deployment for your end users (no compiler necessary to use their package manager, PPM). The ActiveState PDK (Perl Development Kit) is also a very nice way to pack a complete Windows binary that doesn't require any Perl to be installed on the user's machine.

Unfortunately, many very nice CPAN modules (like the Perl bindings for OpenSSL) are not available via ActiveState's repository.

Like most things, you should make your selection based on which distribution best meets your needs.

I had major problems with Strawberry, and I felt there was no support. The good people at PerlMonks couldn't help me, and I gave up. If this page leaves you with a certain lack of confidence, there's your answer.

Strawberry Perl is more like Perl on *nix. It comes with MinGW which could be useful on its own. The Perl modules can also be installed with either ppm or cpan.

I always use Cygwin (xterms with bash are so much better than cmd windows) and the Perl that comes with it. I install Perl modules with the CPAN shell (the "cpan" command); it works fine.

The code I write lands in Fortune 500 companies so a "corporate" feeling is helpful. I've used ActivePerl so far, and it's worked fine for both internal tooling and for distribution to those large'ish customers.

I by far prefer Strawberry Perl. For one, it installs gcc as part of mingwin, so that you can install directly from CPAN.

I used ActiveState's perl for awhile, but I had a lot of flakiness from one machine to another despite them being (seemingly) identically configured. Their PPM module packaging left a bad taste, also. It makes it dead-simple to manage packages, but you rely on them to update PPM after CPAN updates. Also, PPM is not by any means the full content of the CPAN; The last time I'd used ActivePerl, I had a hard time finding all of the modules I needed, and the ones that were there were often an old version.

I am using Active State Perl 5.014, which works OK.

The problem is, it doesn't have the latest version of Padre (the IDE, debbugging environment).