in reply to Perl on Windows Best Practices?
I personally use ActivePerl or self compiled VC Perl (same thing). As other said in the thread, more XS things compile on 32 bits than on 64 bits. Windows is kindda a deprecated platform for Perl. In the late 1990s and early 2000s, Microsoft (through AS) and ActiveState/Hip poured a ton of resources into creating Win32 Perl. All that went dead when .NET came out (AS Perl.NET was the last Perl thing MS ever funded I think), or when MS realized that Perl can't be compiled to .NET CLR bytecode and "embrace extend extinguish" wouldn't work with the Perl crowd.
Cygwin Perl I don't recommend, it seems to get less attention than Mingw and VC Perl from p5p. Between Mingw (GCC) and VC I'm not sure. VC is C89 and MS has repeatedly said since 2008 on their forums/bug trackers that they will not be added any C99 or C11, or any features at all, to VC plain C compiler (C++ is a different story with MS). Many non-Perl POSIX-ish FOSS projects (which can wind up as XS modules in Perl) have formally abandoned compatibility with VC and say "we only support and use GCC C [time for MS to grow up/peer pressure on MS to adopt C99/C11]". But with VC Perl, I think its easier to debug the Windows vs Perl interaction because of the VC debugging symbols MS offers. But because Mingw Perl is a much newer product in the history of Perl, and includes its own reverse engineered equivalent of Platform SDK, some things that compile for modern VC Perl won't compile for Mingw Perl. Not all VC C code (lvalue casts for example) is valid GCC C code. Mingw Perl's FOSS Platform SDK is often older than the latest MS Platform SDK, so things that want to use Vista/NT6/Win 7 APIs might not compile with Mingw yet (plus AS's PPM build farm uses circa 2002 headers). Then again, you said you want XP compatibility, so Platform SDK age is irrelevant for you.
I believe that Win32 Perl, can use a registry entry in addition to environment variables to determine @INC. Having 1 /site/lib and one /lib on a network share for everyone might be something you want to do. Beware of network latency though, My Network Places paths/mapped paths might cause unacceptably slow Perl interp startups. Then again you said that your IT department refuses to help. Have you considered portable perl installed on a USB stick and give one to each employee? Updating will be a chore. Considered writing a perl script that will update every PC's C: Drive Perl dir once a month over the network?
You don't want Perl Module hell (AKA DLL hell) between your different PCs.