The win32.perl.org web site provides references to several Perl distributions for MS Windows.
For a long time I have been using ActivePerl from ActiveState but recently I switched to Strawberry Perl.
IMHO The only advantage that Active Perl still has over Strawberry Perl is the fact that it comes with Perl Tk which means its easy to install Devel::ptkdb the graphical debugger. Other than that, I think Strawberry Perl has all the advantages.
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.
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.
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.
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.